Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU |
A few months ago I asked whether it be practical to run Linux servers inside Qemu guests (running on a Linux host). At least for small time stuff, the answer seems to be: yes. For the host I am running non-gui Ubuntu 7.04 on an AMD XP 1900+ with 2GB of RAM and a pair of parallel ATA disks doing software raid 1. I have two different bootable /-partitions, so before I do anything scary, I backup to the other /, and if anything goes wrong I can quickly reboot back to the previous state. I give the host 1 GB of swap for good measure. The Qemu I am using I compiled from sources because the Ubuntu version had a broken kqemu. (kqemu is a driver that allows native execution of x86 instructions most of the time, not emulation.) For guests I am also running Ubuntu 7.04. The guests are all non-gui console, completely headless, with the "serial port" console running in a "screen" session. I can attach to the appropriate screen, scroll back through the last boot, login on the console, etc. I don't have any fancy management tools. The slickest I get is to store PIDs of the guests so I don't accidentally launch two guest instances on the same disk image--that would be bad. Slight catch with this is if things crash I don't automatically sweep up the PID files. I really should add that. My guests are currently three: 1) A Postfix/IMAP server running in 400 MB, 2) A bash shell machine running in 192 MB, and 3) A www server (which I haven't really started to use) running in 128 MB. I need enough real RAM to completely cover the allocations given to the guests. I still have some RAM left over for playing with wikis, etc. I give each guest 1 GB of swap, for good measure. It works. I have a well known e-mail address that gets lots of spam, some of my users get plenty of spam. I have personally received over 70 thousand spams since mid September, 2007. (A lot more rejected once I added an IP blacklist lookup.) It seems to handle it. There is some overhead in running multiple OSs, and in emulating disks, but this machine is more powerful than my old server, so I figure I can handle anything the old one could. I have had about two problems. Once, after the mail guest had been up for nearly 90-days, it went away. I figure the Qemu application crashed. The other problem was a recent host kernel upgrade, it caused the guests' real time to run *way* slow. (The fix was to add "acpi=force" to the guests' kernel command lines.) I am happy with the whole setup. Noticing that I am nearly two OS revs back, I am liking the modular nature of the setup. If Ubuntu 8.04 looks appealing I can install it on the other / copy (run the installer on another physical machine, copy the resulting files in, refer to my notes and duplicate host customizations, mess with /boot, fstab details, etc), reboot to quickly see if it boots and whether the guests come up somewhat happy. The total downtime on a failure would be on-order 10-minutes, as I futze about discovering I have a problem. On success the downtime would be the reboot/guest restart time. If I want to rev. Qemu I can install a new copy without disturbing any running guests, try a test guest on the new Qemu. If it works I can restart other guests one-by-one on the new Qemu, reverting if there is a problem. For the guests I have images for the OS install that is separate from data partitions. To rev a guest I can copy the OS image and mess with it, build a new guest image, etc. I can rev the host OS to 8.04 and not touch the guests. I can rev a guest OS to 8.04 and not touch the host OS. I can rev the Qemu application for one guest and not touch the others. I can even package up my old (not /yet/ retired) server and keep it around as a runnable image (if I have the disk space). All open source. -kb, the Kent who is pleased. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ Discuss mailing list [hidden email] http://lists.blu.org/mailman/listinfo/discuss
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |