[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.