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

[Jim Fehlig <jfehlig@novell.com>]

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