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@xxxxxxxxxx | virtualization library http://libvirt.org
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list