WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] 15142:78389dbb08bb and domain state

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] 15142:78389dbb08bb and domain state
From: John Levon <levon@xxxxxxxxxxxxxxxxx>
Date: Fri, 9 Nov 2007 04:49:58 +0000
Delivery-date: Thu, 08 Nov 2007 20:50:49 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.9i
With 3.1.2rc2:

bash-3.00# xm destroy sxc15
bash-3.00# xm list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0  6596     4     r-----    202.7
sxc13                                           1024     1                52.0
sxc15                                        6  1024     1     ------      0.0

It's the below changeset - no code to reset the domid exists any more.
It seems suboptimal to me? Shouldn't refreshShutdown (or somewhere,
anyway) remove domid?

I noticed this whilst having another, more serious problem: sometimes,
domains are never released, with a page still referenced (presumably?):

>>> xc.domain_getinfo(21, 1)
[{'paused': 0, 'cpu_time': 4895498373L, 'ssidref': 0, 'hvm': 0,
'shutdown_reason': 0, 'dying': 1, 'mem_kb': 4L, 'domid': 22,
'max_vcpu_id': 0, 'crashed': 0, 'running': 0, 'maxmem_kb': 1048576L,
'shutdown': 0, 'online_vcpus': 1, 'handle': [75, 158, 234, 68, 113, 241,
195, 238, 113, 125, 31, 198, 154, 74, 44, 188], 'blocked': 1}]

None of the user-space daemons seem to be the culprit. I'm still trying
to find out why xen thinks a page is still held. Note that this domain
is still using flip instead of copy - I know that's not the default,
could a bug there have crept in?

cheers
john

changeset:   15142:78389dbb08bb
user:        Steven Hand <steven@xxxxxxxxxxxxx>
date:        Fri Sep 14 16:33:34 2007 +0100
files:       tools/python/xen/xend/XendDomainInfo.py
description:
This patch fixes the issue with waiting for devices to disconnect during the end
stage of migration in Xend. The problem was cause by a deletion of the VM domain
ID which is used by testDevicecompleComplete ->deviceIDs->backendRoot() to get
the virtual backend device path. The virtual backend device path is used to
check if a device still exists in xenstore.

Signed-off-by: Yung Giang <yung.giang@xxxxxxxxx>
xen-unstable changeset: 15128:f6928d6369999cd063edd361d592579c2483196b
xen-unstable date: Tue May 22 15:32:50 2007 +0100


diff -r ac4a34b42602 -r 78389dbb08bb tools/python/xen/xend/XendDomainInfo.py
--- a/tools/python/xen/xend/XendDomainInfo.py   Wed May 16 10:42:07 2007 -0600
+++ b/tools/python/xen/xend/XendDomainInfo.py   Fri Sep 14 16:33:34 2007 +0100
@@ -1684,7 +1684,6 @@ class XendDomainInfo:
         try:
             if self.domid is not None:
                 xc.domain_destroy(self.domid)
-                self.domid = None
                 for state in DOM_STATES_OLD:
                     self.info[state] = 0
                 self._stateSet(DOM_STATE_HALTED)




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel