Opinions on removing the old, legacy libvirt Xen driver

Opinions on removing the old, legacy libvirt Xen driver

[Jim Fehlig]

Hi All,

I briefly mentioned this at an evening event during the KVM Forum / Xen Dev 
Summit, but the list is certainly a better place to discuss such a topic. What 
do folks think about finally removing the old, legacy, xend-based driver from 
the libvirt sources?

The Xen community made xl/libxl the primary toolstack in Xen 4.1. In Xen 4.2, it 
was made the default toolstack. In Xen 4.5, xm/xend was completely removed from 
the Xen source tree. According to the Xen release support matrix [0], upstream 
maintenance of Xen 4.1-4.3 has been dropped for some time, including "long term" 
security support. Xen 4.4-4.5 no longer receive regular maintenance support, 
with security support ending in March for 4.4 and January 2018 for 4.5. In 
short, the fully maintained upstream Xen releases don't even contain xm/xend :-).

As for downstreams, I doubt anyone is interested in running the last several 
libvirt releases on an old Xen installition with xm/xend, let alone libvirt.git 
master. SUSE, which still supports Xen, has no interest in using a new libvirt 
on older (but still supported) SLES that uses the xm/xend toolstack. I struggle 
to find a good reason to keep any of the old cruft under src/xen/. I do think we 
should keep the xm/sexpr config parsing/formatting code src/xenconfig/ since it 
is useful for converting old xm and sexpr config to libvirt domXML.

Thanks for opinions and comments!

Regards,
Jim

[0] https://wiki.xenproject.org/wiki/Xen_Project_Release_Features

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: Opinions on removing the old, legacy libvirt Xen driver

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 1622 bytes --]

On Fri, 2016-11-18 at 14:25 -0700, Jim Fehlig wrote:
> Hi All,
> 
> I briefly mentioned this at an evening event during the KVM Forum /
> Xen Dev 
> Summit, but the list is certainly a better place to discuss such a
> topic. What 
> do folks think about finally removing the old, legacy, xend-based
> driver from 
> the libvirt sources?
> 
As little as it is worth, I'd like to send my +1 to this.

> As for downstreams, I doubt anyone is interested in running the last
> several 
> libvirt releases on an old Xen installition with xm/xend, let alone
> libvirt.git 
> master. SUSE, which still supports Xen, has no interest in using a
> new libvirt 
> on older (but still supported) SLES that uses the xm/xend toolstack.
> I struggle 
> to find a good reason to keep any of the old cruft under src/xen/. I
> do think we 
> should keep the xm/sexpr config parsing/formatting code
> src/xenconfig/ since it 
> is useful for converting old xm and sexpr config to libvirt domXML.
> 
I totally agree with this analysis of yours.

And allow me to add that, for example, on Fedora 24, I have xen-4.6.4,
which does not have xm/xend.

And yet it appear I can install
libvirt-daemon-driver-xen-1.3.3.2-1.fc24.x86_64 which would be totally
useless and, from a user perspective, very confusing.

So, again, +1.

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: Opinions on removing the old, legacy libvirt Xen driver

[Konrad Rzeszutek Wilk]

On Fri, Nov 18, 2016 at 02:25:18PM -0700, Jim Fehlig wrote:
> Hi All,
> 
> I briefly mentioned this at an evening event during the KVM Forum / Xen Dev
> Summit, but the list is certainly a better place to discuss such a topic.
> What do folks think about finally removing the old, legacy, xend-based
> driver from the libvirt sources?

RIP.

It will make your life easier! All the code that Joao and Bob are
doing is against libxl and I presume other folks are more interested
in that.

> 
> The Xen community made xl/libxl the primary toolstack in Xen 4.1. In Xen
> 4.2, it was made the default toolstack. In Xen 4.5, xm/xend was completely
> removed from the Xen source tree. According to the Xen release support
> matrix [0], upstream maintenance of Xen 4.1-4.3 has been dropped for some
> time, including "long term" security support. Xen 4.4-4.5 no longer receive
> regular maintenance support, with security support ending in March for 4.4
> and January 2018 for 4.5. In short, the fully maintained upstream Xen
> releases don't even contain xm/xend :-).
> 
> As for downstreams, I doubt anyone is interested in running the last several
> libvirt releases on an old Xen installition with xm/xend, let alone
> libvirt.git master. SUSE, which still supports Xen, has no interest in using
> a new libvirt on older (but still supported) SLES that uses the xm/xend
> toolstack. I struggle to find a good reason to keep any of the old cruft
> under src/xen/. I do think we should keep the xm/sexpr config
> parsing/formatting code src/xenconfig/ since it is useful for converting old
> xm and sexpr config to libvirt domXML.

/me nods.
> 
> Thanks for opinions and comments!
> 
> Regards,
> Jim
> 
> [0] https://wiki.xenproject.org/wiki/Xen_Project_Release_Features
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: Opinions on removing the old, legacy libvirt Xen driver

