[Libvir] [RFC] Device attach/detach on virsh

[Daniel P. Berrange]

On Thu, May 10, 2007 at 06:50:53PM +0900, Masayuki Sunou wrote:
> I want to add I/F to do attach/detatch of VIF and VBD to virsh with
> virDomainAttachDevice()/virDomainDetachDevice(). 
> And, I have two proposals about I/F for virsh to do attach/detach of VIF and VBD.
> 
> proposal 1:
>   Virsh catches MAC, bridge name, device name (physical,virtual), and another 
>   by the command option.
> 
>   ex)
>     ------------------------------------------------------------------
>     # virsh help attach(detach)-vif(vbd)
>       NAME
>         attach(detach)-vif(vbd) - attach(detach) vif(vbd)
> 
>       SYNOPSIS
>         * VIF
>         attach(detach)-vif <domain> <MAC> <bridge> ...
>           or
>         * VBD
>         attach(detach)-vbd <domain> <virt-dev> ...

I'd probably call them

  attach-disk
  attach-interface

to match the name used within the <devices> block so we don't have lots
of different terminolgy for the same concept.

> 
>       DESCRIPTION
>         Attach(Detach) vif(vbd) device
> 
>       OPTIONS
>         <domain>         domain name, id or uuid
> 
>         * VIF
>         <MAC>            MAC address of vif
>         <bridge>         bridge name of vif
>         ...
> 
>         * VBD
>         <virt-dev>       virtual device name of vbd
>         <phy-dev>        physical device name of vbd
>         ...
>     ------------------------------------------------------------------
> 
>   <advantage>
>     - I/F is easy to use than proposal 1. (Because the user does not have to
>       make XML)
>   <disadvantage>
>     - I/F increases because I/F of VIF and VBD becomes separate. (So, the
>       addition of I/F is necessary at any time for supporting devices other
>       than VIF and VBD. )

I think that's fine.

>     - Handling of optional analysis, handling of XML making are necessary
>       in virsh.c, and processing becomes complicated.

For attaching device's there'll be a variety of optional flags you'll
need to support. eg to specify the driver & subtype, file, phys, tap:aio,
tap:qcow, etc' to specify the front end type (floppy, disk, cdrom).

Some real world examples

  virsh attach-disk /dev/sda1 xvdc
  virsh attach-disk --driver phy /dev/sda1 xvdc
  virsh attach-disk --type cdrom --driver tap --subdriver aio /root/boot.iso hdc
  virsh attach-disk --driver file /var/lib/xen/data.img xvdd

Networking is more complicated because there are 8 (!) different ways to
connected up VMs so far. We could either have huge numbers of args, or
we could just support the two common cases (bridge, virtual network) and
say for more complex cases use full XML.

  virsh attach-interface bridge eth0
  virsh attach-interface --mac 02:23:44:e2:2 network default
  virsh attach-interface --target vnet3 network default

> proposal 2:
>   virsh catches a definition of a device by XML 
> 
>   ex)
>     ------------------------------------------------------------------
>     # virsh help attach(detach)-device
>       NAME
>         attach(detach)-device - attach(detach) device from an XML file
> 
>       SYNOPSIS
>         attach(detach)-device <domain> <file>
> 
>       DESCRIPTION
>         Attach(Detach) device from an XML <file>
> 
>       OPTIONS
>         <domain>         domain name, id or uuid
>         <file>           XML file of device description
>     ------------------------------------------------------------------
> 
>   <advantage>
>     - I/F is unified without affecting a device type. (I/F is simple)
>     - Handling of virsh.c is simple. (Optional analysis is not necessary)
>   <disadvantage>
>     - The user has to describe XML.(It is troublesome) 

I don't think we should consider this an either/or option - lets do both.
ie, have specific attach-disk/interface for convenience, and have the
generic attach-device  for broad support.

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|