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: Tue, 11 Nov 2014 11:42:04 -0500 Message-ID: <54623C5C.6010504@oracle.com> References: <20141107104752.GB28188@zion.uk.xensource.com> <545CF499.8080606@oracle.com> <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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XoEWG-0007m4-Vd for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 16:42:17 +0000 In-Reply-To: <20141111152011.GA21312@zion.uk.xensource.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: Wei Liu Cc: xen-devel List-Id: xen-devel@lists.xenproject.org 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 ). >> >> 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