On Mon, 28 Mar 2011, Pasi Kärkkäinen wrote: > On Sun, Mar 27, 2011 at 09:41:04AM -0400, Steve Thompson wrote: >> First. With Xen I was never able to start more than 30 guests at one time >> with any success; the 31st guest always failed to boot or crashed during >> booting, no matter which guest I chose as the 31st. With KVM I chose to >> add more guests to see if it could be done, with the result that I now >> have 36 guests running simultaneously. > > Hmm.. I think I've seen that earlier. I *think* it was some trivial > thing to fix, like increasing number of available loop devices or so. I tried that, and other things, but was never able to make it work. I was using max_loop=64 in the end, but even with a larger number I couldn't start more than 30 guests. Number 31 would fail to boot, and would boot successfully if I shut down, say, #17. Then #17 would fail to boot, and so on. > Hmm.. Windows 7 might be too new for Xen 3.1 in el5, so for win7 > upgrading to xen 3.4 or 4.x helps. (gitco.de has newer xen rpms for el5 > if you're ok with thirdparty rpms). Point taken; I realize this. >> Third. I was never able to successfully complete a PXE-based installation >> under Xen. No problems with KVM. > That's weird. I do that often. What was the problem? I use the DHCP server (on the host) to supply all address and name information, and this works without any issues. In the PXE case, I was never able to get the guest to communicate with the server for long enough to fully load pxelinux.0, in spite of the bridge setup. I have no idea why; it's not exactly rocket science either. > Can you post more info about the benchmark? How many vcpus did the VMs have? > How much memory? Were the VMs 32b or 64b ? The benchmark is just a "make" of a large package of my own implementation. A top-level makefile drives a series of makes of a set of sub-packages, 33 of them. It is a compilation of about 1100 C and C++ source files, including generation of dependencies and binaries, and running a set of perl scripts (some of which generate some of the C source). All of the sources and target directories were NFS volumes; only the local O/S disks were virtualized. I used 1 vcpu per guest and either 512MB or 1GB of memory. The results I showed were for 64-bit guests with 512MB memory, but they were qualitatively the same for 32-bit guests. Increasing memory from 512MB to 1GB made no significant difference to the timings. Some areas of the build are serial by nature; the result of 14:38 for KVM w/virtio was changed to 9:52 with vcpu=2 and make -j2. The 64-bit HVM guests w/o PV were quite a bit faster than the 32-bit HVM guests, as expected. I also had some Fedora diskless guests (no PV) using an NFS root, in which situation the 32-bit guests were faster than the 64-bit guests (and both were faster than the HVM guests w/o PV). These used kernels that I built myself. I did not compare Xen vs KVM with vcpu > 1. > Did you try Xen HVM with PV drivers? Yes, but I don't have the exact timings to hand anymore. They were faster than the non-PV case but still slower than KVM w/virtio. >> Fifth: I love being able to run top/iostat/etc on the host and see just >> what the hardware is really up to, and to be able to overcommit memory. > "xm top" and iostat in dom0 works well for me :) I personally don't care much for "xm top", and it doesn't help anyway if you're not running as root or have sudo access, or if you'd like to read performance info for the whole shebang via /proc (as I do). Steve