Reply to comment

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?

Reply

Please refrain from adding URLs to unrelated or commercial websites. This site is moderated and comments with inappropriate links are rejected. Thank you for your understanding.
The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

More information about formatting options