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