[libvirt] [FeatureRequest/RFC] non-volitile domain defines
I think I have already sent an email about this to the list, but no reply on this specific point. Libvirt is currently capable of storing storage, networks, the only thing that is really missing is the direct storage of domains. I wonder if a patch would be accepted that stores defined domains (live) to disk upon change. Some sort of dumpxml per define/attach/etc. when a domain is undefined the file is removed. Stefan
On Wed, Jul 23, 2008 at 03:16:57AM +0200, Stefan de Konink wrote:
I think I have already sent an email about this to the list, but no reply on this specific point.
Libvirt is currently capable of storing storage, networks, the only thing that is really missing is the direct storage of domains. I wonder if a patch would be accepted that stores defined domains (live) to disk upon change. Some sort of dumpxml per define/attach/etc. when a domain is undefined the file is removed.
I'm not sure I understand. I would not want domain configuration files to be stored to a specific place in the tree. This generates a duplication of data problem and also possibly a dependancy on the given hypervisor. The acquisition/ modification of domain data should relly go though the API or virsh dumpxml and define commands. But maybe i didn't understand... Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Wed, Jul 23, 2008 at 03:16:57AM +0200, Stefan de Konink wrote:
I think I have already sent an email about this to the list, but no reply on this specific point.
Libvirt is currently capable of storing storage, networks, the only thing that is really missing is the direct storage of domains. I wonder if a patch would be accepted that stores defined domains (live) to disk upon change. Some sort of dumpxml per define/attach/etc. when a domain is undefined the file is removed.
The storage of persistent configurations is implementation defined. With some drivers libvirt takes care of it directly, with others it is delegated to the underlying hypervisor specific tools. We're not going to replicate that in libvirt because it'll cause interoperability problems with tools which aren't libvirt based 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 :|
Daniel P. Berrange schreef:
On Wed, Jul 23, 2008 at 03:16:57AM +0200, Stefan de Konink wrote:
I think I have already sent an email about this to the list, but no reply on this specific point.
Libvirt is currently capable of storing storage, networks, the only thing that is really missing is the direct storage of domains. I wonder if a patch would be accepted that stores defined domains (live) to disk upon change. Some sort of dumpxml per define/attach/etc. when a domain is undefined the file is removed.
The storage of persistent configurations is implementation defined. With some drivers libvirt takes care of it directly, with others it is delegated to the underlying hypervisor specific tools. We're not going to replicate that in libvirt because it'll cause interoperability problems with tools which aren't libvirt based
DV: sorry, wrong webclient. 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. Stefan
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. 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 :|
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. But I think we already had that discussion. Stefan
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. 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 :|
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. Stefan
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 :|
On Wed, Jul 23, 2008 at 12:43:25PM +0200, Stefan de Konink wrote:
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. But I think we already had that discussion.
Yes that discussion had been raised quite a few time, and I think it's good to try to clear things up a bit: http://libvirt.org/intro.html that page is probably one of the oldest in libvirt documentation, and I set there what to me is the fundamentals of the project: "we can define the goal of libvirt: to provide the lowest possible generic and stable layer to manage domains on a node" a few more Node specific extensions have been adeed to this original picture like Network and Storage available for the Domains, but I think this clearly defines the scope of libvirt, and the intent is not to manage a cluster. This can be done on top, this is being done actually by many projects. I'm sorry but I don't want to try to extend libvirt in that direction, there is no reason to put the emphasis toward one specific management tool or setup. There are still quite a few things to be done to improve libvirt within the goal of the project, in addition of the constant evolution of hypervisors facilities. The promise we make to the users is that they need not to worry (too much) about low level changes, and can build their solutions on top. The other implicit promise which I'm fine making explicit is that libvirt won't make their life harder by growing outside the initial project goals and conflicting with their own way of actually managing the resources. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
participants (3)
-
Daniel P. Berrange -
Daniel Veillard -
Stefan de Konink