From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zhigang Wang Subject: Re: xl list -l doesn't work for incoming domain Date: Wed, 12 Nov 2014 10:04:35 -0500 Message-ID: <54637703.80906@oracle.com> References: <20141110123525.GD28360@zion.uk.xensource.com> <5460D342.9090308@oracle.com> <20141110152535.GA6110@zion.uk.xensource.com> <5460F102.9000100@oracle.com> <20141110172408.GA6588@zion.uk.xensource.com> <5460FBCA.5060302@oracle.com> <20141111110156.GA12465@zion.uk.xensource.com> <5462201C.302@oracle.com> <20141111152011.GA21312@zion.uk.xensource.com> <54623C5C.6010504@oracle.com> <20141112113156.GA28075@zion.uk.xensource.com> <54637076.7060708@oracle.com> <1415803209.1155.10.camel@citrix.com> <54637326.6090908@oracle.com> <1415803976.1155.14.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XoZTQ-0006XM-OD for xen-devel@lists.xenproject.org; Wed, 12 Nov 2014 15:04:44 +0000 In-Reply-To: <1415803976.1155.14.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: xen-devel , Wei Liu List-Id: xen-devel@lists.xenproject.org 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