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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
