[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [TestDay] F20 Xen 4.4 RC3 Spice support



On 04/11/2014 08:52 AM, Fabio Fantoni wrote:
Il 10/04/2014 18:21, George Dunlap ha scritto:
On Thu, Apr 10, 2014 at 1:26 PM, Fabio Fantoni <fabio.fantoni@xxxxxxx> wrote:
Il 11/02/2014 10:56, Fabio Fantoni ha scritto:
Il 10/02/2014 18:05, George Dunlap ha scritto:

On Tue, Feb 4, 2014 at 4:01 PM, Fabio Fantoni <fabio.fantoni@xxxxxxx>
wrote:
Il 04/02/2014 16:41, Eric Houby ha scritto:

Xen list,

I am trying to boot a F20 guest and connect using Spice but have run
into an issue.

My VM config file includes:
spice = 1
spicehost='0.0.0.0'
spiceport=6001
spicedisable_ticketing=1


Is Spice supported with qemu-xen-traditional?

No, only with upstream qemu and if compile xen and qemu from source you
also
enable spice support on qemu build, for example on my xen build tests I
add:

tools/Makefile
@@ -201,6 +201,8 @@ subdir-all-qemu-xen-dir: qemu-xen-dir-find
           --datadir=$(SHAREDIR)/qemu-xen \
           --localstatedir=/var \
           --disable-kvm \
+        --enable-spice \
+        --enable-usb-redir \
           --disable-docs \
           --disable-guest-agent \
           --python=$(PYTHON) \

If you use upstream qemu from distribution package probably have already
spice build-in, for example, on debian I've already tested and working.
It might be nice at some point to have this integrated into the
top-level configure, possibly enabled by default (gated on the
appropriate development libraries being enabled).

   -George


I already did a patch to do it time ago in three different ways but all
rejected :(
A one reason was the lack of needed libraries on many distros versions
used with xen.
Now all newer versions have the needed spice and usbredir libraries
included, so if you would like reconsider the path please point me in the
right direction in order to have this done correctly.
The three way I did were:
- enabled by default
- Added optional build configs for qemu upstream (debug part now no more
needed because already present)
http://lists.xen.org/archives/html/xen-devel/2012-03/msg00506.html
- Autoconf: add variable for pass arbitrary options to qemu upstream
http://lists.xen.org/archives/html/xen-devel/2012-03/msg01677.html
Probably there are also newer versions of these patches that I not found
anymore.

Thanks for any reply.

Ping.
Added also Ian Campbell and Ian Jackson to cc, which have been take part to
the discussion about 2 years ago.
I think you'll need to rebase and re-post those patches if want us to
discuss them after 2 years.

  -George

I think the best option would be to identify which one of the three methods is best before do updated and improve patch for it:
- spice and usbredir enabled by default in qemu upstream build
- optional spice and usbredir build configs for qemu upstream
- Autoconf: add variable for pass arbitrary build options to qemu upstream

Looking at that thread, it seems IanJ is in favor of something like your final approach (" [PATCH v3] Autoconf: add variable for pass arbitrary options to qemu upstream"); he apparently just dropped the thread.  (Or perhaps didn't realize that Roger had actually asked you to do the opposite of what he'd asked you to do -- it wasn't obvious to me the first time I went through it.)

Normally the thing to do would be to reply "Ping" to that patch, but given how long ago it was, it's probably a better idea to take the patch as it is, rebase it, and send it again (with [PATCH RESEND] in the subject line).

A couple of additional comments while I'm looking at it:
* After the v1->v2 change, you're no longer passing arbitrary options, so you should probably change the title of the patch again
* Don't include the patch version number in the commit message

 -George
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.