>> 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list