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(a)redhat.com | virtualization library
http://libvirt.org