From: Jim Fehlig <jfehlig@suse.com>
To: Stefan Bader <stefan.bader@canonical.com>
Cc: libvir-list@redhat.com, xen-devel@lists.xensource.com,
Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [libvirt] [Xen-devel] libvirt: [PATCH] libxl: Check for control_d string to decide about dom0
Date: Wed, 12 Mar 2014 18:58:02 -0600 [thread overview]
Message-ID: <5321029A.2080700@suse.com> (raw)
In-Reply-To: <5320510E.4050406@canonical.com>
Stefan Bader wrote:
> On 12.03.2014 13:08, Ian Campbell wrote:
>
>> On Wed, 2014-03-12 at 13:03 +0100, Stefan Bader wrote:
>>
>>> I have been looking into a bug report (see BugLink) which reported
>>> libvirt to fail starting inside a Xen guest. Upon further investigation
>>> I found that some tools that help monitoring Xen guests will mount
>>> xenfs to /proc/xen. This will create a capabilities files there even
>>> if the guest is not dom0. However it will return nothing when reading
>>> from it.
>>>
>> This seems consistent with the xencommons initscript which does:
>> # run this script only in dom0:
>> # no capabilities file in xenlinux domU kernel
>> # empty capabilities file in pv_ops domU kernel
>> if test -f /proc/xen/capabilities && \
>> ! grep -q "control_d" /proc/xen/capabilities ; then
>> exit 0
>> fi
>>
>>
>>> Ian, just to sanity check myself. I looked at the xenfs code and to
>>> me there only seem to be those two outcomes (either "control_d" for
>>> running in dom0 or notrhing if not).
>>>
>>> With the following patch applied, libvirt starts up correctly in
>>> the normal guests (with xenfs mounted) without initializing libxl.
>>> And also in dom0 where it still enables the libxl driver (if the
>>> xl toolstack is selected).
>>>
>>> -Stefan
>>>
>>> From f11949caca6dfe1a802472a2a6d4fe760115ccc6 Mon Sep 17 00:00:00 2001
>>> From: Stefan Bader <stefan.bader@canonical.com>
>>> Date: Wed, 12 Mar 2014 11:37:16 +0100
>>> Subject: [PATCH] libxl: Check for control_d string to decide about dom0
>>>
>>> As soon as any guest mounts xenfs to /proc/xen, there is a capabilities
>>> file in that directory. However it returns nothing when reading from it.
>>> Change the test to actually check the contents of the file.
>>>
>>> BugLink: http://bugs.launchpad.net/bugs/1248025
>>>
>>> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
>>> ---
>>> src/libxl/libxl_driver.c | 14 ++++++++++++--
>>> 1 file changed, 12 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
>>> index 65d80a2..844e828 100644
>>> --- a/src/libxl/libxl_driver.c
>>> +++ b/src/libxl/libxl_driver.c
>>> @@ -944,6 +944,7 @@ libxlDriverShouldLoad(bool privileged)
>>> bool ret = false;
>>> virCommandPtr cmd;
>>> int status;
>>> + char *output = NULL;
>>>
>>> /* Don't load if non-root */
>>> if (!privileged) {
>>> @@ -951,8 +952,17 @@ libxlDriverShouldLoad(bool privileged)
>>> return ret;
>>> }
>>>
>>> - /* Don't load if not running on a Xen control domain (dom0) */
>>> - if (!virFileExists("/proc/xen/capabilities")) {
>>> + /*
>>> + * Don't load if not running on a Xen control domain (dom0). It is not
>>> + * sufficient to check for the file to exist as any guest can mount
>>> + * xenfs to /proc/xen.
>>> + */
>>> + status = virFileReadAll("/proc/xen/capabilities", 10. &output);
>>>
>> Is this "." supposed to be a ","?
>>
>
> Darn, I thought I had fixed that. Unfortunately in the wrong place. Yes, that
> should be a ",". Sorry
>
I fixed your typo and pushed the patch. Thanks!
Regards,
Jim
prev parent reply other threads:[~2014-03-13 0:58 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-12 12:03 [libvirt] libvirt: [PATCH] libxl: Check for control_d string to decide about dom0 Stefan Bader
2014-03-12 12:07 ` Daniel P. Berrange
2014-03-12 12:08 ` Ian Campbell
2014-03-12 12:20 ` Stefan Bader
2014-03-13 0:58 ` Jim Fehlig [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5321029A.2080700@suse.com \
--to=jfehlig@suse.com \
--cc=Ian.Campbell@citrix.com \
--cc=libvir-list@redhat.com \
--cc=stefan.bader@canonical.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).