Dell Linux Engineers work over 5000 bugs with Red Hat

A post today by Dell’s Linux Engineering team announcing support for RHEL 5.8 on PowerEdge 12G servers made me stop and think.  In the post, they included a link to a list of fixes and enhancements worked in preparing RHEL 5.8 for our new servers.  The list was pretty short. But that list doesn’t tell the whole story.

A quick search in Bugzilla for issues which Dell has been involved in since 1999 yields 5420 bugs, 4959 of which are CLOSED, and only 380 of which are still in NEW or ASSIGNED state, many of which look like they’re pretty close to being closed as well.  This is a testament to the hard work Dell puts into ensuring Linux “Just Works” on our servers, straight out of the box, with few to no extra driver disks or post-install updates needed to make your server fully functional.  You want a working new 12G server?  Simply grab the latest RHEL or SLES DVD image and go.  Want a different flavor of Linux?  Just be sure you’re running a recent upstream kernel – we push updates and fixes there regularly too.

Sure, we could make it harder for you, but why?

Congratulations to the Linux Engineering team for launching 12G PowerEdge with full support baked into Linux!  Keep up the good work!

s3cmd sync enhancements and call for help

Coming soon, Fedora and EPEL users with virtual machines in Amazon (US East for starters) will have super-fast updates.  I’ve been hacking away in Fedora Infrastructure and the Fedora Cloud SIG to place a mirror in Amazon S3.  A little more testing, and I’ll flip the switch in MirrorManager, and all Amazon EC2 US East users will be automatically directed to the S3 mirror first.  Yea!  Once that looks good, if there’s enough demand, we can put mirrors in other regions too.

I hadn’t done a lot of uploading into S3 before.  It seems the common tool people use is s3cmd.  I like to think of ‘s3cmd sync’ as a replacement for rsync.  It’s not – but with a few patches, and your help, I think it can be made more usable.  So far I’ve patched in –exclude-from so that it doesn’t walk the entire local file system only to later prune and exclude files – a speedup of over 20x in the Fedora case.  I added a –delete-after option, because there’s no reason to delete files early in the case of S3 – you’ve got virtually unlimited storage.  And I added a –delay-updates option, to minimize the amount of time the S3 mirror yum repositories are in an inconsistent state (now down to a few seconds, and could be even better).  I’m waiting on upstream to accept/reject/modify my patches, but Fedora Infrastructure is using my enhancements in the meantime.

One feature I’d really like to see added is to honor hardlinks.  Fedora extensively uses hardlinks to cut down on the number of files, amount of storage, and time needed to upload content.  Some files in the Fedora tree have 6 hardlinks, and over three quarters of the files have at least one hardlink sibling.  Unfortunately, S3 doesn’t natively understand anything about hardlinks.  Lacking that support, I expect that S3 COPY commands would be the best way to go about duplicating the effect of hardlinks (reduced file upload time), even if we don’t get all the benefits.  However, I don’t have a lot more time available in the next few weeks to create such a patch myself – hence my lazyweb plea for help.  If this sounds like something you’d like to take on, please do!

FUDCon Blacksburg videos

I shot videos of several of the presentations at the Fedora User and Developer Conference yesterday.  For your viewing pleasure:

  • “State of Fedora” from the Fedora Project Leader, Jared Smith [ogg]
  • Mike McGrath, team lead for OpenShift, demoing OpenShift [ogg]
  • Jon Masters and Chris Tyler, on the ARM architecture in Fedora [ogg]. ARM is a secondary architecture today.  By Fedora 18, with your help, it needs to become a primary architecture.
  • David Nalley presented on CloudStack, which is aiming for Fedora 17 inclusion. [ogg]
  • Dan Prince and Russell Bryant giving an introduction to OpenStack [ogg]
  • Mo Morsi presenting the Aeolus cloud management project [ogg]

[Update 1/18/2012] I was able to upload all the videos to YouTube.  http://www.youtube.com/playlist?list=PL2BAA7FF83E6482C2
is a playlist with all 6.

Consistent Network Device Naming updates

Today I released biosdevname v0.3.7, after listening to feedback from all across the web, including NetworkWorld, LWN, and Slashdot.  No, I’m not killing the feature, as some might hope, but some changes are in order.

First, it’s amazing how many people hated the ‘#’ character in device names.  Yes, that was bound to cause some problems, but nothing that couldn’t be fixed given enough time.  But since it’s early in the game, changing that character from ‘#’ to ‘p’ accomplishes the same goal, with less chance of breakage, so that’s done.  pci<slot>p<port>_<vf> it is….

Second, the various virtual machine BIOSes each do something slightly different for the network devices they expose.  VMware exposes the first NIC (traditionally eth0) as in PCI slot 3.  KVM exposes the first NIC as in PCI slot 2, but has no information about the second NIC.  Xen doesn’t expose anything, so those all kept the ethX naming convention.

To address these discrepancies, and because there is no physical representation of a (virtual) NIC in a virtual machine, biosdevname no longer suggests a new name for NICs if running in a VM guest.  This means all VM guests keep ethX as their naming convention. Thanks to colleague Narendra K for this fix.

Third, for everyone who still thinks renaming devices is a really bad idea, you get an out.  A new kernel command line option, honored by udev, lets you disable biosdevname.  biosdevname=0 will prevent biosdevname from being invoked, effectively disabling this feature, leaving you with the ethX names.

All this, and the usual assorted bug fixes as biosdevname gets more widespread exposure and testing.

Love it?  Hate it?  Let me know.  You can find me (mdomsch) on IRC on FreeNode in #biosdevname, #udev, or #fedora-devel, as well as the usual mailing lists.

Fedora Test Day today – please join us

Today is the official  Fedora Test Day for Consistent Network Device Naming.  Given all the coverage this week on NetworkWorld and Slashdot, I would like to see widespread testing of this feature, to assuage the concerns and misconceptions raised there.  Testing is simple – download and boot the LiveISO, and report success or failure on the wiki page.  You can even try it out on a running Fedora 14 instance if you like.

The Dell engineers who have been working on this for years will be online in #fedora-test-day on FreeNode IRC today if you have any questions.  Please join us.  Thanks for your time and participation.

Consistent Network Device Naming coming to Fedora 15

One of my long-standing pet projects – Consistent Network Device Naming, is finally coming to Fedora (emphasizing the 2 of the Fedora F’s: Features and First), and thereafter, all Linux distributions.  What is this, you ask?

Systems running Linux have long had ethernet network devices named ethX.  Your desktop likely has one ethernet port, named eth0.  This works fine if you have only one network port, but what if, like on Dell PowerEdge servers, you have four ethernet ports?  They are named eth0, eth1, eth2, eth3, corresponding to the labels on the back of the chassis, 1, 2, 3, 4, respectively.  Sometimes.  Aside from the obvious confusion of names starting at 0 verses starting at 1, other race conditions can happen such that each port may not get the same name on every boot, and they may get named in an arbitrary order.  If you add in a network card to a PCI slot, it gets even worse, as the ports on the motherboard and the ports on the add-in card may have their names intermixed.

While several solutions have  been proposed over time (detailed at Linux Plumbers Conference last year), none were deemed acceptable, until now.

Enter biosdevname, the tool Dell has developed to bring sanity (and consistency!) to network device names.  Biosdevname is a udev helper, which renames network interfaces based on information presented by system BIOS.

The new naming convention is as follows:

  • em[1-N] for on-board (embedded) NICs (# matches chassis labels)
  • pci<slot>#<port> for cards in PCI slots, port 1..N
  • NPAR & SR-IOV devices add a suffix of _<vf>, from 0..N depending on the number of Partitions or Virtual Functions exposed on each port.
  • Other Linux conventions, such as .<vlan> and :<alias> suffixes remain unchanged and are still applicable.

This provides a sane mapping of Linux network interface name to externally visible network port (RJ-45 jack).

Where do we get this information?  The algorithm is fairly simple:

  • If system BIOS exposes the new PCI Firmware Specification 3.1 ACPI _DSM method, we get the interface label and index from ACPI, and use those.
  • Else if system BIOS exposes an index and label in SMBIOS 2.6 types 9 and 41, use the index value.
  • Else if system BIOS exposes index via the HP proprietary SMBIOS extension, use that.
  • Else fall back to using the legacy PCI IRQ Routing Table to figure out which slots devices are in, sort the PCI device list in breadth-first order, and assign index values.

How will this affect you?

If you have scripts that have hard-coded eth0 or have assumptions that ethX is a particular port, your scripts are already broken (you may just not know it yet).  Begin planning on using the new interface names going forward, adjusting your scripts as necessary.

Fedora 15 will be the first distribution to use biosdevname by default.  There will be a Test Day on Thursday, January 27.  I encourage you to download the Live image, boot it on your system, and verify that your network interfaces are now named according to the above convention, and that all works as expected.  You may also take the opportunity to review your custom scripts, looking for hard-coded ethX values, and prepare for the coming name change.

Once we get sufficient exposure and verification using Fedora, I expect to see this change roll into other Linux distributions, and other operating systems, over time.  Consider yourself warned.

Dell introduces RHEL Auto-Entitlement and 5-year subscriptions

Noted on the Dell blog, the auto-entitlement system we rolled out to the US and Europe a few years ago is finally available worldwide.  What is auto-entitlement, you ask?

If you’ve ever purchased a Red Hat Enterprise Linux subscription when purchasing a Dell PowerEdge server, shrink-wrapped alongside the CDs is a “registration card”, with a long string of numbers on it.  Upon unboxing your system, you had to a) not throw away that card; b) not lose that card; c) get that card to some responsible party at your organization; d) ensure that responsible party went to http://redhat.com/activate to activate the subscription, using the number on that card.  See how many steps that took?  Can you guess how many ways something could go wrong in the process?

