On Sat, Aug 27, 2016 at 11:53:39AM -0400, Anthony de Boer via talk wrote:
The other thing it doesn't do is give you a bunch of virtual machines with collectively more memory than the server has installed. I've had to deal with a box where people had given away 110% of the RAM chips to their various QEMU instances and the server was crawling around on the floor in a very slow and hesitant way.
qemu/kvm supports balloon drivers in the guest. Also the host could run KMS. So you have multiple options for allowing you to overprovision the system and still do fine.
Someone mentioned options: yes, QEMU has a lot of them, and having a script that sets the standard ones and lets you specify just what's different between each one and the next can make starting them a lot easier. QEMU's native commandline can easily start onto a third line on an 80-column screen.
Also, do please use kernel bridging and not the userspace virtual switch.
Yes a kernel bridge with tap interfaces in qemu works pretty well. There might even be better options than the tap interface these days.
If you're running a bunch of heterogenous operating systems, though, QEMU gets you there. I've even seen people use it for Windows.
If everything is this-decade Linux then LXC may be an option. It isolates each VM's processes and root filesystem and network interfaces while still sharing memory, CPUs, and (optionally, if VMs are in the same filesystem) disk space. I've run three generations of Debian all under the kernel that came with the latest. If you're also wanting to run eg Fedora then there's a good chance of it just working, or if not you may have to compare kernel configs and build a host kernel that makes everyone happy.
LXC lets you run collectively a far bigger party; users have access to all the CPUs and RAM when they have a large compute job, not just the tiny ration the QEMU config sets aside for them. So far I haven't had to configure resource limits on LXC; YMMV.
You can restrict resources with lxc as far as I recall. But you might not have to. I guess it depends if you trust the stuff inside the container to be well behaved or not. -- Len Sorensen