Re: xl list -l doesn't work for incoming domain

[Zhigang Wang <zhigang.x.wang@oracle.com>]

On 11/12/2014 06:31 AM, Wei Liu wrote:
> 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.

For above I just want to give you an idea what we currently using for normal VM.

For VM under migration, please see below:

>> But during migration, I believe it's OK if some info is missing. Our high level
>> management stack will handle it.

Also I want clarify one thing: the @introduceDomain watch is triggered at the same
time for xm/xend and xl: when VM fully migrated.

The different between xm/xend and xl is: xend will populate destination side VM 
xenstore entries at the beginning of migration. So xm list -l will show almost
the same result as normal VM.

I think right now we can just add little wrapper in xl cli to let xl list -l show
some info we can get.

Then we have 3 cases in xl list -l:

1. Normal VM.
2. Dom0.
3. VM under migration in the destination side.

They all valid json and 2), 3) are subset of 1). I can accept this design for now.

Thanks,

Zhigang