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/
Home Products Support Community News


Re: [Xen-devel] [PATCH] Fix xm block/network-detach command

To: Masaki Kanno <kanno.masaki@xxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Fix xm block/network-detach command
From: Jim Fehlig <jfehlig@xxxxxxxxxx>
Date: Mon, 06 Aug 2007 18:52:59 -0600
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, mats@xxxxxxxxxxxxxxxxx
Delivery-date: Mon, 06 Aug 2007 17:50:53 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <46B394A4.5060708@xxxxxxxxxx> 7C7D82041F01Bkanno.masaki@xxxxxxxxxxxxxx
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>
References: <46B394A4.5060708@xxxxxxxxxx> 7C7D82041F01Bkanno.masaki@xxxxxxxxxxxxxx
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20060911)
Masaki Kanno wrote:
>> IMO, since xen itself now supports managed domains it should be possible
>> to independently change live and stored config. I should be able to feed
>> a starving domain but have it revert to default (define by me) settings
>> when reset. That said I think it will be considerable work, particularly
>> testing, to ensure this behavior across all resource types and xend
>> interfaces.
> I also think the work to need an effort. 
> When we changed the resources configuration of domain by xm commands, 
> most resources configuration of domain is given to the reset domain 
> without change.  AFAIK, only CPU affinity revert to default.


>> This changes behavior between block-attach and block-detach. In
>> block-detach, the device is removed from store and unplugged from domain
>> if live. For block-attach, the operation fails if domain is inactive. If
>> domain is active, device is plugged but not persisted to store.
> I tried xm block/network-attach command with xen-unstable CS:15672. 

Yep, sorry.  I tested this patch on a 3.1.0-based system missing your
earlier patch


With both patches, block-[attach|detach] behave symmetrically.  I found
no problems testing your patch on c/s 15672.

A comment about the patch:

+    def convertToDeviceNumber(self, devid):
+        try:
+            dev = int(devid)
+        except ValueError:
+            # devid is not a number but a string containing either
+            # device name (e.g. xvda or xvda:disk) or
+            # device_type/device_id (e.g. vbd/51728)
+            dev = type(devid) is str and devid.split('/')[-1] or None
+            if dev == None:
+                return None
+            try:
+                dev = int(dev)
+            except ValueError:
+                dev = dev.split(':')[0]
+                dev = blkdev_name_to_number(dev)
+        return dev

Can this be pushed into the DevController?  Seems like the individual
device controllers would be best equipped to determine validity of a
deviceid.  That's what I was trying to do with this patch


which I see is now in the staging tree as c/s 15689.  BTW, there a two
xml files included in that c/s that were not part of the patch I
submitted :-).


Xen-devel mailing list