On 05/05/17 16:15, Matteo Bernardini wrote:
2017-05-04 13:55 GMT+02:00 Sebastian Arcus <s.ar...@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 :-)
_______________________________________________
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/
