On Wed, Jun 08, 2016 at 07:53:53AM -0400, Doug Goldstein wrote: > 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 to be > >>>> used as QEMU logging fd. But I'm thinking about having one. It wouldn'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 mainly > >>>> for this class of configurations. > >>> > >>> Just to be clear -- internally we're investigating options for dealing > >>> with the "qemu logging" problem* for XenProject for people not running > >>> 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 to > >>> 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. > > > > [Removing libvirt-list] > > > > 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. > > > > This would effectively be declaring a "proper solution" out-of-scope, > > while not opening up our users to security issues. > > > > -George > > > > 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. >
I'm more than happy to make this someone else's problem. :-) > 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. > Yeah, I do want to have something like this -- that is regardless of whatever we end up with the conclusion of the internal machinery for QEMU logging (declare it out of scope, use virtlogd, use xenconsoled etc etc). But I haven't had a clear idea how the interface should look like. My original plan is that if someone provides an fd via the new interface, libxl would use that; if not, libxl would use whatever thing we have for logging. This way is a bit nicer for setup that doesn't use the new API -- the output will still be available somewhere. But since there are many different opinions on this matter, while I don't really care which one ends up "winning", I will just implement the new API, redirect logging to /dev/null by default, and let other people worry about the rest. Wei. > -- > Doug Goldstein > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel