Re: [Libvir] RFC: get/set properties
On Tue, Apr 15, 2008 at 02:23:53PM -0700, Ryan Scott wrote: Daniel P. Berrange wrote: On Tue, Apr 15, 2008 at 11:31:32AM -0700, Ryan Scott wrote: I'd like to get some comments on the following... We would like to use libvirt to store some properties related to a domain. This can be done by adding a simple get/set API as follows: What are the properties ? I'm not really very enthusiastic about the idea of adding API / XML for generic key,value properties. I think it will quickly be abused as a way to add arbitrary, non-standardized hypervisor / driver specific configuration which would be better represented with explicit schema. 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. If it's about the Guest OS currently we only have a generic domain os type .../type having a version attribute there sounds reasonable. If it's about the emulated hardware, for example the number of crypto engine like in the lDOM description the proper place would under domain features While this information is related to domain configuration, it's not hypervisor-specific, so I'm not sure where else we would put it in the domain's XML description. Domain configuration pertains to the XML domain description for sure but this need to be added in a structured way. This gives the control tools someplace to store that information, rather than having to create some separate storage for each domain. I think every new addition to the structure need to be examined on a case by case basis, in order to keep libvirt API and the tools buit on top of them coherent. It is certainly more complex than opening the gate to a completely unstructured mechanism but like any API design, it takes a bit of time and efforts to find the proper syntactic constructs. The effort pays off on the long term IMHO. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] RFC: get/set properties
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 gives the control tools someplace to store that information, rather than having to create some separate storage for each domain. I think every new addition to the structure need to be examined on a case by case basis, in order to keep libvirt API and the tools buit on top of them coherent. I agree with this personally... regards john -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] RFC: get/set properties
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/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] RFC: get/set properties
On Wed, Apr 16, 2008 at 08:34:23AM -0400, Daniel Veillard wrote: 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. 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 Then this seems to be an argument for improving the other solutions not crippling libvirt. Or at the very least providing a mechanism that won't work on the other implementations, as happens with many libvirt facilities already. in the libvirt XML format, because this is not hypervisor domain data, and would break portability as far as I can tell. What do you mean by break portability ? regards john -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] RFC: get/set properties
On Tue, Apr 15, 2008 at 02:23:53PM -0700, Ryan Scott wrote: Daniel P. Berrange wrote: On Tue, Apr 15, 2008 at 11:31:32AM -0700, Ryan Scott wrote: I'd like to get some comments on the following... We would like to use libvirt to store some properties related to a domain. This can be done by adding a simple get/set API as follows: What are the properties ? I'm not really very enthusiastic about the idea of adding API / XML for generic key,value properties. I think it will quickly be abused as a way to add arbitrary, non-standardized hypervisor / driver specific configuration which would be better represented with explicit schema. 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. What are the drivers for ? As an example, if you're refering to drivers for the backend disk devices assigned to a guest, then we alreayd have a driver/ element for disk devices, where we can add a 'version=' attribute. If its not per-domain specific, then we have the 'capabilities' XML format which can be used to expose information about the capabilities of a hypervisor. For now we expose information about supported migration protocols, supported OS types architectures. There's clearly scope for defining further bits of metadata here. So unless more concrete examples of properties come to light I'm still not seeing any compelling argument for generic key,value pairs. One of the key ideas behind libvirt is that we try to provide a consistent set of configuration options across all drivers. NB, I'm not saying we need the lowest-common denominator - just that we try to formalize a way to represent every configuration option in such a away that it could be applied to any driver. I don't think simple key,value pairs are sufficient in the general case. This wasn't meant to be a generic solution to handle storage of all domain information. For your example below, if someone wants more information on the console, the API should be extended to allow that. However, extending the API to every piece of information for a domain seems to be overkill. That's why we just want a simple name/value pair. While extending the XML format for every piece of information is clearly more work than a generic name/value pair, this is a worthwhile tradeoff because it forces us to think about the scope of everything we add, and hopefully come up with an optimal way of representing it. 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@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[Libvir] Reopening the old discussion about virDomainBlockPeek
Virt-df[1] has now gained the ability to fully parse LVM2 partitions, thus: # virt-df -c qemu:///system -h Filesystem Size Used Available Type rhel51x32kvm:hda1 96.8 MiB 14.6 MiB 82.2 MiB Linux ext2/3 rhel51x32kvm:VolGroup00/LogVol006.4 GiB3.6 GiB2.8 GiB Linux ext2/3 rhel51x32kvm:VolGroup00/LogVol01 992.0 MiB Linux swap However it still has to do it by opening the local partitions / files, which means it isn't using a proper part of libvirt and more importantly it cannot run remotely. I'd like to find out whether the time has come for us to look again at a virDomainBlockPeek call for libvirt. Here is the original thread plus patch from 7 months ago: http://www.redhat.com/archives/libvir-list/2007-October/thread.html#00089 (I've attached an updated patch against current CVS). I appreciate that some cases might not be simple (iSCSI?), but the same argument applies to block device statistics too, and we make those available where possible. I think a best-effort call allowing callers to peek into the block devices of guests would be very useful. Rich. [1] http://hg.et.redhat.com/applications/virt/applications/virt-df--devel -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top Index: configure.in === RCS file: /data/cvs/libvirt/configure.in,v retrieving revision 1.139 diff -u -r1.139 configure.in --- configure.in8 Apr 2008 16:45:57 - 1.139 +++ configure.in16 Apr 2008 15:18:07 - @@ -60,6 +60,10 @@ LIBVIRT_COMPILE_WARNINGS(maximum) +dnl Support large files / 64 bit seek offsets. +dnl Use --disable-largefile if you don't want this. +AC_SYS_LARGEFILE + dnl Availability of various common functions (non-fatal if missing). AC_CHECK_FUNCS([cfmakeraw regexec uname]) Index: include/libvirt/libvirt.h === RCS file: /data/cvs/libvirt/include/libvirt/libvirt.h,v retrieving revision 1.72 diff -u -r1.72 libvirt.h --- include/libvirt/libvirt.h 10 Apr 2008 16:54:54 - 1.72 +++ include/libvirt/libvirt.h 16 Apr 2008 15:18:08 - @@ -522,7 +522,11 @@ const char *path, virDomainInterfaceStatsPtr stats, size_t size); - +int virDomainBlockPeek (virDomainPtr dom, + const char *path, + long long offset, + size_t size, + void *buffer); /* * defined but not running domains Index: include/libvirt/libvirt.h.in === RCS file: /data/cvs/libvirt/include/libvirt/libvirt.h.in,v retrieving revision 1.47 diff -u -r1.47 libvirt.h.in --- include/libvirt/libvirt.h.in10 Apr 2008 16:54:54 - 1.47 +++ include/libvirt/libvirt.h.in16 Apr 2008 15:18:09 - @@ -522,7 +522,11 @@ const char *path, virDomainInterfaceStatsPtr stats, size_t size); - +int virDomainBlockPeek (virDomainPtr dom, + const char *path, + long long offset, + size_t size, + void *buffer); /* * defined but not running domains Index: src/driver.h === RCS file: /data/cvs/libvirt/src/driver.h,v retrieving revision 1.46 diff -u -r1.46 driver.h --- src/driver.h10 Apr 2008 16:54:54 - 1.46 +++ src/driver.h16 Apr 2008 15:18:10 - @@ -224,6 +224,13 @@ struct _virDomainInterfaceStats *stats); typedef int +(*virDrvDomainBlockPeek) +(virDomainPtr domain, + const char *path, + long long offset, size_t size, + void *buffer); + +typedef int (*virDrvDomainMigratePrepare) (virConnectPtr dconn, char **cookie, @@ -335,6 +342,7 @@ virDrvDomainMigrateFinish domainMigrateFinish; virDrvDomainBlockStats domainBlockStats; virDrvDomainInterfaceStats domainInterfaceStats; +virDrvDomainBlockPeek domainBlockPeek; virDrvNodeGetCellsFreeMemory nodeGetCellsFreeMemory; virDrvNodeGetFreeMemory
[Libvir] Cross-compiling to Windows
I was reading this rather timely blog posting about the Trouble With Windows: http://www.mega-nerd.com/erikd/Blog/CodeHacking/MinGWCross/cross_compiling.html He mentions that he's managed to set up an entire cross-compiler environment to do the compiles (actually, it's a package in Debian called mingw32 -- we don't have it in Fedora), and he's set up Wine so he can run tests too. Good idea for libvirt too? Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] Cross-compiling to Windows
On Wed, Apr 16, 2008 at 11:24:10PM +0100, Richard W.M. Jones wrote: He mentions that he's managed to set up an entire cross-compiler environment to do the compiles (actually, it's a package in Debian called mingw32 -- we don't have it in Fedora), and he's set up Wine so he can run tests too. Not tried them yet, but there are some Fedora packages of this cross compiler here: http://mirzam.it.vu.nl/mingw/ Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] Cross-compiling to Windows
Hi, Rich It seems good idea! But I have a question. Is the testing script merged with Linux one by using Wine? Thanks Atsushi SAKAI Richard W.M. Jones [EMAIL PROTECTED] wrote: he's set up Wine so he can run tests too. Good idea for libvirt too? -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
