[Libvir] Question about libvirt integration into RHEL-5
Hello, Currently, the libvirt integrated into RHEL-5 beta release is the pretty old 0.1.8 version. Could you confirm that in the first release candidate RHEL-5 RC1 (planned february, 28), the libvirt will be the 0.1.8 version or another one ? Thanks.
On Thu, Jan 11, 2007 at 10:13:34AM +0100, Philippe Berthault wrote:
Hello, Currently, the libvirt integrated into RHEL-5 beta release is the pretty old 0.1.8 version. Could you confirm that in the first release candidate RHEL-5 RC1 (planned february, 28), the libvirt will be the 0.1.8 version or another one ?
it is 0.1.8 but with 12 patches which are backport of later bug fixes or important features like localization, shareable disk support, core dump support, etc ... I guess it's closer to 0.1.9 as a result than 0.1.8, 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/
Daniel Veillard a écrit :
On Thu, Jan 11, 2007 at 10:13:34AM +0100, Philippe Berthault wrote:
Hello, Currently, the libvirt integrated into RHEL-5 beta release is the pretty old 0.1.8 version. Could you confirm that in the first release candidate RHEL-5 RC1 (planned february, 28), the libvirt will be the 0.1.8 version or another one ?
it is 0.1.8 but with 12 patches which are backport of later bug fixes or important features like localization, shareable disk support, core dump support, etc ... I guess it's closer to 0.1.9 as a result than 0.1.8,
Hum ! :-( Currently, the version of libvirt determines its unequivocal contents. With a patched version of libvirt, it becomes impossible in an application to known the functionalities level of libvirt if the version number is identical to a non-patched libvirt. Could you explain how it's possible from an application to distinguish between a patched libvirt and a non-patched libvirt or another patched version of libvirt by using the virGetVersion() function ?
On Thu, Jan 11, 2007 at 11:27:52AM +0100, Philippe Berthault wrote:
Daniel Veillard a écrit :
it is 0.1.8 but with 12 patches which are backport of later bug fixes or important features like localization, shareable disk support, core dump support, etc ... I guess it's closer to 0.1.9 as a result than 0.1.8,
Hum ! :-( Currently, the version of libvirt determines its unequivocal contents. With a patched version of libvirt, it becomes impossible in an application to known the functionalities level of libvirt if the version number is identical to a non-patched libvirt.
Could you explain how it's possible from an application to distinguish between a patched libvirt and a non-patched libvirt or another patched version of libvirt by using the virGetVersion() function ?
Can explain your problem instead ? What is the feature or behaviour you need to detect ? 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/
Daniel Veillard a écrit :
On Thu, Jan 11, 2007 at 11:27:52AM +0100, Philippe Berthault wrote:
Daniel Veillard a écrit :
it is 0.1.8 but with 12 patches which are backport of later bug fixes or important features like localization, shareable disk support, core dump support, etc ... I guess it's closer to 0.1.9 as a result than 0.1.8,
Hum ! :-( Currently, the version of libvirt determines its unequivocal contents. With a patched version of libvirt, it becomes impossible in an application to known the functionalities level of libvirt if the version number is identical to a non-patched libvirt.
Could you explain how it's possible from an application to distinguish between a patched libvirt and a non-patched libvirt or another patched version of libvirt by using the virGetVersion() function ?
Can explain your problem instead ? What is the feature or behaviour you need to detect ?
We have to know if the Attach/Detach devices functions will be in the libvirt library of RHEL-5 RC1 and also if some enhancements of the XML format will be present such as currentMemory, ...
On Thu, Jan 11, 2007 at 11:42:31AM +0100, Philippe Berthault wrote:
Daniel Veillard a écrit :
On Thu, Jan 11, 2007 at 11:27:52AM +0100, Philippe Berthault wrote:
Daniel Veillard a écrit :
it is 0.1.8 but with 12 patches which are backport of later bug fixes or important features like localization, shareable disk support, core dump support, etc ... I guess it's closer to 0.1.9 as a result than 0.1.8,
Hum ! :-( Currently, the version of libvirt determines its unequivocal contents. With a patched version of libvirt, it becomes impossible in an application to known the functionalities level of libvirt if the version number is identical to a non-patched libvirt.
Could you explain how it's possible from an application to distinguish between a patched libvirt and a non-patched libvirt or another patched version of libvirt by using the virGetVersion() function ?
Can explain your problem instead ? What is the feature or behaviour you need to detect ?
We have to know if the Attach/Detach devices functions will be in the libvirt library of RHEL-5 RC1
No this was done after the code freeze, and not request by a partner as a feature for RHEL-5, so this is not present.
and also if some enhancements of the XML format will be present such as currentMemory, ...
Yes currentMemory will be in. This should not be a big problem, you can generate the XML with it, and if the library don't understand it, it should just ignore it. The set of patches are the following: Patch0: create_message.patch -> bug fix Patch1: libvirt-0.1.8-shreable-disk.patch -> shareable disk Patch2: localization.patch -> localization Patch3: core_dump.patch -> support for domain core dump Patch4: current_memory.patch -> current memory amount support Patch5: bootloader.patch -> bug fix for pygrub bootloader Patch6: python-lock.patch -> release python lock when calling libvirt Patch7: ostype.patch -> os type bug fix Patch8: vcpu_info.patch -> bug fix Patch9: pvfb.patch -> Paravirt frame buffer support Patch10: pvfb2.patch Patch11: maxid_check.patch -> bug fix 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/
Daniel Veillard a écrit :
On Thu, Jan 11, 2007 at 11:42:31AM +0100, Philippe Berthault wrote:
Daniel Veillard a écrit :
On Thu, Jan 11, 2007 at 11:27:52AM +0100, Philippe Berthault wrote:
Daniel Veillard a écrit :
it is 0.1.8 but with 12 patches which are backport of later bug fixes or important features like localization, shareable disk support, core dump support, etc ... I guess it's closer to 0.1.9 as a result than 0.1.8,
Hum ! :-( Currently, the version of libvirt determines its unequivocal contents. With a patched version of libvirt, it becomes impossible in an application to known the functionalities level of libvirt if the version number is identical to a non-patched libvirt.
Could you explain how it's possible from an application to distinguish between a patched libvirt and a non-patched libvirt or another patched version of libvirt by using the virGetVersion() function ?
Can explain your problem instead ? What is the feature or behaviour you need to detect ?
We have to know if the Attach/Detach devices functions will be in the libvirt library of RHEL-5 RC1
No this was done after the code freeze, and not request by a partner as a feature for RHEL-5, so this is not present.
and also if some enhancements of the XML format will be present such as currentMemory, ...
Yes currentMemory will be in. This should not be a big problem, you can generate the XML with it, and if the library don't understand it, it should just ignore it. The set of patches are the following:
Patch0: create_message.patch -> bug fix Patch1: libvirt-0.1.8-shreable-disk.patch -> shareable disk Patch2: localization.patch -> localization Patch3: core_dump.patch -> support for domain core dump Patch4: current_memory.patch -> current memory amount support Patch5: bootloader.patch -> bug fix for pygrub bootloader Patch6: python-lock.patch -> release python lock when calling libvirt Patch7: ostype.patch -> os type bug fix Patch8: vcpu_info.patch -> bug fix Patch9: pvfb.patch -> Paravirt frame buffer support Patch10: pvfb2.patch Patch11: maxid_check.patch -> bug fix
Your reply doesn't explain how it will be possible in an application to known the functionalities level of libvirt by using the virGetVersion() function. For RHEL-5 RC1, we have now the response but this problem will occur again in the future with RHEL-5 update-1, update-2, ... and so on. My understanding is that the virGetVersion() function is useless :-(
On Thu, Jan 11, 2007 at 12:21:45PM +0100, Philippe Berthault wrote:
Your reply doesn't explain how it will be possible in an application to known the functionalities level of libvirt by using the virGetVersion() function. For RHEL-5 RC1, we have now the response but this problem will occur again in the future with RHEL-5 update-1, update-2, ... and so on.
What makes you believe we will make a libvirt upgrade in RHEL-5 lifetime. In general we don't do that. Maybe we will to add support for defined non running domains, but as a maintainer for other libraries in RHEL, I never did this before.
My understanding is that the virGetVersion() function is useless :-(
That's your point of view, and I disagree. 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 Thu, Jan 11, 2007 at 12:21:45PM +0100, Philippe Berthault wrote:
Daniel Veillard a écrit :
Yes currentMemory will be in. This should not be a big problem, you can generate the XML with it, and if the library don't understand it, it should just ignore it. The set of patches are the following:
Patch0: create_message.patch -> bug fix Patch1: libvirt-0.1.8-shreable-disk.patch -> shareable disk Patch2: localization.patch -> localization Patch3: core_dump.patch -> support for domain core dump Patch4: current_memory.patch -> current memory amount support Patch5: bootloader.patch -> bug fix for pygrub bootloader Patch6: python-lock.patch -> release python lock when calling libvirt Patch7: ostype.patch -> os type bug fix Patch8: vcpu_info.patch -> bug fix Patch9: pvfb.patch -> Paravirt frame buffer support Patch10: pvfb2.patch Patch11: maxid_check.patch -> bug fix
Your reply doesn't explain how it will be possible in an application to known the functionalities level of libvirt by using the virGetVersion() function. For RHEL-5 RC1, we have now the response but this problem will occur again in the future with RHEL-5 update-1, update-2, ... and so on.
My understanding is that the virGetVersion() function is useless :-(
It can tell you the minimum level of functionality it will contain - ie you have APIs from /at least/ version 0.1.8. There's obviously no way you can encode data about exactly what features are present based on a simple version number. Wrt to whether the Attach/Detach functions are present - the use of the virGetVersion() function is pretty irrelevant because if your app uses them, you'll get an error at build time when trying to link against the library with undefined symbol. Basically treat virGetVersion() as a guide to the minimum available functionality, not as an absolute rule. For things which vary at runtime, the best approach is to simply look for them / try calling them and be prepared to handle errors appropriately if they're not present. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
participants (3)
-
Daniel P. Berrange -
Daniel Veillard -
Philippe Berthault