With Virtual Machine Manager 1.4.3/libvirt 3.0.0-4+deb9u1, when I Shutdown -> Save on a VM, the save data is stored in '/var/lib/libvirt/qemu/save', even when the relevant VMs are stored in a storage pool outside of the root volume (so this starts to become a problem when the root volume runs out of space etc). On the virt-tools mailing list (https://www.redhat.com/archives/virt-tools-list/2018-January/msg00023.html) I was told that libvirt doesn't have the ability to configure this location - please can this be implemented? Ideally for me the save data would be stored alongside the VM data, but any directory configuration would allow me to place it on an appropriate storage volume. Thanks
The managed save feature stores the data in a libvirt controlled location and there's no incentive to change this. If you require more storage you can mount (or bind mount) a location with more storage into that location. Other option is to use the non-managed save API where the user is responsible for providing a path to the memory image to be saved. I'm not sure whether virt-manager supports the non-managed save though.
Thanks, so it sounds like a change request for virt-manager to at least have an option for the non-managed save API.
Just beware, non-managed save data are invisible to libvirt unless it's told to restore the domain from the file. In other words, just starting a domain saved in a non-managed manner will start it from scratch, which may result in data corruption. Especially if you later try to restore the domain from the previously saved data. This is likely one of the reasons why virt-manager does not support this functionality. And don't forget virt-manager does not have to run on the same machine where libvirtd and the domains are running, which would make selecting a right place to for save data harder. For managed save functionality libvirt has to be able to find the save data even if the domain XML gets changed so storing the save data somewhere based on anything from domain XML wouldn't work.
OK, so basically it sounds like the tool is too complicated for just a single person running VMs on one workstation (e.g. why am I not just using QEMU directly? I'm only here since virt-manager seemed to be the UI replacement for Virtualbox's GUI management tool, since moving from Virtualbox to QEMU/kvm).
Eric Blake has actually pointed out that an implementation of this request has already been requested in https://bugzilla.redhat.com/show_bug.cgi?id=1057800 , for anyone watching.
I don't think that's what you are looking for. The <transient/> disk feature allows to create a temporary disk overlay for a single run of a VM which is removed after the VM is stopped. That BZ only deals with the disk portion. The thing you've described requires to change where libvirt stores the memory image when you save a VM state (the memory image). <transient/> would not influence this in any way. As I've said in my first comment, it's actually pretty easy to use a bind-mount to attach a storage location with more storage to /var/lib/libvirt/qemu/save. Obviously you'll need to configure it permanently, otherwise the save images will be lost.
The point is that libvirt has multiple reasons to create storage files (save images, transient disk images, etc) - and while it must have sane default locations for all of those cases (where you can use bind mounts to redirect the storage according to a mounted filesystem), it would ALSO be nice to let the <domain> XML point to a storage pool that should be used for those cases instead of the default location(s). It may be easier to tweak XML configuration to point to a storage pool, particularly for network storage systems that may not be easily mountable into the file system for a bind-mount override of the default location.
Is a bind mount strictly required? Can't a symlink work too? Or just a traditional /etc/fstab mount for /var/lib/libvirt ? (In reply to Eric Blake from comment #7) > The point is that libvirt has multiple reasons to create storage files (save > images, transient disk images, etc) - and while it must have sane default > locations for all of those cases (where you can use bind mounts to redirect > the storage according to a mounted filesystem), it would ALSO be nice to let > the <domain> XML point to a storage pool that should be used for those cases > instead of the default location(s). It may be easier to tweak XML > configuration to point to a storage pool, particularly for network storage > systems that may not be easily mountable into the file system for a > bind-mount override of the default location. That's a lot of flexibility to put in libvirt for something that IMO doesn't have a compelling usecase at the moment. It would likely take more user work to setup a storage pool and point the domain XML at it, then it would to just handle this as a one off host side.
(In reply to Cole Robinson from comment #8) > Is a bind mount strictly required? Can't a symlink work too? Or just a > traditional /etc/fstab mount for /var/lib/libvirt ? Traditional mount will certainly work as well, but you need a separate filesystem for that which is impractical. BTW bind mounts are setup via /etc/fstab. Symlink should work as well, but I haven't tried that.