xl list -l doesn't work for incoming domain

xl list -l doesn't work for incoming domain

[Zhigang Wang]

Hi,

While doing VM migration, in the destination side:

   # xl list -l
    libxl: error: libxl.c:6535:libxl_retrieve_domain_configuration: fail to get domain configuration for domain 7
    [
        {
            "domid": 0,
            "config": {
                "c_info": {
                    "type": "pv",
                    "name": "Domain-0"
                },
                "b_info": {
                    "max_memkb": 876544,
                    "target_memkb": 876543,
                    "sched_params": {
    
                    },
                    "type.pv": {
    
                    }
                }
            }
        }
    ]
 
    # xl list
    Name                                          ID   Mem VCPUs      State   Time(s)
    Domain-0                                       0   856     4     r-----    2758.9
    0004fb00000600003f327a843a5f2b72--incoming     7   131     1     --p---       0.0

Testing on:

    commit 816f5bb1f0740be8355e1be6cc24edf09547d984
    Author: Ian Campbell <ian.campbell@citrix.com>
    Date:   Fri Oct 24 10:58:33 2014 +0100

Thanks,

Zhigang

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

[Wei Liu]

On Thu, Nov 06, 2014 at 02:14:42PM -0500, Zhigang Wang wrote:
> Hi,
> 
> While doing VM migration, in the destination side:
> 
>    # xl list -l
>     libxl: error: libxl.c:6535:libxl_retrieve_domain_configuration: fail to get domain configuration for domain 7
>     [
>         {
>             "domid": 0,
>             "config": {
>                 "c_info": {
>                     "type": "pv",
>                     "name": "Domain-0"
>                 },
>                 "b_info": {
>                     "max_memkb": 876544,
>                     "target_memkb": 876543,
>                     "sched_params": {
>     
>                     },
>                     "type.pv": {
>     
>                     }
>                 }
>             }
>         }
>     ]
>  
>     # xl list
>     Name                                          ID   Mem VCPUs      State   Time(s)
>     Domain-0                                       0   856     4     r-----    2758.9
>     0004fb00000600003f327a843a5f2b72--incoming     7   131     1     --p---       0.0
> 
> Testing on:
> 

What's the rune you used to migrate the domain? xl migrate? Why is the
domain paused?

What's inside /var/lib/xen?

What's the content of xenstore?

Wei.

>     commit 816f5bb1f0740be8355e1be6cc24edf09547d984
>     Author: Ian Campbell <ian.campbell@citrix.com>
>     Date:   Fri Oct 24 10:58:33 2014 +0100
> 
> Thanks,
> 
> Zhigang

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

[Zhigang Wang]

On 11/07/2014 05:47 AM, Wei Liu wrote:
> On Thu, Nov 06, 2014 at 02:14:42PM -0500, Zhigang Wang wrote:
>> Hi,
>>
>> While doing VM migration, in the destination side:
>>
>>    # xl list -l
>>     libxl: error: libxl.c:6535:libxl_retrieve_domain_configuration: fail to get domain configuration for domain 7
>>     [
>>         {
>>             "domid": 0,
>>             "config": {
>>                 "c_info": {
>>                     "type": "pv",
>>                     "name": "Domain-0"
>>                 },
>>                 "b_info": {
>>                     "max_memkb": 876544,
>>                     "target_memkb": 876543,
>>                     "sched_params": {
>>     
>>                     },
>>                     "type.pv": {
>>     
>>                     }
>>                 }
>>             }
>>         }
>>     ]
>>  
>>     # xl list
>>     Name                                          ID   Mem VCPUs      State   Time(s)
>>     Domain-0                                       0   856     4     r-----    2758.9
>>     0004fb00000600003f327a843a5f2b72--incoming     7   131     1     --p---       0.0
>>
>> Testing on:
>>
> 
> What's the rune you used to migrate the domain? xl migrate? Why is the
> domain paused?

The domain is under migrating, so the destination side it's paused. When migration finish,
it will become running.

FYI: the domain migration will success.

> What's inside /var/lib/xen?

# xl list
Name                                        ID   Mem VCPUs	State	Time(s)
Domain-0                                     0   856     4     r-----    1669.2
0004fb0000060000834f0ecf044b2219--incoming     3   700     0     --p---       0.0

# ls /var/lib/xen
qemu-resume.3  userdata-d.0.00000000-0000-0000-0000-000000000000.libxl-json  userdata-d.11.0004fb00-0006-0000-eadd-3c2eb729617a.libxl-json  xenpaging

It seems no userdata for this domain.

> What's the content of xenstore?

# xenstore-ls  -f
/local = ""
/local/domain = ""
/local/domain/0 = ""
/local/domain/0/domid = "0"
/local/domain/0/name = "Domain-0"
/local/domain/0/device-model = ""
/local/domain/0/device-model/0 = ""
/local/domain/0/device-model/0/state = "running"
/local/domain/0/memory = ""
/local/domain/0/memory/target = "876544"
/local/domain/0/memory/static-max = "876544"
/local/domain/0/memory/freemem-slack = "628980"
/local/domain/0/libxl = ""
/local/domain/0/libxl/disable_udev = "1"
/local/domain/3 = ""
/local/domain/3/vm = "/vm/0004fb00-0006-0000-834f-0ecf044b2219"
/local/domain/3/name = "0004fb0000060000834f0ecf044b2219--incoming"
/local/domain/3/cpu = ""
/local/domain/3/memory = ""
/local/domain/3/device = ""
/local/domain/3/device/suspend = ""
/local/domain/3/device/suspend/event-channel = ""
/local/domain/3/control = ""
/local/domain/3/control/shutdown = ""
/local/domain/3/control/platform-feature-multiprocessor-suspend = "1"
/local/domain/3/control/platform-feature-xs_reset_watches = "1"
/local/domain/3/data = ""
/vm = ""
/vm/0004fb00-0006-0000-834f-0ecf044b2219 = ""
/vm/0004fb00-0006-0000-834f-0ecf044b2219/uuid = "0004fb00-0006-0000-834f-0ecf044b2219"
/vm/0004fb00-0006-0000-834f-0ecf044b2219/name = "0004fb0000060000834f0ecf044b2219--incoming"
/libxl = ""
/libxl/3 = ""

Thanks,

Zhigang

> Wei.
> 
>>     commit 816f5bb1f0740be8355e1be6cc24edf09547d984
>>     Author: Ian Campbell <ian.campbell@citrix.com>
>>     Date:   Fri Oct 24 10:58:33 2014 +0100
>>
>> Thanks,
>>
>> Zhigang

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

[Wei Liu]

On Fri, Nov 07, 2014 at 11:34:33AM -0500, Zhigang Wang wrote:
> On 11/07/2014 05:47 AM, Wei Liu wrote:
> > On Thu, Nov 06, 2014 at 02:14:42PM -0500, Zhigang Wang wrote:
> >> Hi,
> >>
> >> While doing VM migration, in the destination side:
> >>
> >>    # xl list -l
> >>     libxl: error: libxl.c:6535:libxl_retrieve_domain_configuration: fail to get domain configuration for domain 7
> >>     [
> >>         {
> >>             "domid": 0,
> >>             "config": {
> >>                 "c_info": {
> >>                     "type": "pv",
> >>                     "name": "Domain-0"
> >>                 },
> >>                 "b_info": {
> >>                     "max_memkb": 876544,
> >>                     "target_memkb": 876543,
> >>                     "sched_params": {
> >>     
> >>                     },
> >>                     "type.pv": {
> >>     
> >>                     }
> >>                 }
> >>             }
> >>         }
> >>     ]
> >>  
> >>     # xl list
> >>     Name                                          ID   Mem VCPUs      State   Time(s)
> >>     Domain-0                                       0   856     4     r-----    2758.9
> >>     0004fb00000600003f327a843a5f2b72--incoming     7   131     1     --p---       0.0
> >>
> >> Testing on:
> >>
> > 
> > What's the rune you used to migrate the domain? xl migrate? Why is the
> > domain paused?
> 
> The domain is under migrating, so the destination side it's paused. When migration finish,
> it will become running.
> 
> FYI: the domain migration will success.
> 

I see. At that point the configuration was not available, yet. After the
domain is successfully migrated, the configuration should be available.

I think a domain under construction without domain configuration is a
valid state. What do you think?

Wei.

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

[Ian Campbell]

On Mon, 2014-11-10 at 12:35 +0000, Wei Liu wrote:
> On Fri, Nov 07, 2014 at 11:34:33AM -0500, Zhigang Wang wrote:
> > On 11/07/2014 05:47 AM, Wei Liu wrote:
> > > On Thu, Nov 06, 2014 at 02:14:42PM -0500, Zhigang Wang wrote:
> > >> Hi,
> > >>
> > >> While doing VM migration, in the destination side:
> > >>
> > >>    # xl list -l
> > >>     libxl: error: libxl.c:6535:libxl_retrieve_domain_configuration: fail to get domain configuration for domain 7
> > >>     [
> > >>         {
> > >>             "domid": 0,
> > >>             "config": {
> > >>                 "c_info": {
> > >>                     "type": "pv",
> > >>                     "name": "Domain-0"
> > >>                 },
> > >>                 "b_info": {
> > >>                     "max_memkb": 876544,
> > >>                     "target_memkb": 876543,
> > >>                     "sched_params": {
> > >>     
> > >>                     },
> > >>                     "type.pv": {
> > >>     
> > >>                     }
> > >>                 }
> > >>             }
> > >>         }
> > >>     ]
> > >>  
> > >>     # xl list
> > >>     Name                                          ID   Mem VCPUs      State   Time(s)
> > >>     Domain-0                                       0   856     4     r-----    2758.9
> > >>     0004fb00000600003f327a843a5f2b72--incoming     7   131     1     --p---       0.0
> > >>
> > >> Testing on:
> > >>
> > > 
> > > What's the rune you used to migrate the domain? xl migrate? Why is the
> > > domain paused?
> > 
> > The domain is under migrating, so the destination side it's paused. When migration finish,
> > it will become running.
> > 
> > FYI: the domain migration will success.
> > 
> 
> I see. At that point the configuration was not available, yet. After the
> domain is successfully migrated, the configuration should be available.
> 
> I think a domain under construction without domain configuration is a
> valid state. What do you think?

Can we write a stub json file at the beginning of migrate receive, a bit
like we do on create?

Otherwise code like xl list is going to have start special casing
domains which have no json, which we've tried hard to avoid I think.

Ian.

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

[Wei Liu]

On Mon, Nov 10, 2014 at 12:38:53PM +0000, Ian Campbell wrote:
> On Mon, 2014-11-10 at 12:35 +0000, Wei Liu wrote:
> > On Fri, Nov 07, 2014 at 11:34:33AM -0500, Zhigang Wang wrote:
> > > On 11/07/2014 05:47 AM, Wei Liu wrote:
> > > > On Thu, Nov 06, 2014 at 02:14:42PM -0500, Zhigang Wang wrote:
> > > >> Hi,
> > > >>
> > > >> While doing VM migration, in the destination side:
> > > >>
> > > >>    # xl list -l
> > > >>     libxl: error: libxl.c:6535:libxl_retrieve_domain_configuration: fail to get domain configuration for domain 7
> > > >>     [
> > > >>         {
> > > >>             "domid": 0,
> > > >>             "config": {
> > > >>                 "c_info": {
> > > >>                     "type": "pv",
> > > >>                     "name": "Domain-0"
> > > >>                 },
> > > >>                 "b_info": {
> > > >>                     "max_memkb": 876544,
> > > >>                     "target_memkb": 876543,
> > > >>                     "sched_params": {
> > > >>     
> > > >>                     },
> > > >>                     "type.pv": {
> > > >>     
> > > >>                     }
> > > >>                 }
> > > >>             }
> > > >>         }
> > > >>     ]
> > > >>  
> > > >>     # xl list
> > > >>     Name                                          ID   Mem VCPUs      State   Time(s)
> > > >>     Domain-0                                       0   856     4     r-----    2758.9
> > > >>     0004fb00000600003f327a843a5f2b72--incoming     7   131     1     --p---       0.0
> > > >>
> > > >> Testing on:
> > > >>
> > > > 
> > > > What's the rune you used to migrate the domain? xl migrate? Why is the
> > > > domain paused?
> > > 
> > > The domain is under migrating, so the destination side it's paused. When migration finish,
> > > it will become running.
> > > 
> > > FYI: the domain migration will success.
> > > 
> > 
> > I see. At that point the configuration was not available, yet. After the
> > domain is successfully migrated, the configuration should be available.
> > 
> > I think a domain under construction without domain configuration is a
> > valid state. What do you think?
> 
> Can we write a stub json file at the beginning of migrate receive, a bit
> like we do on create?
> 

No, we don't generate stub for normal domain at the moment.

Whether we should do it or not, it depends on whether we want libxl user
to see incomplete (and certainly incorrect) domain configuration. I
think not, because libxl user doesn't know how to distinguish stub
(invalid) configuration from a valid one.

> Otherwise code like xl list is going to have start special casing
> domains which have no json, which we've tried hard to avoid I think.
> 

>From xl's (and other tools on the same level) point of view, that means
invocation of library function fails, which it should always be ready to
cope with.

Wei.

> Ian.

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

[Ian Campbell]

On Mon, 2014-11-10 at 13:54 +0000, Wei Liu wrote:
> > Can we write a stub json file at the beginning of migrate receive, a bit
> > like we do on create?
> > 
> 
> No, we don't generate stub for normal domain at the moment.

