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