[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 03/13] libxl: provide a function to retrieve the xenstore domain id
On Thu, 2016-01-07 at 06:37 +0100, Juergen Gross wrote: > On 06/01/16 16:59, Ian Campbell wrote: > > On Fri, 2015-12-18 at 15:10 +0100, Juergen Gross wrote: > > > On 18/12/15 14:53, Andrew Cooper wrote: > > > > On 18/12/15 13:14, Juergen Gross wrote: > > > > > Add libxl_xenstore_domid() to obtain the domain id of the > > > > > xenstore > > > > > domain. > > > > > > > > > > Signed-off-by: Juergen Gross <jgross@xxxxxxxx> > > > > > > > > What are the expected semantics here? Would you expect it to return > > > > domid 0 for a traditional setup, or are you wanting to use it as a > > > > "does > > > > a xenstored domain exist" test? > > > > > > The latter. It will be used in patch 13 to decide which domain to > > > stop via "xl shutdown --all". > > > > ITYM "not stop". > > Well, yes, if you select which domains to stop you select which domains > are not stopped, too. :-) > > I don't mind either wording. :-) In the sense you meant I think you want "domains". > > libxl already has interfaces for getting info about a > > domain, libxl_domain_info libxl_list_domain etc, it seems like this > > property should be added to that data rather than introducing a special > > purpose API to get it. Especially given that xl shutdown already calls > > libxl_list_domain. > > Okay, I can change it that way. Thanks. > > I'm unsure if (lib)xl ought to be special casing XS in this way, as > > opposed > > to adding a more generic concept such as e.g. permanent domains, which > > would be true for the xs domain but also for other special domains in > > the > > future and could even be controlled by the user or toolstack (I'm > > thinking > > you might want to set the flag on a driver domain for example). > > The xs domain has to be handled separately, as it is needed to run in > order to be able to stop other domains in a clean way. > > In case dom0 reboot will be supported we need two different reboot > modes: one with a hypervisor reboot implying all domains will be > stopped (including the xs domain), and one without hypervisor reboot > implying that all domains not requiring dom0 to be up all time will > still be running after dom0 is up again. > > For stopping all domains before doing a hypervisor reboot, driver > domains should be stopped, too, but they should be stopped _after_ > all other domains. And even then the xs domain should be still > running when the driver domains are being stopped. So what we have is in effect some sort of reboot ordering or priority and a threshold depending on what sort of reboot the host as a whole is undergoing? > IMO the generic concept you are asking for should be added in a > separate patch handling stopping (and possibly rebooting) driver > domains in a clean way. Since libxl has a stable API once we add something we need to continue supporting it, so we cannot (easily/cleanly) switch an xs specific scheme into a generic one later. That argues then for supporting the XS case via the generic mechanism now, even if we don't implement the other cases. > > > Juergen > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxx > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |