On Fri, Dec 19, 2014 at 02:19:18PM -0800, Ross Boylan wrote: > Is there a way to expose host file systems to the guests? NFS is a > possibility, but the VM's will be running various services that warn > not to use NFS. libvirt doesn't seem to provide the ability to expose > host file systems directly (as opposed to exposing raw block devices), > but I'm hoping I have missed something.
http://www.linux-kvm.org/page/9p_virtio I have no experience with it, so please evaluate it yourself. > I could run LVM inside the VM's; this would provide somewhat more > flexibility and disk snapshotting, though I'm not sure how I would > provide more total space to the VM in this scenario. To extend the space available to the guest in this scenario, you need to work layer by layer. On the host: - enlarge the logical volume containing the guest image In the guest sytem: - enlarge or add a partition containing a physical volume - pvresize or pvcreate/vgextend to enlarge the volume group - lvresize -r to enlarge the logical volume and the filesystem; or fsadm (same purpose) > Finally, could anyone clarify the VMs in this libvirt/KVM setup use > CPU and RAM resources? If I give a guest machine 4G of RAM does that > mean that memory is unavailable for other use by the host or other > guests? virt-manager has configuration for memory and maximum memory, > suggesting that at least some dynamic growth is possible. Likewise, > if the physical machine has 8 cores, could I run several VM's with 8 > cores each? My suspicion is that CPU's are shareable, but RAM is not, > but I don't know. Yes, CPUs are shareable. How many CPUs should be assigned to each guest depends on the number of guests and their CPU usage. I would assign all cores to a single guest only if the load is very light. With higher CPU load, guests should be assigned enough CPUs to keep all physical CPU cores busy, and maybe a little more to allow for scheduling flexibility. Above a certain number of CPUs assigned, you will just increase the scheduling overhead, but not gain better performance. RAM is shareable in theory, but current operating systems use up all available RAM as disk buffers, so some tuning may be necessary. One possibility is the current memory / maximum memory setting you mentioned, which needs a guest driver for ballooning. The guest driver reserves some memory from the guest OS for exclusive use (the difference max - current). It doesn't actually use that memory, but returns it to the host so it can be used elsewhere. I don't know if this RAM reassignment has been automated yet to change based on demand. > Thanks. > Ross Boylan > > P.S. I don't need to be able to make the changes while the VM's are > live, though the ability to do so would be handy. If you can take your VMs offline, there is another option for accessing the guest filesystems: http://libguestfs.org/ Regards, Mirko -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141220141352.GA4750@guitar.localdomain
