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 > 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. This kind of information doesn't really belong in the domain XML. The domain XML is describing an instantiation of a VM on a particular machine. If you have a application managing a bunch of VMs & hosts across the data center you're not going to be relying on the hosts running the VMs as your master storage repository for information about a VM. You have to expect any host in the data center is expendible and can go away at any time. The management app will have its own storage database of some form where it keeps its master copy of all configs so it can re-deploy the VM to another host upon failure of a physical host. This is the logical place for asset / ownership data and any other metadata of this kind, along with the master copy of the VM configuration (which may or may not be stored in the libvirt XML format). The VM configuration need only be pushed out to individual hosts when a VM is deployed / run, and does not need to include asset / ownership metadata. Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list