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