On Thu, May 10, 2007 at 12:50:40PM -0400, Daniel Veillard wrote: > 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 Huh ? I didn't see anything in this proposal which was Xen-specific. The disks where being identified based on their backend path (eg /var/lib/xen/image/foo.img or /dev/sda4), while network cards were being identified based on their MAC address. Both of those are unique identifiers used by pretty much any virt system. > 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). MAC address. > > 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. Yeah, its utterly horrible for end users to use, but at the same time could be useful for automation / tools. 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 -=|