Oh, I thought we did.

SO what happens if someone runs "xl list" while a domain create is in
progress? 

> Whether we should do it or not, it depends on whether we want libxl user
> to see incomplete (and certainly incorrect) domain configuration. I
> think not, because libxl user doesn't know how to distinguish stub
> (invalid) configuration from a valid one.
> 
> > Otherwise code like xl list is going to have start special casing
> > domains which have no json, which we've tried hard to avoid I think.
> > 
> 
> From xl's (and other tools on the same level) point of view, that means
> invocation of library function fails, which it should always be ready to
> cope with.

So your opinion is that the bug is the "libxl: error:
libxl.c:6535:libxl_retrieve_domain_configuration: fail to get domain
configuration for domain 7" message which should be removed?

I'd be happy enough with domain 7 being listed with an empty cfg in that
case.

Ian.

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

[Wei Liu]

On Mon, Nov 10, 2014 at 02:05:49PM +0000, Ian Campbell wrote:
> On Mon, 2014-11-10 at 13:54 +0000, Wei Liu wrote:
> > > Can we write a stub json file at the beginning of migrate receive, a bit
> > > like we do on create?
> > > 
> > 
> > No, we don't generate stub for normal domain at the moment.
> 
> Oh, I thought we did.
> 

We only generate stub for Dom0.

> SO what happens if someone runs "xl list" while a domain create is in
> progress? 
> 

It works the same as before. The "short" list doesn't relies on
libxl_retrieve_domain_configuration.  Now it's only "xl list -l" doesn't
have output.

> > Whether we should do it or not, it depends on whether we want libxl user
> > to see incomplete (and certainly incorrect) domain configuration. I
> > think not, because libxl user doesn't know how to distinguish stub
> > (invalid) configuration from a valid one.
> > 
> > > Otherwise code like xl list is going to have start special casing
> > > domains which have no json, which we've tried hard to avoid I think.
> > > 
> > 
> > From xl's (and other tools on the same level) point of view, that means
> > invocation of library function fails, which it should always be ready to
> > cope with.
> 
> So your opinion is that the bug is the "libxl: error:
> libxl.c:6535:libxl_retrieve_domain_configuration: fail to get domain
> configuration for domain 7" message which should be removed?
> 

I think so. This error message is red-herring. The caller knows best
what to do with the error.

> I'd be happy enough with domain 7 being listed with an empty cfg in that
> case.
> 

OK.

Wei.

> Ian.

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

[Zhigang Wang]

On 11/10/2014 07:35 AM, Wei Liu wrote:
> I see. At that point the configuration was not available, yet. After the
> domain is successfully migrated, the configuration should be available.
> 
> I think a domain under construction without domain configuration is a
> valid state. What do you think?

Here is my thought:

1. In this design, if I watch xenstore @introduceDomain, it will not been
   triggered until migration finish.

2. Because we have multiple places (hypervisor, xenstore, /var/lib/xen) holding
   domain state, we need to define what does it mean by "VM started".

3. It looks like a inconsistent state and we may want to eliminate or keep
   it as short as possible.

Thanks,

Zhigang

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

[Wei Liu]

On Mon, Nov 10, 2014 at 10:01:22AM -0500, Zhigang Wang wrote:
> On 11/10/2014 07:35 AM, Wei Liu wrote:
> > I see. At that point the configuration was not available, yet. After the
> > domain is successfully migrated, the configuration should be available.
> > 
> > I think a domain under construction without domain configuration is a
> > valid state. What do you think?
> 
> Here is my thought:
> 
> 1. In this design, if I watch xenstore @introduceDomain, it will not been
>    triggered until migration finish.
> 

OK. What in this design makes behavior different than before? Are you
suggesting "xl list -l" has something to do with your xenstore watch? I
don't think I can get this.

My guess is that, you have some tool that watches @introduceDomain,
which happens *before* the domain creation is finished. And your tool
needs to get domain information once your watch fires.  Here with this
design, your tool cannot get the correct information until migration is
finished. Am I right?

However, in previous design, even if you manage to get configuration
before migration is finished, I don't think that configuration reflects
the true configuration of that domain. It's conceptually bogus.

In any case, if you look at xenstore code, XS_INTRODUCE doesn't mean a
domain is started, so using it for that purpose would be wrong.

> 2. Because we have multiple places (hypervisor, xenstore, /var/lib/xen) holding
>    domain state, we need to define what does it mean by "VM started".
> 

If my above analysis is correct, will some kind of @startDomain event solve
your problem?

