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

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>

On Wed, 2015-02-18 at 14:53 +0100, Stefan Bader wrote:
> 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.
Apart from parallel installation (which is useful in itself) it also
eases regular upgrades, since you can install all the new packages,
reboot (e.g. where xendomains will still want to use the old tools) and
then pick up the new tools. Plus it makes it easier to roll back in case
of problems.

At some point I'd really love to see the ability to install into
versioned directories become a properly integrated feature of the
upstream build system which Debian could simply enable. That would take
a bunch of reworking (since the patches take a slightly too big hammer
approach) and I'm not sure when, if ever, I might get to it...

Ian.

On 18.02.2015 16:13, Ian Campbell wrote:
> On Wed, 2015-02-18 at 14:53 +0100, Stefan Bader wrote:
>> 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.
> 
> Apart from parallel installation (which is useful in itself) it also
> eases regular upgrades, since you can install all the new packages,
> reboot (e.g. where xendomains will still want to use the old tools) and
> then pick up the new tools. Plus it makes it easier to roll back in case
> of problems.
Hm, yeah. And all that coming from tools/library potentially not working well
against and older/newer hypervisor which is running until the next reboot. So
point taken for the upgrade. Not sure about the rollback as with libvirt and
qemu compiled against a single version and being in other packages this becomes
more than just booting backinto the old hv. But I cannot think of any better way
either.

Thanks for the explanation.
-Stefan
> 
> At some point I'd really love to see the ability to install into
> versioned directories become a properly integrated feature of the
> upstream build system which Debian could simply enable. That would take
> a bunch of reworking (since the patches take a slightly too big hammer
> approach) and I'm not sure when, if ever, I might get to it...
> 
> Ian.
> 

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

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.
> 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

--

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>