From mboxrd@z Thu Jan 1 00:00:00 1970 From: Doug Goldstein Subject: Re: [libvirt] Questions about virtlogd Date: Wed, 8 Jun 2016 07:53:53 -0400 Message-ID: <94e5a180-3542-914d-724e-b43c398de19d@cardoe.com> References: <20160607121153.GL25922@citrix.com> <20160607132116.GD20196@redhat.com> <20160607155708.GM25922@citrix.com> <5757EA60.4030004@citrix.com> <20160608100716.GD7760@redhat.com> <5757FA29.10605@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0022814786547761516==" Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bAc3a-0001zb-O5 for xen-devel@lists.xenproject.org; Wed, 08 Jun 2016 11:53:58 +0000 Received: by mail-qt0-f179.google.com with SMTP id 9so1257299qtg.2 for ; Wed, 08 Jun 2016 04:53:56 -0700 (PDT) In-Reply-To: <5757FA29.10605@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: George Dunlap , "Daniel P. Berrange" Cc: George Dunlap , Ian Jackson , Wei Liu , Xen-devel List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============0022814786547761516== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="b007dsvGcktiGLcDnBxShD43XsrlvbxrD" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --b007dsvGcktiGLcDnBxShD43XsrlvbxrD Content-Type: multipart/mixed; boundary="WgvXIIFeoHo3ot0jihHKb3AQWL0aPUmF4" From: Doug Goldstein To: George Dunlap , "Daniel P. Berrange" Cc: Wei Liu , George Dunlap , Ian Jackson , Xen-devel Message-ID: <94e5a180-3542-914d-724e-b43c398de19d@cardoe.com> Subject: Re: [libvirt] Questions about virtlogd References: <20160607121153.GL25922@citrix.com> <20160607132116.GD20196@redhat.com> <20160607155708.GM25922@citrix.com> <5757EA60.4030004@citrix.com> <20160608100716.GD7760@redhat.com> <5757FA29.10605@citrix.com> In-Reply-To: <5757FA29.10605@citrix.com> --WgvXIIFeoHo3ot0jihHKb3AQWL0aPUmF4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 6/8/16 6:57 AM, George Dunlap wrote: > On 08/06/16 11:07, Daniel P. Berrange wrote: >> On Wed, Jun 08, 2016 at 10:50:24AM +0100, George Dunlap wrote: >>> On 07/06/16 16:57, Wei Liu wrote: >>>>> I must admit I'm not familiar with the division of responsibility >>>>> for managing QEMU between the Xen provided libxl library(s) and >>>>> the libvirt libxl driver code. Naively I would expect the libvirt >>>>> libxl driver code to deal with virtlogd and then configure the >>>>> Xen libxl library / QEMU accordingly. Your request seems to imply >>>>> that you will need the Xen libxl library to directly talk to >>>>> virtlogd instead. >>>>> >>>>> Is there any way in which it would be practical for the libvirt >>>>> libxl driver to talk to virtlogd to acquire the file descriptors >>>>> to use and pass those file descriptors down to the libxl library ? >>>>> >>>> >>>> There are two classes of configurations. >>>> >>>> For libvirt + libxl, There is currently no API for passing in a fd t= o be >>>> used as QEMU logging fd. But I'm thinking about having one. It would= n't >>>> be too hard. >>>> >>>> The other class is configurations that don't have libvirt. We need = some >>>> sort of mechanism to handle QEMU logs. My intent of this email is ma= inly >>>> for this class of configurations. >>> >>> Just to be clear -- internally we're investigating options for dealin= g >>> with the "qemu logging" problem* for XenProject for people not runnin= g >>> libvirt -- people who use the xl toolstack, or people who build their= >>> own toolstack on top of libxl. >>> >>> (We *also* need to figure out how to deal with the libxl+libvirt >>> situation, but that's just a matter of plumbing I think.) >>> >>> The options we've come up with, broadly, are as follows: >>> >>> 1. Try to use the existing syslog facilities >>> >>> 2. Re-purpose one of our existing daemons to perform a role similar t= o >>> virtlogd >>> >>> 3. "Steal" virtlogd and import it into our tree (yay GPL!) >>> >>> 4. Work with the libvirt community to make virtlogd an independent >>> project which can be used by both libvirt and libxl directly >> >> For completeness I'd also suggest >> >> 5. Declare it out of scope for xl toolstack to solve the whole >> problem. Merely provide the minimal hooks to enable the layer >> above libxl to solve it. This is effectively QEMU's approach. >> >> Of course, this would mean that any non-libvirt layer using libxl >> stil faces the same problem you're facing, so I understand if thats >> not desirable from your POV. >=20 > [Removing libvirt-list] >=20 > Well we definitely want to make it possible for people to use xl while > still avoiding DoSes. But at the simplest level this could be done by > having qemu's stderr/stdout piped to /dev/null by default, and allowing= > an option for the admin to enable piping it to a file on a per-guest > basis when necessary. >=20 > This would effectively be declaring a "proper solution" out-of-scope, > while not opening up our users to security issues. >=20 > -George >=20 I'm in favor of an approach like this that declares it out of scope. In a world of finite resources Xen has to focus on what its strengths are in the virtualization space and being the best possible solution for the use cases where its strengths can shine. This requires some tough choices and acknowledging that being the complete vertical stack and legitimately competing against a number of other pieces that build the stack for other hypervisor solutions is just not a situation that will allow Xen to shine. You mentioned it earlier in the thread and we've talked about this before but libxl should be enhanced to allow everything it needs to be passed in as an fd and let the actual toolstack (be it xl or libvirt or something else) do the actual open() and supply the fd. --=20 Doug Goldstein --WgvXIIFeoHo3ot0jihHKb3AQWL0aPUmF4-- --b007dsvGcktiGLcDnBxShD43XsrlvbxrD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0 iQJ8BAEBCgBmBQJXWAdTXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNTM5MEQ2RTNFMTkyNzlCNzVDMzIwOTVB MkJDMDNEQzg3RUQxQkQ0AAoJEKK8A9yH7RvUqLoQAIJNdLWeGJD1PbEhIvGXL+Wh K/Nm7JQkAqZ+ZO25bN6HSPnxrmlOyYn5WAhvZ5T2LVoqYqetMXRcQ6o7TTTvFsGj p4xv65SSsw88aOwq/Bs3pQwVQTubLYCG3cOmIRlMSGm1j3hYzkqUS19BamYjvJRs CIubK51lOXux3i+uxqj4ZHjjbf5FlAyfC6DG4hlUMJuUxWbCky+aZVB2luWK7VOD dAN91fl4qtrejx+MNDiJoNM62nL36ALASv2DBUrjYCOBVIyjNsyhMgh8Fs2sO3RN frq+0u2W8kDXp102TCcrFRPk+bjC+xNnOWUJ5d6XapHHNE/pCRGgoL9FTqpuIapm ndM1gCY5YWVXcaJzoMRf39yCZJYVRll4M5tp+1aRRtnLq4VUwT8QUp45pA264jz2 Z4tlBQHsIz/5TIIdwFpM+qKrGnfmf7yPlOxbDCTAztI/zXdIV+hqDsQRto0voyuu FlulUHEgb5jKWueBgcVC6BcvCd0PvsaqsTwlH7vWmVF/23rB/aTSGgxE9/EmUk2H LYj8Hh3NRUhypvkcOYvC8On/qCx3xKu6/5OOmHU093V/BzRpVFbkA+eBKIL70d5S HB83jzHyiS2KLrs+9N8cPbtbLlZwd79AHCQQcPplgDaXXatQhqcptLeMBHg2A3+/ Na4UB5NqEqJh814qLIGP =MynS -----END PGP SIGNATURE----- --b007dsvGcktiGLcDnBxShD43XsrlvbxrD-- --===============0022814786547761516== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y Zy94ZW4tZGV2ZWwK --===============0022814786547761516==--