But this involves making changes to Xenstore protocol. Let's not go into
details until we make sure your requirement is well understood.

Wei.

> 3. It looks like a inconsistent state and we may want to eliminate or keep
>    it as short as possible.
> 
> Thanks,
> 
> Zhigang

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

[Zhigang Wang]

On 11/10/2014 10:25 AM, Wei Liu wrote:
> On Mon, Nov 10, 2014 at 10:01:22AM -0500, Zhigang Wang wrote:
>> On 11/10/2014 07:35 AM, Wei Liu wrote:
>>> I see. At that point the configuration was not available, yet. After the
>>> domain is successfully migrated, the configuration should be available.
>>>
>>> I think a domain under construction without domain configuration is a
>>> valid state. What do you think?
>>
>> Here is my thought:
>>
>> 1. In this design, if I watch xenstore @introduceDomain, it will not been
>>    triggered until migration finish.
>>
> 
> OK. What in this design makes behavior different than before? Are you
> suggesting "xl list -l" has something to do with your xenstore watch? I
> don't think I can get this.
> 
> My guess is that, you have some tool that watches @introduceDomain,
> which happens *before* the domain creation is finished. And your tool
> needs to get domain information once your watch fires.  Here with this
> design, your tool cannot get the correct information until migration is
> finished. Am I right?
> 
> However, in previous design, even if you manage to get configuration
> before migration is finished, I don't think that configuration reflects
> the true configuration of that domain. It's conceptually bogus.
> 
> In any case, if you look at xenstore code, XS_INTRODUCE doesn't mean a
> domain is started, so using it for that purpose would be wrong.
> 
>> 2. Because we have multiple places (hypervisor, xenstore, /var/lib/xen) holding
>>    domain state, we need to define what does it mean by "VM started".
>>
> 
> If my above analysis is correct, will some kind of @startDomain event solve
> your problem?
> 
> But this involves making changes to Xenstore protocol. Let's not go into
> details until we make sure your requirement is well understood.

We do currently watch xenstore @introduceDomain for VM start.

I thought the @introduceDomain behavior is different than xm/xend,
but I just did a test and I was wrong.

xm/xend also trigger @introduceDomain until domain migration finish. (but before
@introduceDomain, all the VM xenstore entries are already there.)

Right now, I'm all set if we fix the xl list -l issue during migration.

Thanks,

Zhigang

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

[Wei Liu]

On Mon, Nov 10, 2014 at 12:08:18PM -0500, Zhigang Wang wrote:
> On 11/10/2014 10:25 AM, Wei Liu wrote:
> > On Mon, Nov 10, 2014 at 10:01:22AM -0500, Zhigang Wang wrote:
> >> On 11/10/2014 07:35 AM, Wei Liu wrote:
> >>> I see. At that point the configuration was not available, yet. After the
> >>> domain is successfully migrated, the configuration should be available.
> >>>
> >>> I think a domain under construction without domain configuration is a
> >>> valid state. What do you think?
> >>
> >> Here is my thought:
> >>
> >> 1. In this design, if I watch xenstore @introduceDomain, it will not been
> >>    triggered until migration finish.
> >>
> > 
> > OK. What in this design makes behavior different than before? Are you
> > suggesting "xl list -l" has something to do with your xenstore watch? I
> > don't think I can get this.
> > 
> > My guess is that, you have some tool that watches @introduceDomain,
> > which happens *before* the domain creation is finished. And your tool
> > needs to get domain information once your watch fires.  Here with this
> > design, your tool cannot get the correct information until migration is
> > finished. Am I right?
> > 
> > However, in previous design, even if you manage to get configuration
> > before migration is finished, I don't think that configuration reflects
> > the true configuration of that domain. It's conceptually bogus.
> > 
> > In any case, if you look at xenstore code, XS_INTRODUCE doesn't mean a
> > domain is started, so using it for that purpose would be wrong.
> > 
> >> 2. Because we have multiple places (hypervisor, xenstore, /var/lib/xen) holding
> >>    domain state, we need to define what does it mean by "VM started".
> >>
> > 
> > If my above analysis is correct, will some kind of @startDomain event solve
> > your problem?
> > 
> > But this involves making changes to Xenstore protocol. Let's not go into
> > details until we make sure your requirement is well understood.
> 
> We do currently watch xenstore @introduceDomain for VM start.
> 
> I thought the @introduceDomain behavior is different than xm/xend,
> but I just did a test and I was wrong.
> 
> xm/xend also trigger @introduceDomain until domain migration finish. (but before
> @introduceDomain, all the VM xenstore entries are already there.)
> 
> Right now, I'm all set if we fix the xl list -l issue during migration.
> 