[Wei Liu]

On Fri, Nov 18, 2016 at 02:25:18PM -0700, Jim Fehlig wrote:
> Hi All,
> 
> I briefly mentioned this at an evening event during the KVM Forum / Xen Dev
> Summit, but the list is certainly a better place to discuss such a topic.
> What do folks think about finally removing the old, legacy, xend-based
> driver from the libvirt sources?
> 
> The Xen community made xl/libxl the primary toolstack in Xen 4.1. In Xen
> 4.2, it was made the default toolstack. In Xen 4.5, xm/xend was completely
> removed from the Xen source tree. According to the Xen release support
> matrix [0], upstream maintenance of Xen 4.1-4.3 has been dropped for some
> time, including "long term" security support. Xen 4.4-4.5 no longer receive
> regular maintenance support, with security support ending in March for 4.4
> and January 2018 for 4.5. In short, the fully maintained upstream Xen
> releases don't even contain xm/xend :-).
> 
> As for downstreams, I doubt anyone is interested in running the last several
> libvirt releases on an old Xen installition with xm/xend, let alone
> libvirt.git master. SUSE, which still supports Xen, has no interest in using
> a new libvirt on older (but still supported) SLES that uses the xm/xend
> toolstack. I struggle to find a good reason to keep any of the old cruft
> under src/xen/. I do think we should keep the xm/sexpr config
> parsing/formatting code src/xenconfig/ since it is useful for converting old
> xm and sexpr config to libvirt domXML.
> 
> Thanks for opinions and comments!

FWIW I agree with your analysis.

Wei.

> 
> Regards,
> Jim
> 
> [0] https://wiki.xenproject.org/wiki/Xen_Project_Release_Features
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [libvirt] Opinions on removing the old, legacy libvirt Xen driver

[Martin Kletzander]

[-- Attachment #1.1: Type: text/plain, Size: 2538 bytes --]

On Fri, Nov 18, 2016 at 02:25:18PM -0700, Jim Fehlig wrote:
>Hi All,
>
>I briefly mentioned this at an evening event during the KVM Forum / Xen Dev
>Summit, but the list is certainly a better place to discuss such a topic. What
>do folks think about finally removing the old, legacy, xend-based driver from
>the libvirt sources?
>
>The Xen community made xl/libxl the primary toolstack in Xen 4.1. In Xen 4.2, it
>was made the default toolstack. In Xen 4.5, xm/xend was completely removed from
>the Xen source tree. According to the Xen release support matrix [0], upstream
>maintenance of Xen 4.1-4.3 has been dropped for some time, including "long term"
>security support. Xen 4.4-4.5 no longer receive regular maintenance support,
>with security support ending in March for 4.4 and January 2018 for 4.5. In
>short, the fully maintained upstream Xen releases don't even contain xm/xend :-).
>
>As for downstreams, I doubt anyone is interested in running the last several
>libvirt releases on an old Xen installition with xm/xend, let alone libvirt.git
>master. SUSE, which still supports Xen, has no interest in using a new libvirt
>on older (but still supported) SLES that uses the xm/xend toolstack. I struggle
>to find a good reason to keep any of the old cruft under src/xen/. I do think we
>should keep the xm/sexpr config parsing/formatting code src/xenconfig/ since it
>is useful for converting old xm and sexpr config to libvirt domXML.
>
>Thanks for opinions and comments!
>

I'm not familiar with Xen to such detail, particularly with its history,
but allow me to (hopefully) help you with the decision by saying that we
dropped support for any QEmu older than 0.12.0 (released on December
2009).  And by that I don't mean that we stopped fixing bugs for those,
but that libvirt now *mandates* version 0.12.0 or newer.  That is what
is available in CentOS 6 and similar (or as Dan stated it "RHEL-6 era
distros).  For others like me, who don't know when the Xen releases were
made, I found out (for you) that it should be March 2011 for 4.1 and
September that year for 4.2.  So I'm not even going to ask in which
version xl/libxl was introduced.  I think we're totally fine with that
part being removed.  But, please, take it as just an opinion from
someone almost not touched by the Xen areas of the code.

Have a nice day,
Martin

>Regards,
>Jim
>
>[0] https://wiki.xenproject.org/wiki/Xen_Project_Release_Features
>
>--
>libvir-list mailing list
>libvir-list@redhat.com
>https://www.redhat.com/mailman/listinfo/libvir-list

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [libvirt] Opinions on removing the old, legacy libvirt Xen driver

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 1336 bytes --]

