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,

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 ?

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