[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] libxl: error when destroying domain on NetBSD
On Fri, 2011-12-02 at 10:29 +0000, Roger Pau Monnà wrote: > 2011/12/2 Ian Campbell <Ian.Campbell@xxxxxxxxxx>: > > libxl_destroy_domain should be called with force = 1 in the main_destroy > > case, I suspect. Does that cause the scripts to be run? > > Well, with force = 1 hotplug scripts are executed, but devices are > still busy and they cannot be disconnected (mainly vnd). Also crashed > the server, but that's NetBSD buggy vnd driver problem. Seeing the > execution order in libxl_domain_destroy, shouldn't we first destroy > the domain (xc_domain_destroy) and then remove the devices? In the force case, yes, I expect so. In the non-force case you want to let the guest shutdown its devices gracefully so you would do devices first. However I'm not entirely sure that a non-forced libxl_domain_destroy makes much sense. The callsites are: * handle_domain_death: The guest has already shutdown at this point. Nothing graceful can happen. * create_domain: We have failed to start the guest, no chance of graceful shutdown. * destroy_domain: Semantics are explicitly the force case. * save_domain: Domain has already suspended. There's nothing which can be done gracefully. * migrate_domain: Already forced, domain is gone already, no chance of a graceful shutdown. * migrate_receive: Already forced, we have failed to receive the domain, no possibility of a graceful shutdown. * libxl_domain_create, on the failure path so no need for a graceful option. * libxl__destroy_device_model. Maybe this should be doing a graceful shutdown but in that case it should either be calling libxl_domain_shutdown or writing the qemu-dm control node and waiting, at which point after some timeout perhaps a forced shutdown would be appropriate. So it seems to me that the non-forced option in libxl_domain_destroy can be removed and we should just shoot the domain and then forcibly teardown the backends, running script as necessary. The only wrinkle is the stub device-model case but really that's already a special domain and should be treated as such. Does that make sense to anyone else? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |