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

Re: [Libvir] Question about libvirt integration into RHEL-5



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


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