[Libvir] virDomainConfigureDevice?

[Daniel P. Berrange]

On Wed, Jul 18, 2007 at 09:09:41AM -0400, Hugh Brock wrote:
> Daniel Veillard wrote:
> >On Wed, Jul 18, 2007 at 10:40:48AM +0100, Richard W.M. Jones wrote:
> >>Hugh Brock wrote:
> >>>I'm looking at ways to replicate xm block-configure at the libvirt 
> >>>level. xm block-configure is useful in that it allows you to change the 
> >>>back device for an HVM guest while the guest is still running; this 
> >>>permits you for example to change the CDROM without shutting down your 
> >>>guest or poking around in xenstore. Thus we can have an "eject" button 
> >>>on cdrom devices in virt-manager (or "eject" and "load" buttons, I 
> >>>guess), which we really need.
> >>>
> >>>The issue of course is that xm block-configure is specifically intended 
> >>>for block devices and takes arguments for the back device and the front 
> >>>device (among others). We would naturally prefer to accept a block of 
> >>>XML just as virDomainAttachDevice does and then parse it, determine if 
> >>>the device in question is of a type we can actually edit, determine if 
> >>>the new backdev is appropriate, and so on.
> >>Definitely this will be useful for USB ...
> >>
> >>I think the question is: Should we have another entry point 
> >>(virDomainConfigureDevice), or should we just modify 
> >>virDomainAttachDevice so that if it sees XML for a device which is 
> >>already attached it just modifies the device?
> >
> >  It was raised previously that it's okay to recreate an existing domain
> >to modify its configuration, then allowing virDomainAttachDevice to
> >override an existing definition would be consistent with this. Another
> >bonus point is one less entry point in the library and drivers.
> >
> Yes, that's right. I'm certainly in favor of reducing entry points, 
> although if we allow virDomainAttachDevice to also modify existing 
> devices, then it isn't quite named correctly... virDomainDefineDevice 
> would probably be better. Too bad I guess.
> 
> Next question is, how much protection do we want to build into the API? 
> Do we want to rely on whatever hypervisor we're talking to to, for 
> example, not allow us to change the back device for a disk on a running 
> guest, or do we need to protect against that ourselves?

Its impossible to protect against that. We have no knowledge about whether
the guest has mounted the disk.  The hypervisor *should* protect against
that - eg the guest ought to be able to 'lock' the virtual CD tray to 
prevent media changes. Likewise the paravirt disk driver ought to be able
to detect whether its frontend is mounted a fail. So leaving it upto the
HV to protect is best.

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