> Hi all:
> Suppose we have a guest domain which is pvops, for example, rhel6.4.
>
> Steps to produce the problem:
> 1 start the guest by virDomainCreate()
> 2 the API returns before the guest domain fully available, which means,
the disks, network interfaces and some import services are not available inside
the guest.
> 3 we call virDomainShutdown() to shutdown the guest.
>
> Expected result:
> The guest got shutdown.
>
> The result in fact:
> Because the guest is not available when we call virDomainShutdown(),
it couldn't respond to our 'shutdown' xenstore request, the guest turns on
later, rather than shutting down.
I don't think this is unique to a pvops guest kernel, or even a xen stack. I see
the same behavior with qemu. 'virsh create dom.xml && virsh shutdown dom'
results in the guest kernel missing the shutdown event and booting anyhow. I
guess SeaBIOS could still be loading when the shutdown event is issued :-). The
virDomainShutdownFlags documentation even states "that the guest OS may
ignore
the request". In my example, the guest OS isn't even alive yet.
> So , the question is:
> In libxl_driver( xen-hypervisor environment), how can we tell that the
guest is available or not, and is it suitable to shutdown the guest at that
moment?
libxl has no API to determine if a guest OS has booted. In a qemu/kvm stack, I
suppose qemu-ga is the preferred way to know when a guest OS has booted, or
is
far enough along to respond to shutdown events.
One possible approach in xen, which is not supported by libvirt, would be to
monitor the state of a device frontend in xenstore. E.g. when
/local/domain/<domid>/device/vif/<vifid>/state reaches 4 (connected),
you'll at
least know the driver in the guest is up and running.
I've tried that way, but even the device state is not trustable, because inside the
guest, it calls "add_disk" after the device state changes to 4, and before it
could respond the 'shutdown' xenstore request, which takes a while to complete.
Regards,
Jim