From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Fehlig Subject: Re: [PATCH] Fix xm block/network-detach command Date: Mon, 06 Aug 2007 18:52:59 -0600 Message-ID: <46B7C26B.4080903@novell.com> References: <46B394A4.5060708@novell.com> 7C7D82041F01Bkanno.masaki@jp.fujitsu.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <46B394A4.5060708@novell.com> 7C7D82041F01Bkanno.masaki@jp.fujitsu.com List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Masaki Kanno Cc: xen-devel@lists.xensource.com, mats@planetcatfish.com List-Id: xen-devel@lists.xenproject.org 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. > Right. >> 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 http://xenbits2.xensource.com/xen-unstable.hg?rev/3196b63a7301 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 http://lists.xensource.com/archives/html/xen-devel/2007-08/msg00038.html 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 :-). Regards, Jim