On Sun, 2016-11-20 at 23:37 +0100, Martin Kletzander wrote:
> 
> I'm not familiar with Xen to such detail, particularly with its
> history,
> but allow me to (hopefully) help you with the decision by saying that
> we
> dropped support for any QEmu older than 0.12.0 (released on December
> 2009).  And by that I don't mean that we stopped fixing bugs for
> those,
> but that libvirt now *mandates* version 0.12.0 or newer.  That is
> what
> is available in CentOS 6 and similar (or as Dan stated it "RHEL-6 era
> distros).  For others like me, who don't know when the Xen releases
> were
> made, I found out (for you) that it should be March 2011 for 4.1 and
> September that year for 4.2.  So I'm not even going to ask in which
> version xl/libxl was introduced.
>
FYI, xl was introduced in Xen 4.1:
https://wiki.xen.org/wiki/XL

Xen 4.1 was indeed released on 25th March 2011:
https://wiki.xen.org/wiki/Xen_4.1_Release_Notes

Xen 4.2 was released on 17 Sept _2012_:
https://wiki.xen.org/wiki/Xen_Project_Release_Features

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [libvirt] Opinions on removing the old, legacy libvirt Xen driver

[Neal Gompa]

On Fri, Nov 18, 2016 at 4:25 PM, Jim Fehlig <jfehlig@suse.com> wrote:
> Hi All,
>
> I briefly mentioned this at an evening event during the KVM Forum / Xen Dev
> Summit, but the list is certainly a better place to discuss such a topic.
> What do folks think about finally removing the old, legacy, xend-based
> driver from the libvirt sources?
>
> The Xen community made xl/libxl the primary toolstack in Xen 4.1. In Xen
> 4.2, it was made the default toolstack. In Xen 4.5, xm/xend was completely
> removed from the Xen source tree. According to the Xen release support
> matrix [0], upstream maintenance of Xen 4.1-4.3 has been dropped for some
> time, including "long term" security support. Xen 4.4-4.5 no longer receive
> regular maintenance support, with security support ending in March for 4.4
> and January 2018 for 4.5. In short, the fully maintained upstream Xen
> releases don't even contain xm/xend :-).
>
> As for downstreams, I doubt anyone is interested in running the last several
> libvirt releases on an old Xen installition with xm/xend, let alone
> libvirt.git master. SUSE, which still supports Xen, has no interest in using
> a new libvirt on older (but still supported) SLES that uses the xm/xend
> toolstack. I struggle to find a good reason to keep any of the old cruft
> under src/xen/. I do think we should keep the xm/sexpr config
> parsing/formatting code src/xenconfig/ since it is useful for converting old
> xm and sexpr config to libvirt domXML.
>
> Thanks for opinions and comments!
>
> Regards,
> Jim
>
> [0] https://wiki.xenproject.org/wiki/Xen_Project_Release_Features
>

For what it's worth, I totally agree with this proposal, as it will
make it less confusing to identify what you actually need for
Xen-based virtualization.

As an aside, I recently attempted to set up a Xen based system using
libvirt on Fedora, and I was initially confused by the two drivers,
and completely messed up my setup because of it. I think simply from a
usability point of view, it makes a lot of sense to eliminate the old
code and set up the libxl driver to be the "successor" of the old xen
driver.



-- 
真実はいつも一つ！/ Always, there's only one truth!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [libvirt] Opinions on removing the old, legacy libvirt Xen driver

[Daniel P. Berrange]

On Fri, Nov 18, 2016 at 02:25:18PM -0700, Jim Fehlig wrote:
> Hi All,
> 
> I briefly mentioned this at an evening event during the KVM Forum / Xen Dev
> Summit, but the list is certainly a better place to discuss such a topic.
> What do folks think about finally removing the old, legacy, xend-based
> driver from the libvirt sources?
> 
> The Xen community made xl/libxl the primary toolstack in Xen 4.1. In Xen
> 4.2, it was made the default toolstack. In Xen 4.5, xm/xend was completely
> removed from the Xen source tree. According to the Xen release support
> matrix [0], upstream maintenance of Xen 4.1-4.3 has been dropped for some
> time, including "long term" security support. Xen 4.4-4.5 no longer receive
> regular maintenance support, with security support ending in March for 4.4
> and January 2018 for 4.5. In short, the fully maintained upstream Xen
> releases don't even contain xm/xend :-).
> 
> As for downstreams, I doubt anyone is interested in running the last several
> libvirt releases on an old Xen installition with xm/xend, let alone
> libvirt.git master. SUSE, which still supports Xen, has no interest in using
> a new libvirt on older (but still supported) SLES that uses the xm/xend
> toolstack. I struggle to find a good reason to keep any of the old cruft
> under src/xen/. I do think we should keep the xm/sexpr config
> parsing/formatting code src/xenconfig/ since it is useful for converting old
> xm and sexpr config to libvirt domXML.
> 
> Thanks for opinions and comments!

As a point of reference, for the QEMU/KVM driver we took the decision to drop
support for distros whose age is older than RHEL-6 (Nov 2010 release date).
Xen 4.1 came out in early 2011 IIUC, so dropping support for Xen < 4.1 is
a reasonable thing todo and consistent with what we've done for QEMU. So
ACK to that from a project support POV.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel