[Libvir] virDomainConfigureDevice?

Hugh Brock hbrock at redhat.com
Wed Jul 18 13:32:04 UTC 2007


Daniel Veillard wrote:
> On Wed, Jul 18, 2007 at 09:09:41AM -0400, Hugh Brock wrote:
>> Daniel Veillard wrote:
>>>  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.
> 
> yeah, still open question though, I would be fine adding a change entry point.
> 
>> 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?
> 
> can we realistically do that ? And is that sensible ? Say we are changing
> a CD-Rom device, how would libvirt really check usage ? (the hypervisor might
> still keep a open fd on the file even if the domain does not use it at
> least until told to change to something else)
> 
>  I'm afraid those kind of checks are very unlikely to work correctly outside
> of the hypervisor itself.
> 

That's rather what I was thinking as I wrote the question. Fine, error 
checking will be limited to the usual "is the xml valid" stuff.

Does anyone else have an opinion on whether to overload 
virDomainAttachDevice for modifying existing devices, or on the other 
hand add a new entry point like virDomainModifyDevice?

--H

-- 
Red Hat Virtualization Group http://redhat.com/virtualization
Hugh Brock           | virt-manager http://virt-manager.org
hbrock at redhat.com    | virtualization library http://libvirt.org




More information about the libvir-list mailing list