From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Fehlig Subject: Re: Missing libvirt+libxl functionality (Was: Re: [Xen-users] Programmatic administration of Xen machines) Date: Thu, 07 Jan 2016 22:54:01 -0700 Message-ID: <568F4EF9.2090609@suse.com> References: <56812352.8060500@pse-consulting.de> <1451907382.13361.37.camel@citrix.com> <568A5BEE.9090808@pse-consulting.de> <1451909615.13361.46.camel@citrix.com> <568A6618.5@pse-consulting.de> <1451911062.13361.60.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1451911062.13361.60.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell , Andreas Pflug , xen-users@lists.xen.org Cc: Olaf Hering , xen-devel List-Id: xen-devel@lists.xenproject.org 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