Submitted by Benjamin Schweizer (not verified) on Thu, 2009/12/17 - 13:51.
- use libvirt! You can run kvm directly from the command line, wrap this into a script and reinvent the wheel. But you will not be able to use any management tools. If you don't need a GUI like VirtManager, there is virsh. The only caveat so far, there is no support for that fancy VESA-to-ncurses console wrapper (which allows text-mode installs within a ssh session (so no serial ttys are required)
- use virtio; if available, it's fast (and stable enough for me, since I've upgraded to a recent Kernel!)
- use labels to mount file systems, so that you can easily revert from virtio to scsi emulation (this is what rhev does)
- I name my bridge kvm0 e.g.; it should be obvious to anyone else that this is a special host.
- I store my VMs at /srv/kvm/ and configs in /etc/libvirt/; though, separating config from data looks somewhat odd on a single host environment.
- I'm using some routing tricks, so that I do not loose any ip addresses on my kvm0 bridge (which is necessary with some hosting providers, but this is another story that needs an extra post)
- I prefer to run 64bit clients because the 4 GB limit hits VMs the same way it hits physical machines
- naming storage: I think that's not important, but I derive the naming from the mount points/primary use in general. but: shall I put a (GPT) partition table inside of an iscsi volume?
what I've learned so far
- use libvirt! You can run kvm directly from the command line, wrap this into a script and reinvent the wheel. But you will not be able to use any management tools. If you don't need a GUI like VirtManager, there is virsh. The only caveat so far, there is no support for that fancy VESA-to-ncurses console wrapper (which allows text-mode installs within a ssh session (so no serial ttys are required)
- use virtio; if available, it's fast (and stable enough for me, since I've upgraded to a recent Kernel!)
- use labels to mount file systems, so that you can easily revert from virtio to scsi emulation (this is what rhev does)
- I name my bridge kvm0 e.g.; it should be obvious to anyone else that this is a special host.
- I store my VMs at /srv/kvm/ and configs in /etc/libvirt/; though, separating config from data looks somewhat odd on a single host environment.
- I'm using some routing tricks, so that I do not loose any ip addresses on my kvm0 bridge (which is necessary with some hosting providers, but this is another story that needs an extra post)
- I prefer to run 64bit clients because the 4 GB limit hits VMs the same way it hits physical machines
- naming storage: I think that's not important, but I derive the naming from the mount points/primary use in general. but: shall I put a (GPT) partition table inside of an iscsi volume?