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@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/