On 11/11/2014 10:20 AM, Wei Liu wrote: > On Tue, Nov 11, 2014 at 09:41:32AM -0500, Zhigang Wang wrote: >> On 11/11/2014 06:01 AM, Wei Liu wrote: >>> On Mon, Nov 10, 2014 at 12:54:18PM -0500, Zhigang Wang wrote: >>> [...] >>>> Could you please explain what does "no configuration" means? >>>> >>>> Do you mean no info for the domain at all? If this is the case, it seems >>>> not consistent with xl list without -l. >>>> >>> >>> That means no configuration at all. I think a skeleton can be provided >>> at best (in xl level) to be consistent with "xl list", which should >>> include domid and domain name etc. Since nothing else exists in >>> xenstore yet, there's no point poking there. >> >> This approach should works for me. >> >>> [...] >>>> Currently we want our APIs to get domain info by invoking xl list -l, but >>>> we can change them to get necessary info from other places. >>>> >>> >>> Hmm... I don't think poking around in different places is a good idea. >>> This is prone to breakage in the future. >> >> I agree. >> >>> Since xenstore is not filled in when your tool looks at it, what makes >>> it different to wait a bit until migration finishes? >> >> The logic is: when migration started, high level management console will >> check >> destination side to make sure the VM is running there >> (currently call xl list -l <domain>). >> >> If I can get enough runtime info (even some are missing), I think it should >> be OK. >> > > What runtime info do you need?
Currently we need: info['domid'] info['config']['b_info']['avail_vcpus'] info['config']['c_info']['uuid'] info['config']['b_info']['target_memkb'] Also read vnc port from xenstore. We may add more. But during migration, I believe it's OK if some info is missing. Our high level management stack will handle it. Thanks, Zhigang > As I understand it's something in the long output -- otherwise you would > have used the short output already if you only need to check the > existence and / or state of a domain. > >>> And, from your earlier reply, you're implying Xend fires >>> @introduceDomain at the same point as xl, but your tool can work with >>> it? >> >> For xm/xend, VM xenstore entries already populated before @introduceDomain. >> "xm list -l" will show the right information. >> >> Anyone knows what prevents us from populating VM xenstore entries during >> migration in libxl? >> > > FWIW in libxl @introduceDomain is fired after domain is built, before > adding devices. If you're after device information, it's a bit late. > > Xend might have done it in different order. I don't know. > > Whether we can change libxl to do so, I'm not sure. But it's definitely > not 4.5 material. > > Wei. > >> Thanks, >> >> Zhigang _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
