Re: Question about libvirt integration into RHEL-5

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 :-(


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]