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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

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
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel