From: Jim Fehlig <jfehlig@novell.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [PATCH] Fix pci passthru in xend interface used by libvirt [and 1 more messages]
Date: Mon, 08 Nov 2010 15:26:44 -0700 [thread overview]
Message-ID: <4CD87924.9030505@novell.com> (raw)
In-Reply-To: <19672.9283.766350.105712@mariner.uk.xensource.com>
Ian Jackson wrote:
> Jim Fehlig writes ("[Xen-devel] [PATCH] Fix pci passthru in xend interface used by libvirt"):
>
>> Attempting to define or create a domain whose XML config contains a
>> passthru PCI device fails with libvirt
>>
>
> Thanks for this report. I'm afraid that no-one any more seems to know
> much about the protocol that libvirt speaks to xend. And, xend is on
> the way out - we're trying to push the new libxl library instead.
>
Heh, I was just beginning to craft a mail asking for some clarity on
"xend is on the way out". I've seen comments on the list about
deprecating xend and switching to the new tool stack, but can't seem to
find any details about the change. I have seen Stefano's talk on
libxenlight from spring Xen Summit, which states xend will be 'ported'
to libxenlight. But as you hint, I don't think this is the case - and
it sounds like a rather unpleasant task :-).
Is there a wiki, doc, roadmap, etc. that provides more details on the
tool stack future? E.g. when can we anticipate the xend-based stack no
longer being the default? Xen 4.1? Are there plans to completely
remove xend and associated code from xen-unstable?
I've seen some "interesting" custom tools over the years and would like
to better understand how these users might be affected by the tool stack
changes. What, if any, compatibility will there be with these existing
xend interfaces?
direct use of xm tool
xenapi (xen.org version)
xmlrpc
sexpr-over-http
I think there have been statements about traditional python
configuration files working with xl. I assume this means config files
containing only assignment statements correct? I've tried several
simple python config files with xl and haven't noticed any problems, but
looking for a more authoritative statement about libxl compatibility
with tradition, ubiquitous python config files.
> So it would be worth thinking about changing libvirt to use libxl
> instead.
>
Yes, I thought about it while investigating this bug. I think some
answers to my questions above will help prioritize this task.
> In the meantime, though, I've applied your patch.
>
Thank you.
Regards,
Jim
next prev parent reply other threads:[~2010-11-08 22:26 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-28 21:41 [PATCH] Fix pci passthru in xend interface used by libvirt Jim Fehlig
2010-11-04 14:35 ` Jim Fehlig
2010-11-08 16:24 ` [PATCH] Fix pci passthru in xend interface used by libvirt [and 1 more messages] Ian Jackson
2010-11-08 22:26 ` Jim Fehlig [this message]
2010-11-09 16:48 ` Ian Jackson
2010-11-09 17:27 ` Stefano Stabellini
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=4CD87924.9030505@novell.com \
--to=jfehlig@novell.com \
--cc=Ian.Jackson@eu.citrix.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 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.