On Wed, Jul 23, 2008 at 01:00:08PM +0200, Stefan de Konink wrote: > Daniel P. Berrange schreef: > >On Wed, Jul 23, 2008 at 12:43:25PM +0200, Stefan de Konink wrote: > >>Daniel P. Berrange schreef: > >>>On Wed, Jul 23, 2008 at 11:54:11AM +0200, Stefan de Konink wrote: > >>>>DP: Would a patch be accepted that makes this configurable for *all* > >>>>implementations? So that by after configuration a file is saved, and is > >>>>queried after the platform specific implementation doesn't list the > >>>>domain as defined? > >>>> > >>>>List Defined domains: > >>>>- Query current implementation > >>>>- If defined merge all non available domains. > >>>> > >>>>In principle what I want to see is that if a domain is not defined in > >>>>the specific hypervisor, the domain file can be queried. I know I can > >>>>implement this behavior in my own code, but I really thing this would > >>>>be a cool thing for more people. > >>>This doesn't make any sense. We have APIs for listing & defining > >>>inactive domains. The individual drivers implement these APIs according > >>>to the > >>>required API contract, and the underlying impl is not something which any > >>>application using libvirt need know or care about. If your application is > >>>relying on the inactive domains being stored in files it is broken. > >>Or you could say that libvirt is broken because it isn't able to > >>distribute the inactive domains across the network in a consistent way. > > > >No, because that is not libvirt's job. The goal of libvirt is to provide > >an API for managing virtualization capabilities on a host. Data center or > >network management is an application level problem, out of scope for > >libvirt. > > That calls for a libvirt-fork that does implement what is needed to > consistently providing a replicated pool of domains; call it > libvirt-datacenter-edition. I think it is the biggest non sense for > implementing shortcommings/management in kvm/qemu, but don't provide > these to the other hypervisors 'just because they implement it > theirselves locally'. > > It is non-trivial to provide a 'xenstored' for the complete network, > while it is relatively easy to put an NFS dir on the libvirt xml configs. This is an appliction specific use case which can be implemented outside of libvirt. All management apps which manage more than one host have a need for a global data store with details of all virtual machines. They do not all wish to store XML on NFS for this purpose - I know of apps using libvirt which store inactive VMs in SQL databases, LDAP directory and clustered/network filesystems. libvirt provides APIs sufficient to allow you to track global state in the manner most suitable to your application's needs without imposing a specific impl for cross-host management. Daniel -- |: Red Hat, Engineering, London -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