From: Jim Fehlig <jfehlig@suse.com>
To: Ian Campbell <ian.campbell@citrix.com>,
Andreas Pflug <pgadmin@pse-consulting.de>,
xen-users@lists.xen.org
Cc: Olaf Hering <OHering@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: Missing libvirt+libxl functionality (Was: Re: [Xen-users] Programmatic administration of Xen machines)
Date: Thu, 07 Jan 2016 22:54:01 -0700 [thread overview]
Message-ID: <568F4EF9.2090609@suse.com> (raw)
In-Reply-To: <1451911062.13361.60.camel@citrix.com>
On 01/04/2016 05:37 AM, Ian Campbell wrote:
> On Mon, 2016-01-04 at 13:31 +0100, Andreas Pflug wrote:
>> Am 04.01.16 um 13:13 schrieb Ian Campbell:
>>> On Mon, 2016-01-04 at 12:47 +0100, Andreas Pflug wrote:
>>>> Am 04.01.16 um 12:36 schrieb Ian Campbell:
>>>>> Sorry to hijack this thread.
>>>>>
>>>>> On Mon, 2015-12-28 at 12:56 +0100, Andreas Pflug wrote:
>>>>>> Actually, I find virsh a bad idea since its support for the new
>>>>>> xl
>>>>>> interface isn't feature complete as the old xm interface was. I
>>>>>> had
>>>>>> to
>>>>>> realize this the hard way when my virsh based python tools didn't
>>>>>> work
>>>>>> as expected after upgrading from xm to xl.
>>>>> Note that virsh speaks to libxl directly, not via xl.
>>>>>
>>>>> Please can you list the functionality of libvirt's libxl backed
>>>>> which
>>>>> is
>>>>> missing compared to the old xend based one?
>>>> libvirt only handles domains created through it, i.e. using xl at the
>>>> same time is incompatible. Since dom0 can't be created using libvirt,
>>>> it's missing from "virsh list" in any case.
>>> This works for me with a reasonably modern set of bits:
>>>
>>> root@marilith-n0 :~# virsh list
>>> Id Name State
>>> ----------------------------------------------------
>>> 0 Domain-0 running
>>> 13 d running
>>>
>>> It probably requires the correct running of xen-init-dom0 during boot
>>> (likely via the xencommons initscript).
>>>
>>> I could believe it was broken at some point in history though.
>>>
>>>> libvirt stores its own state, not using libxl/xenstore stuff.
>>> Please can you elaborate.
>> I tested on Debian with 4.4.1 and xl toolstack. See the author's blog
>> post:
>> https://blog.xenproject.org/2014/01/17/libvirt-support-for-xens-new-
>> libxenlight-toolstack/
> I think that particular aspect of the blog post is no longer valid, at
> least AFAICT with modern libvirt.
Commit 45697fe5 added dom0 management support to the libvirt libxl driver.
libvirt >= 1.2.18 contains the commit.
>
>> I had even more trouble, e.g. I wasn't able to use non-standard block
>> scripts (neither via /etc/xen/scripts/block-XXX nor via a script
>> parameter) which are mandatory for me.
> Looking at the code it seems like this is still missing.
>
> Copying the devel list and maintainer in case I've either missed something
> or there is a reason for this (other than "still on the TODO list", which I
> expect is most likely).
It is on a TODO list, but I'm not sure how to solve it :-/. Unlike the
libxl_device_disk struct, the corresponding libvirt struct does not support a
'script' field, and I doubt it ever will. Repeated attempts to add a <script>
element to the <disk> config have been rejected. The libvirt community prefers
all config needed to setup disks be provided in the XML, not left to a magic
script doing unknown things behind libvirtd's back.
In the old xend-based libvirt driver, some of the block-* scripts worked by
accident. E.g. the block-iscsi script might work with config such as
<disk type='file' device='disk'>
<driver name='file'/>
<source
file='iscsi:iqn.2006-09.de.suse@0ac47ee2-216e-452a-a341-a12624cd0225'/>
<target dev='hda'/>
</disk>
The 'iscsi:iqn.2006-09.de.suse@0ac47ee2-216e-452a-a341-a12624cd0225' blob was
passed wholesale to xend, which would eat it and "do the right thing". AFAIK,
libxl is not that forgiving. I've cc'd Olaf on this thread since we recently
discussed how libvirt+libxl might support external block scripts. As I recall,
we didn't have an novel ideas.
>
> If you find other shortcomings of libvirt with libxl then I suppose the
> best way to approach them would be to report them as bugs:
> http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen
>
> (I don't know if Jim or libvirt prefers some other means of doing so).
See http://libvirt.org/bugs.html for reporting libvirt bugs. Deficiencies in
libxl compared to the old xend toolstack should be reported against Xen - and
probably libvirt too since it most likely contains the deficiency as well.
Regards,
Jim
next prev parent reply other threads:[~2016-01-08 5:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CA+v+Np+eT=mmyt-ZicW1uY4358FP5bCmDrivXU=kw2uTL--i0A@mail.gmail.com>
[not found] ` <56812352.8060500@pse-consulting.de>
[not found] ` <1451907382.13361.37.camel@citrix.com>
[not found] ` <568A5BEE.9090808@pse-consulting.de>
[not found] ` <1451909615.13361.46.camel@citrix.com>
[not found] ` <568A6618.5@pse-consulting.de>
2016-01-04 12:37 ` Missing libvirt+libxl functionality (Was: Re: [Xen-users] Programmatic administration of Xen machines) Ian Campbell
2016-01-08 5:54 ` Jim Fehlig [this message]
2016-01-08 6:51 ` Olaf Hering
2016-01-08 12:46 ` Ian Campbell
2016-01-09 1:48 ` Jim Fehlig
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=568F4EF9.2090609@suse.com \
--to=jfehlig@suse.com \
--cc=OHering@suse.com \
--cc=ian.campbell@citrix.com \
--cc=pgadmin@pse-consulting.de \
--cc=xen-devel@lists.xen.org \
--cc=xen-users@lists.xen.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.