On 08/03/2017 06:38 PM, Philipp Hahn wrote:
Hello,
Am 03.08.2017 um 09:36 schrieb Michal Privoznik:
>
https://bugzilla.redhat.com/show_bug.cgi?id=1476866
>
> For some reason, we completely ignore <on_reboot/> setting for
> domains. The implementation is simply not there. It never was.
> However, things are slightly more complicated. QEMU sends us two
> RESET events on domain reboot. Fortunately, the event contains
> this 'guest' field telling us who initiated the reboot. And since
> we don't want to destroy the domain if the reset is initiated by
> a user, we have to ignore those events. Whatever, just look at
> the code.
White you are at "QEMU reset": From Xen I remember that on reboot a new
qemu-dm (Device Model) is created - if I remember correctly - for both
PV and HV.
For QEMU the old qemu process is reused and the reset is done by SeaBios
inside the VM. If would be cool if there was an option to kill the old
qemu process and start a new qemu process (with an updated
configuration) on reboot.
I sometimes have the situation where the libvirt part is done by one
group of admins, while the guest OS and everything within in VM is done
by some other group of persons. Currently they always have to coordinate
a time, where the internal group does initiate the guest OS shutdown and
the libvirt admins then updates the configuration and starts the VM again.
It would be nice if I could update the config "just now" and then tell
the OS group "just do the reboot when your schedule permits it - you
will then get your updates configuration automatically."
Or is this already there and I missed it?
I think this patch enables exactly that. The VM admins don't start the
domains by hand but probably have some SW that starts configured domains
whenever not running. E.g. if one domain crashes, the mgmt SW starts it
up again. With such SW in place this patch is exactly what's been missing.
Alternatively, we can introduce new <on_reboot/> target, say "reinit"
that would kill the qemu process and start a new one instead.
Michal