12:20 p.m.
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.
6:54 p.m.
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
2:47 a.m.
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(a)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
3:48 a.m.
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
4:32 a.m.
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
1614
days inactive
1615
days old
4 comments
3 participants
participants (3)
-
brent s. -
Marc Roos -
Pavel Hrdina