On 12/17/10 16:01, Anthony Liguori wrote:
On 12/17/2010 07:39 AM, Alon Levy wrote:
Adding a chardev backend for spice, for usage by spice vdagent in
conjunction with a properly named virtio-serial device.
Example usage:
qemu -device virtio-serial -chardev spicevmc,name=vdagent,id=vdagent
-devic
This example is incomplete btw ...
What doe this channel do?
It is a communication path between spice client and guest.
There used to be just one, for vdagent (spice guest agent) which sends
mouse events for example. There will be more in the future, and using
chardevs allows us to handle that.
I really don't feel comfortable with this. This is not connecting QEMU
to an existing interface that happens to fit our model.
This is clearly a "library" that provides thin wrappers around internal
QEMU interfaces to implement code that belongs in QEMU outside of QEMU.
No. This is about tunneling server/client connections through spice, so
we can reuse the authentication and encryption provided by spice.
Assume you have your VM running on machine A and you are sitting in
front of machine B. You want use the smartcard attached to host B in
your virtual machine.
Without spice you'll use this on machine A:
qemu -chardev socket,server,host=0.0.0.0,port=2001,id=ccid,nowait \
-usb -device usb-ccid -device ccid-card-passthru,chardev=ccid
and run "vscclient <machine A> 2001" on machine B.
With spice you'll use this on machine A:
qemu -chardev spicevmc,id=ccid,name=smartcard \
-usb -device usb-ccid -device ccid-card-passthru,chardev=ccid
and the spice client on machine B will forward the requests to vscclient
(well, I think it is actually linked to libcaccard, which is effectively
the same as vscclient just forwards the requests from the network to
libcaccard too).
There is no hidden magic.
cheers,
Gerd