Just to be sure -- you're fine with "xl list -l" displaying no
configuration for an incoming domain, am I correct?

Wei.

> Thanks,
> 
> Zhigang

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

[Zhigang Wang]

On 11/10/2014 12:24 PM, Wei Liu wrote:
> On Mon, Nov 10, 2014 at 12:08:18PM -0500, Zhigang Wang wrote:
>> On 11/10/2014 10:25 AM, Wei Liu wrote:
>>> On Mon, Nov 10, 2014 at 10:01:22AM -0500, Zhigang Wang wrote:
>>>> On 11/10/2014 07:35 AM, Wei Liu wrote:
>>>>> I see. At that point the configuration was not available, yet. After the
>>>>> domain is successfully migrated, the configuration should be available.
>>>>>
>>>>> I think a domain under construction without domain configuration is a
>>>>> valid state. What do you think?
>>>>
>>>> Here is my thought:
>>>>
>>>> 1. In this design, if I watch xenstore @introduceDomain, it will not been
>>>>    triggered until migration finish.
>>>>
>>>
>>> OK. What in this design makes behavior different than before? Are you
>>> suggesting "xl list -l" has something to do with your xenstore watch? I
>>> don't think I can get this.
>>>
>>> My guess is that, you have some tool that watches @introduceDomain,
>>> which happens *before* the domain creation is finished. And your tool
>>> needs to get domain information once your watch fires.  Here with this
>>> design, your tool cannot get the correct information until migration is
>>> finished. Am I right?
>>>
>>> However, in previous design, even if you manage to get configuration
>>> before migration is finished, I don't think that configuration reflects
>>> the true configuration of that domain. It's conceptually bogus.
>>>
>>> In any case, if you look at xenstore code, XS_INTRODUCE doesn't mean a
>>> domain is started, so using it for that purpose would be wrong.
>>>
>>>> 2. Because we have multiple places (hypervisor, xenstore, /var/lib/xen) holding
>>>>    domain state, we need to define what does it mean by "VM started".
>>>>
>>>
>>> If my above analysis is correct, will some kind of @startDomain event solve
>>> your problem?
>>>
>>> But this involves making changes to Xenstore protocol. Let's not go into
>>> details until we make sure your requirement is well understood.
>>
>> We do currently watch xenstore @introduceDomain for VM start.
>>
>> I thought the @introduceDomain behavior is different than xm/xend,
>> but I just did a test and I was wrong.
>>
>> xm/xend also trigger @introduceDomain until domain migration finish. (but before
>> @introduceDomain, all the VM xenstore entries are already there.)
>>
>> Right now, I'm all set if we fix the xl list -l issue during migration.
>>
> 
> Just to be sure -- you're fine with "xl list -l" displaying no
> configuration for an incoming domain, am I correct?

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.

Or do you mean show some info of the domain, but lack some parts? If this the case,
here I attach an example and you can tell me which part will be missing:

# xl list -l
...

   {
        "domid": 4,
        "config": {
            "c_info": {
                "type": "pv",
                "name": "0004fb0000060000495324cb831d2664",
                "uuid": "0004fb00-0006-0000-4953-24cb831d2664",
                "run_hotplug_scripts": "True"
            },
            "b_info": {
                "max_vcpus": 2,
                "avail_vcpus": [
                    0,
                    1
                ],
                "max_memkb": 716800,
                "target_memkb": 716800,
                "shadow_memkb": 7648,
                "sched_params": {
                    "weight": 55000
                },
                "claim_mode": "True",
                "type.pv": {
                    "bootloader": "/usr/bin/pygrub"
                }
            },
            "disks": [
                {
                    "pdev_path": "/OVS/Repositories/0004fb0000030000abbd129258377a77/VirtualDisks/OVM_OL6U4_X86_64_PVM_2GB_UEK3_System.img",
                    "vdev": "xvda",
                    "format": "raw",
                    "readwrite": 1
                }
            ],
            "nics": [
                {
                    "devid": 0,
                    "mac": "00:21:f6:00:08:aa",
                    "bridge": "1011d6ac59"
                }
            ],
            "vfbs": [
                {
                    "devid": 0,
                    "vnc": {
                        "listen": "127.0.0.1",
                        "findunused": "True"
                    },
                    "sdl": {

                    },
                    "keymap": "en-us"
                }
            ],
            "vkbs": [
                {
                    "devid": 0
                }
            ],
            "on_reboot": "restart",
            "on_crash": "restart"
        }
    }

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.

Thanks,

Zhigang

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

[Wei Liu]

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.

