Feature request? Auto start vm upon next shutdown
Sometimes when you change the configuration, this configuration change will only be available after a shutdown. Not to have to monitor when the vm shuts down, to start it again. It could be nice to have libvirt start it one time. Something like: 1. change the network interface of a running guest 2. at the prompt of the virt-manager "Some changes may require a guest shutdown to take effect" introduce check box 'Auto start vm upon next shutdown' 3. shutdown the guest 4. after the guest completed shutdown, libvirt is automatically starting it again.
On 6/21/20 13:20, Marc Roos wrote:
Sometimes when you change the configuration, this configuration change will only be available after a shutdown. Not to have to monitor when the vm shuts down, to start it again. It could be nice to have libvirt start it one time. Something like:
1. change the network interface of a running guest 2. at the prompt of the virt-manager "Some changes may require a guest shutdown to take effect" introduce check box 'Auto start vm upon next shutdown' 3. shutdown the guest 4. after the guest completed shutdown, libvirt is automatically starting it again.
This took me a while because at first I thought you were talking about the vm automatically starting on libvirt invocation (autostart), but instead it sounds like you want a function to allow the user upon making a change to initiate a hypervisor-level restart (i.e. destroy then start). Correct? -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info
It is not a destroy. With some hardware changes you require the host to shutdown down and then start. The shutdown down is manually given either via some acpi request or from within the guest. When the guest is down, the 'host' recognizes this guest requires a one time start, and starts it. This should 'solve' that if you change hardware you have to wait for the guest to shutdown and then start the guest manually. I would not know what level this can best be implemented. -----Original Message----- From: brent s. [mailto:bts@square-r00t.net] Sent: maandag 22 juni 2020 1:54 To: libvirt-users@redhat.com Subject: Re: Feature request? Auto start vm upon next shutdown On 6/21/20 13:20, Marc Roos wrote:
Sometimes when you change the configuration, this configuration change
will only be available after a shutdown. Not to have to monitor when the vm shuts down, to start it again. It could be nice to have libvirt
start it one time. Something like:
1. change the network interface of a running guest 2. at the prompt of
the virt-manager "Some changes may require a guest shutdown to take effect" introduce check box 'Auto start vm upon next shutdown' 3. shutdown the guest 4. after the guest completed shutdown, libvirt is automatically starting it again.
This took me a while because at first I thought you were talking about the vm automatically starting on libvirt invocation (autostart), but instead it sounds like you want a function to allow the user upon making a change to initiate a hypervisor-level restart (i.e. destroy then start). Correct? -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info
On 6/22/20 03:47, Marc Roos wrote:
It is not a destroy. With some hardware changes you require the host to shutdown down and then start. The shutdown down is manually given either via some acpi request or from within the guest. When the guest is down, the 'host' recognizes this guest requires a one time start, and starts it.
So here's the problem- in order for hardware changes to be detected/applied, you actually *do* need a destroy[0] operation as I understand it (a "poweroff" finishes-ish with a destroy, as does the ACPI shutdown, as dues a guest shutdown, etc. but NOT a guest reboot- it bypasses the destroy, which is precisely why domains' hardware changes do not simply show up when a reboot is issued in the guest), in libvirt parlance, not a reboot. I strongly suspect I am grossly oversimplifying the above, but it should be close enough. In order to do what you propose above, one would need at the least: 1.) A flag for the domain specifying only a single reboot after the very next time it does some sort of shutdown. a.) I suspect this is already available, in SOME form, as domains will reboot once the install is marked as finished. Whether this is a full destroy/start operation or merely an ACPI reboot, I don't know. 2.) A polling system that looks for domains that are defined but not running ("destroyed"). Check for flag in #1 and, if present, start the domain and remove #1's flag. I do not believe this sort of polling exists; I believe domain status is done on-demand.
This should 'solve' that if you change hardware you have to wait for the guest to shutdown and then start the guest manually.
I would not know what level this can best be implemented.
See above; in order to apply new hardware without a destroy/start operation, major swathes of code would need to be rewritten - *and* the guest operating system needs to be able to recognize new hardware changes on the fly. Many do not like this as, with specialized exceptions, it does not happen on physical hardware. I can see potentially this being implemented into VirtIO, but again - it would require the guest OS' awareness of that. But without that guest OS' awareness, you will need (should) still need to perform a proper shutdown regardless of how the hypervisor implements hardware changing. [0] "destroy" in hypervisors does not mean "delete" - or, in livirt terminology, "undefine"; it means "make this domain not-active". it's the "true" opposite of a start operation. I recommend reading the virsh(1) manpage. -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info
On Mon, Jun 22, 2020 at 04:48:32AM -0400, brent s. wrote:
On 6/22/20 03:47, Marc Roos wrote:
It is not a destroy. With some hardware changes you require the host to shutdown down and then start. The shutdown down is manually given either via some acpi request or from within the guest. When the guest is down, the 'host' recognizes this guest requires a one time start, and starts it.
So here's the problem- in order for hardware changes to be detected/applied, you actually *do* need a destroy[0] operation as I understand it (a "poweroff" finishes-ish with a destroy, as does the ACPI shutdown, as dues a guest shutdown, etc. but NOT a guest reboot- it bypasses the destroy, which is precisely why domains' hardware changes do not simply show up when a reboot is issued in the guest), in libvirt parlance, not a reboot.
I strongly suspect I am grossly oversimplifying the above, but it should be close enough.
In order to do what you propose above, one would need at the least:
1.) A flag for the domain specifying only a single reboot after the very next time it does some sort of shutdown. a.) I suspect this is already available, in SOME form, as domains will reboot once the install is marked as finished. Whether this is a full destroy/start operation or merely an ACPI reboot, I don't know.
2.) A polling system that looks for domains that are defined but not running ("destroyed"). Check for flag in #1 and, if present, start the domain and remove #1's flag. I do not believe this sort of polling exists; I believe domain status is done on-demand.
There is no need for polling as libvirt provides events and one of them is a VM lifecycle. This is similar to what virt-manager does when installing a new VM. It creates two XML configurations where the first XML (used to install the VM) contains this bit: <on_reboot>destroy</on_reboot> which ensures that once the installation is done and the installer asks to reboot the VM is actually destroyed (the QEMU process is killed) and virt-manager starts the VM again with a different XML without installation data (like attached ISO image or kernel/initrd boot elements or PXE configuration and so on). virt-manager has to be running the whole time otherwise the VM will be just destroyed and there would be no process to automatically start it again. Now to make this work with the changes to HW when virt-manager shows the warning that the changes require shutting down the VM and starting it again there are two possible solutions: 1) Implement everything in virt-manager (not ideal) since virt-manager can be closed by user and the VM might be restarted when virt-manager is not running and we would have to save which VM to destroy and start again. 2) Add support to libvirt which would require two changes: - make the on_poweroff, on_reboot and on_crash elements editable for running VMs - introduce new value which would do the destroy&start operation With this approach any application using libvirt including virt-manager would simply update the <on_reboot> element and libvirt would take care of the rest. Pavel
participants (3)
-
brent s. -
Marc Roos -
Pavel Hrdina