Masaki Kanno
2007-Aug-03 05:20 UTC
[Xen-devel] [PATCH] Fix xm block/network-detach command
Hi,
This patch fixes a few problem of xm block/network-detach command.
At first, when I tested xm block/network-detach command to a inactive
managed domain, I saw the following error messages.
# xm new /xen/vm1.conf
Using config file "/xen/vm1.conf".
# xm list --long vm1
(domain
<snip>
(device
(vif
(mac 00:16:3e:75:96:d8)
(uuid ebd29601-41ac-75de-87cd-2ae051fa8719)
)
)
(device
(vbd
(uuid 7572ae87-5706-217a-3fa5-f68496e147c1)
(bootable 1)
(driver paravirtualised)
(dev hda1)
(uname file:/xen/rhel4u2.root.img-vm1)
(mode w)
)
)
)
# xm block-detach vm1 hda1
Error: Device hda1 not connected
Usage: xm block-detach <Domain> <DevId> [-f|--force]
Destroy a domain''s virtual block device.
# xm network-detach vm1 0
Error: (22, ''Invalid argument, while reading
None/device/vif/0/backend'')
Usage: xm network-detach <Domain> <DevId> [-f|--force]
Destroy a domain''s virtual network device.
I was able to fix the problem of inactive managed domains by writing
a small patch. However, I found a other problem in xm block/network-
detach command when I tested xm block/network-detach command more.
The other problem is the same as the problem that Mats reported in
the following.
http://lists.xensource.com/archives/html/xen-devel/2007-08/msg00040.html
This patch fixes the other problem as follows.
- To remove device info, it waits for the backend path of the device
to be removed.
- It removes device info from domain info.
- It saves domain info to the config.sxp of the managed domain.
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
Best regards,
Kan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Jim Fehlig
2007-Aug-03 20:48 UTC
Re: [Xen-devel] [PATCH] Fix xm block/network-detach command
Masaki Kanno wrote:> Hi, > > This patch fixes a few problem of xm block/network-detach command. > > At first, when I tested xm block/network-detach command to a inactive > managed domain, I saw the following error messages. > > # xm new /xen/vm1.conf > Using config file "/xen/vm1.conf". > # xm list --long vm1 > (domain > <snip> > (device > (vif > (mac 00:16:3e:75:96:d8) > (uuid ebd29601-41ac-75de-87cd-2ae051fa8719) > ) > ) > (device > (vbd > (uuid 7572ae87-5706-217a-3fa5-f68496e147c1) > (bootable 1) > (driver paravirtualised) > (dev hda1) > (uname file:/xen/rhel4u2.root.img-vm1) > (mode w) > ) > ) > ) > # xm block-detach vm1 hda1 > Error: Device hda1 not connected > Usage: xm block-detach <Domain> <DevId> [-f|--force] > > Destroy a domain''s virtual block device. > # xm network-detach vm1 0 > Error: (22, ''Invalid argument, while reading None/device/vif/0/backend'') > Usage: xm network-detach <Domain> <DevId> [-f|--force] > > Destroy a domain''s virtual network device. > > > I was able to fix the problem of inactive managed domains by writing > a small patch.This brings up a broader question concerning managed domains. What is the behavior when changing config of a managed domain? a) - persist change to store and modify domain if live b) - explicitly change live config - explicitly change stored config Some of the xm commands support a). That would be behavior of block-detach with this patch. It appears Xen API supports b) given the *_live, plug, and unplug operations defined in the spec. I have noticed this to be the case for some resource types, but doubt it is consistent across all resource types - let alone both Xen API and legacy sxpr interfaces. 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.> However, I found a other problem in xm block/network- > detach command when I tested xm block/network-detach command more. > The other problem is the same as the problem that Mats reported in > the following. > > http://lists.xensource.com/archives/html/xen-devel/2007-08/msg00040.html >That patch did not cause any problems with save.> This patch fixes the other problem as follows. > - To remove device info, it waits for the backend path of the device > to be removed. > - It removes device info from domain info. > - It saves domain info to the config.sxp of the managed domain. >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. We need to agree on behavior when changing config of managed domains and then set out on the (perhaps time consuming) path of realizing that behavior. Thoughts? Jim _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Masaki Kanno
2007-Aug-06 11:52 UTC
Re: [Xen-devel] [PATCH] Fix xm block/network-detach command
Hi Jim, Mon Aug. 06 2007, Jim Fehlig wrote:>Masaki Kanno wrote: >> Hi, >> >> This patch fixes a few problem of xm block/network-detach command. >> >> At first, when I tested xm block/network-detach command to a inactive >> managed domain, I saw the following error messages. >> >> # xm new /xen/vm1.conf >> Using config file "/xen/vm1.conf". >> # xm list --long vm1 >> (domain >> <snip> >> (device >> (vif >> (mac 00:16:3e:75:96:d8) >> (uuid ebd29601-41ac-75de-87cd-2ae051fa8719) >> ) >> ) >> (device >> (vbd >> (uuid 7572ae87-5706-217a-3fa5-f68496e147c1) >> (bootable 1) >> (driver paravirtualised) >> (dev hda1) >> (uname file:/xen/rhel4u2.root.img-vm1) >> (mode w) >> ) >> ) >> ) >> # xm block-detach vm1 hda1 >> Error: Device hda1 not connected >> Usage: xm block-detach <Domain> <DevId> [-f|--force] >> >> Destroy a domain''s virtual block device. >> # xm network-detach vm1 0 >> Error: (22, ''Invalid argument, while reading None/device/vif/0/backend'') >> Usage: xm network-detach <Domain> <DevId> [-f|--force] >> >> Destroy a domain''s virtual network device. >> >> >> I was able to fix the problem of inactive managed domains by writing >> a small patch. > >This brings up a broader question concerning managed domains. What is >the behavior when changing config of a managed domain? > >a) >- persist change to store and modify domain if live > >b) >- explicitly change live config >- explicitly change stored config > >Some of the xm commands support a). That would be behavior of >block-detach with this patch. > >It appears Xen API supports b) given the *_live, plug, and unplug >operations defined in the spec. I have noticed this to be the case for >some resource types, but doubt it is consistent across all resource >types - let alone both Xen API and legacy sxpr interfaces. > >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.>> However, I found a other problem in xm block/network- >> detach command when I tested xm block/network-detach command more. >> The other problem is the same as the problem that Mats reported in >> the following. >> >> http://lists.xensource.com/archives/html/xen-devel/2007-08/msg00040.html >> > >That patch did not cause any problems with save. > >> This patch fixes the other problem as follows. >> - To remove device info, it waits for the backend path of the device >> to be removed. >> - It removes device info from domain info. >> - It saves domain info to the config.sxp of the managed domain. >> > >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. Could you see the attached file "xm_attach.log" ? If the domain is inactive, xm block/network-attach command succeed. And the device info is saved into config.sxp. If the domain is active, the device is plugged to the domain. And the device info is saved into config.sxp. My patch rolls back the proceeding of xm block/network-attach command. Best regard, Kan>We need to agree on behavior when changing config of managed domains and >then set out on the (perhaps time consuming) path of realizing that >behavior. > >Thoughts? >Jim > > >_______________________________________________ >Xen-devel mailing list >Xen-devel@lists.xensource.com >http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jim Fehlig
2007-Aug-07 00:52 UTC
Re: [Xen-devel] [PATCH] Fix xm block/network-detach command
Masaki Kanno wrote: <snip>>> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Masaki Kanno
2007-Aug-07 10:38 UTC
Re: [Xen-devel] [PATCH] Fix xm block/network-detach command
Hi Jim, Tue Aug. 07 2007, Jim Fehlig wrote: <snip>>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 patchI believe that I can do it.>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 :-).Maybe they are patches for CS:15688. Best regards, Kan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2007-Aug-07 10:40 UTC
Re: [Xen-devel] [PATCH] Fix xm block/network-detach command
On 7/8/07 11:38, "Masaki Kanno" <kanno.masaki@jp.fujitsu.com> wrote:>> 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 :-). > > Maybe they are patches for CS:15688.Looks like I forgot to hg addremove on 15688, yes. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel