Re: [RFC] Device attach/detach on virsh

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]