From mboxrd@z Thu Jan 1 00:00:00 1970 From: Martin Kletzander Subject: Re: [libvirt] Opinions on removing the old, legacy libvirt Xen driver Date: Sun, 20 Nov 2016 23:37:15 +0100 Message-ID: <20161120223715.GB26559@wheatley> References: <990edf2f-05cd-4d29-0c77-08a78c1a97dd@suse.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3484218288229438070==" Return-path: Received: from mail6.bemta6.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c8aji-0007eP-53 for xen-devel@lists.xenproject.org; Sun, 20 Nov 2016 22:37:22 +0000 In-Reply-To: <990edf2f-05cd-4d29-0c77-08a78c1a97dd@suse.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Jim Fehlig Cc: Libvirt List , xen-devel List-Id: xen-devel@lists.xenproject.org --===============3484218288229438070== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FL5UXtIhxfXey3p5" Content-Disposition: inline --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline 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 --FL5UXtIhxfXey3p5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJYMiWaAAoJEAgfwp8kF4bdmg8P/RgzW3UJ37v9Yrmh3DZA8jD1 D/Om0eOTBfKZoPYiHNNj0Wmxwsedr+0OTgel2nvzW5uWF4ksjzvWFoWOgNTcuuJs e5TZtIeVlucklrjMdUgQsQcUyWlZ4vRZ09iAD0HxifCOWdPsGA+I0E0fsA45vPFM MT4IXVdp3wJBRzUEWDRqDGGvQhdFrmAngD86MYGug26KFNFM7+b7n1oZc+Q2KWX+ 3PhdNl0V3G1lGtWKVjMWfNm8Idjipf0alkGPTkAUgCAeViBnvh5mKBiWpmt6FPVm 368KpsLxgmi5ZksVD/nA9ojDix77eXGk2aHZAGLlIiL4b6YBTWwfNG7DxWumjvVO NEkp9eaLyRVQyUtCZsIseede7V8pdf3kleIqMFtHNEGAmC6zdZ/75vT0sHFHLnic D3gjXp4al799nlbCVxF922jx1inM/McLj9ZXxthK1YZhvZWFUecVoGht9Ks21Vzr 9plFKa3FixlVQ9Jy9CNhUUZ2irKl8P+1igkpLhq6f/sCq+MMCkqgfnboIzl9uLxt XyIVzIj1ry5JAAJwAz2rMfINRbtsCA0l43+z2SGY4DFlbYXYIhSYj6eEl0GJQBw0 v8dqOQc/TRmENNYTLL31pQNKQxpB1y+H52rtwITqmYMmyPSX5K7KJ7U5SV6HUK9v skoBNi/ItVR3B3GdVnfZ =I4rQ -----END PGP SIGNATURE----- --FL5UXtIhxfXey3p5-- --===============3484218288229438070== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============3484218288229438070==--