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. [...] > <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. ) > - Handling of optional analysis, handling of XML making are necessary > in virsh.c, and processing becomes complicated. To me this proposal is not okay as-is because it looks completely tied to Xen. But maybe I didn't understand, suppose I use KVM what would be the vbd or vif parameter looking like ? We need at least to change the terminology i.e. replace vif and vbd terms, but I'm afraid One important problem is naming, suppose you want to remove a network device, how will you name that device ? Using a vif Xen device number is not proper in my opinion it makes it really hard for the user (i.e. you have to dig in Xen internal to find the number). > > 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 think that specifications that a user is easy to use (proposal 1) > are better. > Please, give me an opinion which proposal is better. it looks to me that only proposal 2 is not tied to a given engine and would work even if we add very different system with more complex devices. But I agree it's not perfect from a user point of view either. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/