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
Attachment:
signature.asc
Description: PGP signature
