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

[Masaki Kanno <kanno.masaki@xxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxx
>http://lists.xensource.com/xen-devel

Attachment: xm_attach.log
Description: Binary data

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