UMLazi

Just a warning: If you want a nice, stable UML farm, stay away from 2.4.26-1um. Apparently, 2.4.24-1um is the latest stable patch.

Update: Also, some people have reported problems with the 2.6.6 kernel on the download. I’d advise against using it in production until a new one is posted.

I’ve been running 2.4.22-5um since last October. For the most part it’s been pretty stable—I have guests that have been up since the first day I pushed it out—but there were still the occasional odd kernel panics. Over time, as the farm grew from dozens of guests, to several hundred guests, those occassional crashes added up to several a day.

So, I built a new kernel (2.4.26-1um) and after some perfunctory testing (does it boot, can I compile a kernel in it, will it pass a few thousand emails) pushed it out to a batch of about a hundred non-critical guests. Man, what a disaster. I immediately went from one crash for every three or four hours, to three or four crahes for every one hour. Then, when backups kicked off, they all pretty much collapsed at the same time.

Looks like 2.4.26-1m has some problems with high load.

So, now I have a 2.4.26 kernel patched with the 2.4.24-1um patch. It’s pushed out to the same hundred hosts, and so far, four hours later, no crashes. After it runs for a few days, I’ll promote it to “default”, and the rest of the guests will pick it up with their maintenance reboots.

For UMLazi users, the new kernel (2.4.26-20040615-1um) is available on the download page.

When creating a large number of UMLazi Guests at the same time, or creating a guest with more than 8 filesystems, you might run into an error like this one:

mount: could not find any free loop device

This is because your host kernel is limited in the number of loopback filesystems it can have mounted at any one time. The default limit is 8. I like to set this to 64.

To increase this value, you need to tell the kernel you want more devices:

• If you have the “loop” driver compiled into your kernel, you need to add “max_loop=64” to your kernel boot arguments (the “append=” line in lilo.conf, or to the end of the “kernel” line in grub’s menu.lst), and reboot.

• If you have the “loop” driver compiled as a module, you need to insmod it with “max_loop=64” added to its options. On Debian systems, you edit /etc/modules.conf and add “options loop max_loop=64”, and “rmmod loop” “modprobe loop”.

  If you’re using devfs, then stop here. The new /dev/loop* will appear automatically. If not, you’ll need to edit and run MAKEDEV:
  Change:

          loop)
                  for part in 0 1 2 3 4 5 6 7
                  do
                          makedev loop$part b 7 $part $disk
                  done
                  ;;
  

  To:

          loop)
                  for part in `seq 0 63`
                  do
                          makedev loop$part b 7 $part $disk
                  done
                  ;;
  

  And run “MAKEDEV loop”.

Release 1.0.5.1 clears up all reported bugs from 1.0.5. Most importantly, “systemcheck” now works.

There’s improved support for Fedora Core 2, as well, thanks to Antonello Alonzi.

Antonello Alonzi reports the following bugs in 1.0.5:

• There’s a typo in “systemcheck” which prevents it from running. D’oh. Add a ”)” on line 44, after the “file_exists /usr/bin/sar” block.
• On Fedora Core 2, the chkconfig syntax in the umlazi.init script isn’t complete. Locate the chkconfig line and add this line before it:
  # description: This script won't touch a Guest if it's not "enabled"

• Also on Fedora Core 2, “nice” is in ”/bin/”, not ”/usr/bin”. This prevents Guests from starting on Fedora Core 2. Fix by changing ”/usr/bin/nice” on line 515 of lib_uml to just “nice”.

  Update: These bugfixes have been rolled into UMLazi 1.0.5.1.

Until we have the mailing lists and bugtracking systems up, please email your bug reports and support questions to support@umlazi.org.