[...]
> 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.

Since xenstore is not filled in when your tool looks at it, what makes
it different to wait a bit until migration finishes?

And, from your earlier reply, you're implying Xend fires
@introduceDomain at the same point as xl, but your tool can work with
it?

Wei.

> Thanks,
> 
> Zhigang

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

[Zhigang Wang]

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.

> 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?

Thanks,

Zhigang

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

[Wei Liu]

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?

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

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

[Zhigang Wang]

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

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

[Wei Liu]

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

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

[Zhigang Wang]

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

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

[Ian Campbell]

On Wed, 2014-11-12 at 09:36 -0500, Zhigang Wang wrote:
> 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.

Do you mean *before* @introduceDomain has triggered?

Ian.

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

[Zhigang Wang]

On 11/12/2014 09:40 AM, Ian Campbell wrote:
> On Wed, 2014-11-12 at 09:36 -0500, Zhigang Wang wrote:
>> 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.
> 
> Do you mean *before* @introduceDomain has triggered?

Yes, from my test. I didn't check the code logic yet.

I designed a test: set eth0 to low speed:

    $ ethtool -s eth0 speed 10 duplex half

and then migrate the VM. I can see the watch been triggered very late (couple minutes later after migration).

Thanks,

Zhigang

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

[Ian Campbell]

On Wed, 2014-11-12 at 09:48 -0500, Zhigang Wang wrote:
> On 11/12/2014 09:40 AM, Ian Campbell wrote:
> > On Wed, 2014-11-12 at 09:36 -0500, Zhigang Wang wrote:
> >> 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.
> > 
> > Do you mean *before* @introduceDomain has triggered?
> 
> Yes, from my test. I didn't check the code logic yet.

I think anything which is trying to inspect the state of a domain before
the corresponding @introduceDomain and expecting anything more complex
than the fact of that domain's existence is broken.

IOW the json associated with such a domain should be:
    {
        "domid": 123,
        "config": {}
    }
Or even
    {
        "domid": 123,
    }

No more or less.

> I designed a test: set eth0 to low speed:
> 
>     $ ethtool -s eth0 speed 10 duplex half
> 
> and then migrate the VM. I can see the watch been triggered very late (couple minutes later after migration).

A couple of minutes after *starting* the migration (i.e. the couple of
minutes is just the time taken to migrate) or a couple of minutes after
*finishing* the migration (which would be unfortunate and should be
investigated).

Ian.

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

[Zhigang Wang]

On 11/12/2014 09:52 AM, Ian Campbell wrote:
> On Wed, 2014-11-12 at 09:48 -0500, Zhigang Wang wrote:
>> On 11/12/2014 09:40 AM, Ian Campbell wrote:
>>> On Wed, 2014-11-12 at 09:36 -0500, Zhigang Wang wrote:
>>>> 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.
>>>
>>> Do you mean *before* @introduceDomain has triggered?
>>
>> Yes, from my test. I didn't check the code logic yet.
> 
> I think anything which is trying to inspect the state of a domain before
> the corresponding @introduceDomain and expecting anything more complex
> than the fact of that domain's existence is broken.
...
> IOW the json associated with such a domain should be:
>     {
>         "domid": 123,
>         "config": {}
>     }
> Or even
>     {
>         "domid": 123,
>     }
> 
> No more or less.

Here is the xl list output:

    # xl list
    Name                                          ID   Mem VCPUs      State   Time(s)
    Domain-0                                       0   856     4     r-----    2758.9
    0004fb00000600003f327a843a5f2b72--incoming     7   131     1     --p---       0.0

So we don't even want to match the two results?
 
>> I designed a test: set eth0 to low speed:
>>
>>     $ ethtool -s eth0 speed 10 duplex half
>>
>> and then migrate the VM. I can see the watch been triggered very late (couple minutes later after migration).
> 
> A couple of minutes after *starting* the migration (i.e. the couple of
> minutes is just the time taken to migrate) or a couple of minutes after
> *finishing* the migration (which would be unfortunate and should be
> investigated).

Sorry I didn't say it clearly. I mean couple minutes after the migration started, but before the migration finish.

>From xend code xend/XendDomainInfo.py:


    def completeRestore(self, store_mfn, console_mfn):

        log.debug("XendDomainInfo.completeRestore")

        self.store_mfn = store_mfn
        self.console_mfn = console_mfn

        self._introduceDomain()
        self.image = image.create(self, self.info)
        if self.image:
            self.image.createDeviceModel(True)
        self._storeDomDetails()
        self._registerWatches()
        self.refreshShutdown()

        log.debug("XendDomainInfo.completeRestore done")

