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

[Zhigang Wang <zhigang.x.wang@xxxxxxxxxx>]

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