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

Wed May 24 12:49:11 UTC 2017

On 05/05/17 15:50, Robby Workman wrote:
> On Thu, 4 May 2017 12:55:03 +0100
> Sebastian Arcus <s.arcus at open-t.co.uk> wrote:
> 
>> 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:
>>
>> 1. It is much less likely for users who might use the guests remotely
>> to loose work, as the machine state is suspended.
>>
>> 2. Guests stopped with 'managedsave' will start fine with the 'start'
>> command - so no need to change any settings anywhere else, and the
>> 'autostart' feature of libvirt will continue to work fine.
>>
>> 2. On my server, the 'managedsave' operation takes around 20 seconds
>> per guest, and it is more predictable in duration than a 'shutdown',
>> which depends on the OS in the guest, if it is installing updates etc.
>>
>> 4. The 'managedsave' command doesn't return immediately, so we can
>> wait for each guest in turn and know when it is done. Or ampersand
>> could be used on the command, and then just do a looped check on
>> 'virsh list' lower down, waiting for the 'managedsave' on all guests
>> to finish.
>>
>> 5. If my understanding is correct, the 'shutdown' command depends on
>> the guest implementing correctly and acting on ACPI commands, while a
>> 'managedsave' seems to be under the complete control of libvirt -
>> which means the script would work correctly out of the box with a
>> much wider variety of OS's and configurations on the guest side.
>>
>> If necessary, I suppose the script could also implement a
>> 'reboot_guests' separate command, for people to use it to reboot all
>> running guests - as the "stop" command wouldn't be performing a full
>> shutdown any more.
>>
>> Just a suggestion in case it helps. I'm already very happy with the
>> current script, as I used to have to write my own to shutdown
>> kvm/qemu guests :-)
> 
> 
> This seems like a reasonable change. Can you push it to a git
> repo/branch somewhere and send me a link, or else send me a
> patch(set) to merge?

With some delay, please find attached the suggested changes to the 
rc.libvirt script. I have made the following the amendments:

1. Increased the default timeout to 5 minutes (300 seconds). I think 
guests should be destroyed only as a last resort - as the risk of 
corrupting data is very high. If a quicker shutdown is needed - one 
should look at optimising or troubleshooting things, not destroying 
guests. I am half-tempted to suggest increasing this to 10 minutes actually.

2. Change the default behaviour of the "stop" option to do a managedsave 
on all running and paused guests - as this is safer for all guest 
operating systems - and the duration is more predictable (no Windows 
automatic updates to install during shutdown etc.)

3. Added a guests_shutdown option, for those preferring to do a full 
shutdown instead of a managedsave (not enough space on hdd to save ram 
images, for example). So rc.local_shutdown would contain:

     /etc/rc.d/rc.libvirt guests_shutdown
     /etc/rc.d/rc.libvirt stop

4. Added a guests_reboot option, to reboot all running guests. I find 
this really useful, as, for example, Windows guests need regular reboots 
to stop them from going bananas  - so an option to reboot all of them at 
once seems like a useful addition. This doesn't wait and doesn't have a 
timeout - just issues the command and exits. The idea is that this 
wouldn't be used during a reboot, so there is no need to check when the 
command has finished executing.

Note: when issuing the managedsave command, the guests go first through 
a 'paused' state, then they show up as 'shut off' in virsh --list. Thus 
it is impossible to tell between the guests which were already paused 
initially, and the ones in transition to the managedsave state, while 
waiting for the command to complete. Because of this, the only way to 
proceed is to issue a 'managedsave' on both running and already paused 
guests.

On the other hand, 'guests_shutdown' only acts on running guests - an 
ACPI shutdown command is unlikely to be acted on by a paused guest anyway.

I also suggest adding the following notes to libvirt-info:

"The enclosed rc.libvirt script will to a 'managedsave' on all running 
and paused guests when issuing 'rc.libvirt stop'. Please note that this 
saves the RAM of each guest to the host hdd (by default under 
/var/lib/libvirt/qemu/save) - so make sure enough space is available. If 
you prefer to perform a full shutdown on all running guests instead, 
issue a 'rc.libvirt guests_shutdown' followed by 'rc.libvirt shutdown'.

By default 'rc.libvirt stop' and 'rc.libvirt guests_shutdown' will wait 
a maximum of 5 minutes for all guests to shutdown, after which any 
guests still running will be destroyed. Adjust this to a suitable value 
for your system, as destroying a running guest carries a high risk of 
data loss!

There is also a 'guests_reboot' for rebooting all running guests."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rc.libvirt.diff
Type: text/x-patch
Size: 3202 bytes
Desc: not available
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20170524/17646f71/attachment.bin>