Jim Fehlig writes ("Re: [Xen-devel] Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?"):
> I think that is a good idea too. I've sent a patch setting
> LIBXL_API_VERSION to 0x040200
>
> https://www.redhat.com/archives/libvir-list/2016-April/msg00771.html
It seems that the libvirt LIBXL_API_VERSION is now rather higher, at
0x040400, since libvirt#fccf27253ced
libxl: switch to using libxl_domain_create_restore from v4.4 API
One unfortunate effect of this is to break the osstest tests of the
Xen 4.3 stable branch, which for the moment is still allegedly in
security support.
I can't really see a way that this kind of problem could be avoided
in principle, without
- providing a more sophisticated way for libxl callers to set the
requested version
- providing more compatibility code in libvirt, too, and retaining
it for some time
I think instead that it would probably be better for osstest to
"freeze" the version of libvirt that it is using, every time we branch
Xen.
So Xen 4.4 would be tested with whatever libvirt we were using when
the stable branch for Xen 4.4 was made, and so on.
Does that sound sensible ?
Ian.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list