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

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

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!