With auto-entitlement, the system administrator is able to simply log their new system into Red Hat Network the first time they use it (as they would to get updates and to manage their system).  Red Hat Network is then smart enough to recognize that the system was purchased from Dell, knows the subscription type and duration, and Bob’s your Uncle.  No registration card to lose, no extra steps to take.  Oh, and if you manage to blow away the hard disk image and re-install RHEL before connecting to Red Hat Network for the first time – no worries – auto-entitlement will still work.

Oh, and while we’re at it, the new 5-year RHEL subscription matches the available 5-year ProSupport hardware service contract, so there’s never any mess with having out-of-sync support subscriptions.

Just two more ways Dell ensures Linux, in this case Red Hat Enterprise Linux, “Just Works”.

Linux Plumbers Conference 2010 – User-visible Network Problems track links

At Linux Plumbers Conference in Cambridge this morning, we will be covering several networking issues that have specific implications on userspace programs or system administrator behavior.  Links below are to join us (virtually).  In addition, video of the sessions will be available following.

Topics and their discussion leaders:

  • Challenges in Mobile Networking – Dan Williams
  • Network Device Naming – Matt Domsch
  • Scaling techniques in the stack for servers with high connection rates – Ying Cai
  • Simplifying network configuration for VMs by harmonizing multiple Bridging, QOS, DCB and CNA implementations – Shyam Iyer

To join:

IRC: #lpc2010-thomas-paine on FreeNode

Etherpad (live note taking): http://etherpad.osuosl.org/lpc2010-user-visible-network-issues

Slide decks: http://domsch.com/linux/lpc2010/

Twitter and Identi.ca: Use hashtag #lpc2010

LPC Wiki links:

Fedora Elections – it starts now

You know it’s election season.  The commercials are unavoidable.  Candidates kissing babies.  “The other guys say…”.  Shameless promotion and pandering.  Division and false dichotomies rule the airwaves.

However, in Fedora-land, the tenor is quite calm, welcoming, and actively non-partisan, even though we have several elections going on.

First (timewise), the code name for Fedora 15.  This is the quirky name that we give each release, that both serves as inspiration for the artwork that our fantastic design team generates, and that ties our releases together, both backwards in history to our Red Hat Linux roots and continuing on with each subsequent Fedora release.  Each code name has a non-obvious link to the predecessor release, while leaving wide open the range of future release names.

After sifting through 50 suggestions, and trimming the list for possible trademark conflicts, we are left with 5 names that any Fedora member can vote for:

- Asturias
- Blarney
- Sturgis
- Lovelock
- Pushcart

Take a moment to reflect on the nature of each of the above, and then vote for your favorite.

Second, we have started the nomination process for the semi-annual election of seats on the Fedora Project Board and the Fedora Engineering Steering Committee (FESCo), and for the annual election of members of the Fedora Ambassadors Steering Committee (FAMSCo).  These are important, highly visible, volunteer positions which guide the Project as a whole, the technical details of the “product” of Fedora the distro, and coordinate the activities of our outreach and evangelism teams.  Please consider running for one of these offices by nominating yourself, or, you may nominate someone you would like to see be elected (with their consent of course).

For my part, I have had the pleasure of serving on the Board for the last 5 years since its inception.  We have come a long way during my tenure, from the elimination of the dreaded “Core vs Extras” distinction, to the creation of the Spins and Remixes processes that let anyone, anywhere, use Fedora for any purpose, to the creation of the Stable Updates policy, and finally a Vision Statement we can all get behind.  While there is plenty more to be done, it’s time for me to step aside from policy-making, and assist a new Board in delivering on these visions.  I thank the community for allowing me to serve on the Board thus far, and am counting on you to support the newly elected Board, FESCo, and FAMSco, in continuing to develop and deliver a fantastic distribution.

Linux Plumbers Conference: User-visible Network Issues Mini-Conf

At the Linux Plumbers Conference November 3-5, 2010 in Cambridge,
MA, we have a half-day mini-conference set aside on Thursday
morning (so as to follow immediately, but not conflict with netconf)
to discuss “User-visible Network Issues” – challenges that users face,
that could benefit from both userspace and kernel enhancements to make
their lives easier.

Accepted topics are:

* Challenges in Mobile Networking
Challenges that we have with networking in the mobile space.
Led by Dan Williams

* Network Device Naming
Which of my NICs is eth0?
Led by Matt Domsch

* Scaling techniques in the stack for servers with high connection rates
This talk will describe some techniques for scaling front end
servers. In particular, we will describe the the use of SO_REUSEPORT
in scaling servers for high connection rates with a single listening
port.
Led by Ying Cai

* Simplifying network configuration for VMs by harmonizing multiple Bridging, QOS, DCB and CNA implementations
Led by Shyam Iyer, with John Fastabend

While I’m sure the individual topics will generate great discussion,
it will be vital that members of the netdev community be present to
represent the kernel developers’ perspectives on the problems and to
help brainstorm solutions.  Most of these topics have significant
kernel components to them, and without additional kernel developer
participation, I fear we would just be talking to ourselves, but no
real progress made.  I invite you to attend LPC, and this
mini-conf in particular, and lend your expertise.

If you would attend LPC, except that the conference fee is a burden,
please let me know.  I have at least one pass available for mini-conf
participants.