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@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list