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 -=|