[Pkg-xen-devel] Does it still make sense to have versioned xen-hypervisor, libxen and xen-utils?
Stefan Bader
stefan.bader at canonical.com
Wed Feb 18 13:53:07 UTC 2015
I do not know the history there. I could imagine it once was done to allow a
stable and bleeding edge version of Xen to co-exist. Though today there might be
reasons to re-think:
- libvirt
* 1.2.12 starts to validate configs and requires full path specifications
for hvmloader, pygrub, and qemu. Things are not completely cleared up,
yet. But for the future the xen build would create a xenlight.pc that
communicates the used paths. But still this would require to rewrite
configuration files when switching between versioned libxl.
* Even now there is only one libvirt which is compiled against one version
of libxl. At least when moving between xen 4.4 and 4.5 this caused issues.
Libvirtd would fail to start as long as it was not recompiled against libxl
4.5. I have not tested the other way round but it probably is as bad.
- qemu
* There is no xen specific binary anymore. Instead the upstream qemu is
pulled in through depends.
* That qemu also is compiled against one version of libxl. When moving from
4.4 to 4.5 without recompiling qemu the issues were subtle. Not sure why
but using cirrus on HVM would stop updating a VNC screen as soon as the
resolution was changed.
So given that for above reasons moving between xen versions installed in
parallel is not as straight forward as one would hope and maintaining the
patches to get the versioned packages is some effort, what are/were the reasons
to do this? Might be a dumb question but I guess I have to ask anyway.
-Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20150218/2f944d44/attachment.sig>
More information about the Pkg-xen-devel
mailing list