[Slackbuilds-users] Libvirt package - small change to /etc/rc.d/rc.libvirt

[Sebastian Arcus]

On 05/05/17 16:15, Matteo Bernardini wrote:
> 2017-05-04 13:55 GMT+02:00 Sebastian Arcus <s.arcus at open-t.co.uk>:
>> I have a small change to suggest for the /etc/rc.d/rc.libvirt script. The
>> script at the moment does a 'virsh shutdown <vm-name>' on all running
>> guests, and then, after waiting only 40 seconds, it destroys all guests
>> which are still running. I think in most circumstances this is very likely
>> to lead to corrupted guests because:
>>
>> 1. Many guests will take longer than 40 seconds to shutdown, specially if
>> they are Windows guests.
>> 2. Some Windows guests might be trying to install updates on shutdown, which
>> can take 10, 20 or even 60 minutes.
>> 3. If there are a number of guests running and the host is busy trying to
>> shut them all down at the same time, even Linux guests will still be in the
>> process of shutting down after 40 seconds.
>> 4. If it is a setup where users connect to guests remotely, it is possible
>> that people are in the middle of doing work which would be lost.
>>
>> Would it maybe be safer to do a 'virsh managedsave <vm-name>' on every
>> running guest instead? I can see many advantages to this option, including:
> 
> one potential gotcha that I can foresee with this approach might be
> that managedsave, creating a RAM image of the virtual machine, will
> need an amount of Gb of disk space in /var/lib/libvirt/qemu/save/ the
> same size of the RAM used by all the running virtual machines: on my
> 64 Gb virtualization server I don't have, for example, that amount of
> space in the root partition.
> I'm just thinking out loud, don't misunderstand me :)

Thank you for spotting that. I have submitted a patch which includes a 
"guests_shutdown" option - for those preferring to issue a full shutdown 
on all running guests before doing a /etc/rc.d/rc.libvirt stop (which 
otherwise would do a managedsave by default on all running and paused 
guests). Hopefully this will keep things flexible and safe and satisfy 
the needs of both types of setups :-)