[Pkg-xen-devel] Does it still make sense to have versioned xen-hypervisor, libxen and xen-utils?

[Stefan Bader]

On 26.02.2015 09:29, Bastian Blank wrote:
> On Wed, Feb 18, 2015 at 02:53:07PM +0100, Stefan Bader wrote:
>> - 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.
> 
> So libvirt is broken in this respect.
> 
>>   * 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.
> 
> And this would not change with unversioned utils, as the libs still have
> versions.
> 
>> - qemu
>>   * 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.
> 
> $ ldd /usr/bin/qemu-system-x86_64 | grep xen
>         libxenstore.so.3.0 => /usr/lib/x86_64-linux-gnu/libxenstore.so.3.0 (0x00007f401610c000)
>         libxenctrl-4.4.so => /usr/lib/x86_64-linux-gnu/libxenctrl-4.4.so (0x00007f4015ee4000)
>         libxenguest-4.4.so => /usr/lib/x86_64-linux-gnu/libxenguest-4.4.so (0x00007f4015cb8000)
> 
> Neither libvirt nor qemu are critical for the system.

While libvirt is debatable, I would disagree for qemu. Not the 64bit one but
qemu-system-i386. This is now the device-model provider for all HVM and even PVM
use it for file based vdisks.
A cannot say whether there have been any issues with that before. In general I
end up with only one version installed. And the weird behaviour I noticed while
experimenting with moving from 4.4.1 to 4.5 was not a fatal one.

But bottom line, I do understand why the versioned package are still wanted.
Still there are now more complicated relationships with other package which
require some thinking about. Right now the side-by-side installation may (or may
not) have weird effects.

-Stefan

> 
>> 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.
> 
> The same reason why the name of the kernel changes now and then.  And
> yes, I use this with Xen 4.1, 4.4 and 4.5 on several machines.
> 
> Bastian
> 


-------------- 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/20150226/c4347629/attachment.sig>