> My favorite way out for most of the cases I would be forced to handle with Xen for this kind of needs is to use vserver - Which is _not_ formally a virtualization technology, but a compartmentalization/isolation technology (akin to what was introduced as the BSD Jails around 2000), where many almost-independent hosts share a single kernel, but live within different security contexts.
Well things like BSD Jails, Vserver, OpenVZ, etc etc. All of these are very much virtualization technology in a very real sense. They just are not hardware virtualization.
> Why do you want to paravirtualize? Because the performance impact is way lower. You don't have to emulate hardware at all - In a regular virtualization setup, the guest OS will still shuffle bits around to give them to, say, the ATA I/O interface, possibly aligning them to cylinder/head/sector - On a hard disk that just does not exist, that is a file on another filesystem or whatever. When it is paravirtualized, the guest OS just signals the host OS to do its magic.
Heh. KVM has paravirt drivers that are built into the kernel right now.
virtio-blk = block driver
virtio-rng = random number generator
virtio-net = ethernet network driver
virtio-balloon = used for reclaiming memory from VMs
virtio-pci = pci driver
9pnet_virtio = plan9 networking
And that works fine with updated versions of Qemu also. So you should be able to take advantage of them if your using Kqemu + Qemu for your virtualization. I think. But virtio is a standardized way of doing things. Should probably work with Qemu-dm for Xen stuff.
I there are windows drivers for virtio network. I am not sure about virtio block or balloon though...
I don't know how well KVM + Virtio compares to Xen PV..
Then on top of that you can use AMD's IOMMU or Intel's VT-d to map real hardware directly to virtualized hosts, which would be the fastest possible since your handing off direct access to the hardware.