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.
Daniel
--
Red Hat Virtualization group
http://redhat.com/virtualization/
Daniel Veillard | virtualization library
http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine
http://rpmfind.net/