It seems the self._introduceDomain() does called at the end of migration after memory transfer.

Thanks,

Zhigang

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

[Wei Liu]

On Wed, Nov 12, 2014 at 10:04:35AM -0500, Zhigang Wang wrote:
> On 11/12/2014 09:52 AM, Ian Campbell wrote:
> > On Wed, 2014-11-12 at 09:48 -0500, Zhigang Wang wrote:
> >> On 11/12/2014 09:40 AM, Ian Campbell wrote:
> >>> On Wed, 2014-11-12 at 09:36 -0500, Zhigang Wang wrote:
> >>>> 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.
> >>>
> >>> Do you mean *before* @introduceDomain has triggered?
> >>
> >> Yes, from my test. I didn't check the code logic yet.
> > 
> > I think anything which is trying to inspect the state of a domain before
> > the corresponding @introduceDomain and expecting anything more complex
> > than the fact of that domain's existence is broken.
> ...
> > IOW the json associated with such a domain should be:
> >     {
> >         "domid": 123,
> >         "config": {}
> >     }
> > Or even
> >     {
> >         "domid": 123,
> >     }
> > 
> > No more or less.
> 
> Here is the xl list output:
> 
>     # xl list
>     Name                                          ID   Mem VCPUs      State   Time(s)
>     Domain-0                                       0   856     4     r-----    2758.9
>     0004fb00000600003f327a843a5f2b72--incoming     7   131     1     --p---       0.0
> 
> So we don't even want to match the two results?
>  

I can make some change in *xl*, when it knows a guest is actually there
but doesn't have a valid result returned from the new API, it generates
a stub by transforming the short result to json output.

This may solve your problem short term. It matches my intention of
"caller knows best about what to do when that API call fails", and
make short and long output consistent to a degree. However, your
toolstack is still prone to breakage in the long run.

I would like to suggest you modify your toolstack so that it
properly uses the interface provided by *libxl*.  If the interface /
machinery you need doesn't exist we can talk about it on xen-devel.

It just occurs to me that the use of @introduceDomain is very hard to
justify (not blaming you, just I'm not sure whether it should be used
like that). In any case, the thread should not develop into a long
discussion on what means what and what happens before / after what.

Wei.

> >> I designed a test: set eth0 to low speed:
> >>
> >>     $ ethtool -s eth0 speed 10 duplex half
> >>
> >> and then migrate the VM. I can see the watch been triggered very late (couple minutes later after migration).
> > 
> > A couple of minutes after *starting* the migration (i.e. the couple of
> > minutes is just the time taken to migrate) or a couple of minutes after
> > *finishing* the migration (which would be unfortunate and should be
> > investigated).
> 
> Sorry I didn't say it clearly. I mean couple minutes after the migration started, but before the migration finish.
> 
> >From xend code xend/XendDomainInfo.py:
> 
> 
>     def completeRestore(self, store_mfn, console_mfn):
> 
>         log.debug("XendDomainInfo.completeRestore")
> 
>         self.store_mfn = store_mfn
>         self.console_mfn = console_mfn
> 
>         self._introduceDomain()
>         self.image = image.create(self, self.info)
>         if self.image:
>             self.image.createDeviceModel(True)
>         self._storeDomDetails()
>         self._registerWatches()
>         self.refreshShutdown()
> 
>         log.debug("XendDomainInfo.completeRestore done")
> 
> It seems the self._introduceDomain() does called at the end of migration after memory transfer.
> 
> Thanks,
> 
> Zhigang
> 

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

[Ian Campbell]

On Wed, 2014-11-12 at 10:04 -0500, Zhigang Wang wrote:
> On 11/12/2014 09:52 AM, Ian Campbell wrote:
> > On Wed, 2014-11-12 at 09:48 -0500, Zhigang Wang wrote:
> >> On 11/12/2014 09:40 AM, Ian Campbell wrote:
> >>> On Wed, 2014-11-12 at 09:36 -0500, Zhigang Wang wrote:
> >>>> 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.
> >>>
> >>> Do you mean *before* @introduceDomain has triggered?
> >>
> >> Yes, from my test. I didn't check the code logic yet.
> > 
> > I think anything which is trying to inspect the state of a domain before
> > the corresponding @introduceDomain and expecting anything more complex
> > than the fact of that domain's existence is broken.

I think I may have asked the wrong question there and then read the
answer in the context of the question I thought I'd asked. IOW most of
the rest of my mail was predicated on xend behaving differently to how
you've just explained via showing completeRestore().

It seems Wei is on the case so I'm just going to butt out...

Ian