On Wed, Apr 16, 2008 at 12:13:09PM +0100, John Levon wrote: > On Wed, Apr 16, 2008 at 03:58:16AM -0400, Daniel Veillard wrote: > > > > One thing we have in mind is driver/software version numbers. For > > > example, the control tools may change the domain configuration based on > > > whether a certain driver has the support for a new feature. If we > > > create the domain's xml with the driver information, we can make this > > > decision quickly, on the fly, in dom0. > > > > Taking the specific example of driver support I think it's far better to > > express that as part of the device description of the domain. > > There's a wider usage case though. Management tools can often need to > track assets, and the UUID is not necessarily sufficient for that. Tools Hum, why is UUID insufficient for tracking ? I understand that maintaining coherency and access to metadata is not easy, but I don't see why the UUID is insufficient to make the binding, or did I misunderstood ? > want to be able to associate textual descriptions of the asset, or > define ownership. All of these are higher-level values that don't > necessarily have any meaning to the v12n technology itself. More > crucially they can be specific to the management tool, and lack any > reasonable generalization. I agree. The point is that the XML used by libvirt for domains is a view of the domain sufficient to create it on the hypervisor and able to be recreated just from the hypervisor data. The fact that Xen embbeded some kind of database as part of the hypervisor and exposed it on the stack is just bad design taste IMHO and can't be generalized to all hypervisors. Of course there is a need higher in the stack to associate metadata with the domain instance, but the fact this can be put in the hypervisor is a Xen specific as far as I can tell, and I'm reluctant to put this in the libvirt XML format, because this is not hypervisor domain data, and would break portability as far as I can tell. 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