Re: [Xen-devel] xl list -l doesn't work for incoming domain

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Tue, Nov 11, 2014 at 11:42:04AM -0500, Zhigang Wang wrote:
> 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.  
> 

Unfortunately this won't work, as not everything you need is in xenstore
at that point (see the xenstore entries you posted). It's not something
that can be easily worked around in xl by creating a stub -- even the
stub needs to get its information from somewhere.

> We may add more.
> 

This also means even if we create a stub now, it's still prone to
breakage in the future.

I think the root cause of your problem is xend and libxl fires
@introduceDomain at different point (correct me if I'm wrong, because I
haven't looked at xend code, only inferred from your reply). It should
be fixed there, not patching xl.

Wei.

> 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel