[libvirt] adding smartcard support to libvirt

[Daniel P. Berrange]

On Thu, Jan 06, 2011 at 08:05:55AM -0700, Eric Blake wrote:
> On 01/06/2011 04:33 AM, Alon Levy wrote:
> >> Hmm, right now, the only use of spice in XML is under <graphics
> >> type='spice'>, and it is the <graphics> element that contains port,
> >> tlsPort, autoport, and listen arguments.  So we may need to revisit
> >> that, and have some way to use a single location for spice parameters
> >> shared among all spice-related devices, and a way for both <graphics
> >> type='spice'> and <smartcard type='passthrough'> to reference that
> >> rather than repeating it.  Meaning that spicevmc support just got more
> >> difficult, if it involves tweaking <graphics> rather than just adding a
> >> new <channel type='spicevmc'> element.
> > 
> > Are you saying that for correctness you want to tie the two elements together?
> > I mean, that's the only possible reason I see. If you want to tie them
> > together to prevent an instance of spicevmc without an instance of graphics
> > of type spice, I understand. I guess (after seeing the patch you sent) there
> > is a verifier to the xml inputs to libvirt that would be able to deduce invalidity
> > in that case?
> > Of course the alternative is to have logic elsewhere, but I see the point in
> > trying to verify the xml input only at one place.
> 
> I'm thinking more along the lines that the spice parameters (port,
> tlsport, autoPort, listen, passwd, and child <channel> elements main,
> display, inputs, cursor, playback, and record) _might_ need to be
> specified independently from their current position under <graphics>,
> since we are likely adding new channels.  That is, I think it should be
> possible to use a spicevmc agent for _just_ a smartcard channel, while
> still using older vnc or other graphics, in which case specifying spice
> parameters living under <graphics> doesn't make sense, but neither
> should the spice parameters live under <smartcard>.  For that reason, it
> does seem to argue that creating a top-level <spice> element would make
> sense.

The primary reason for the tunnelling, is that it directly associates
the smartcard with your current remote desktop client. If you're not
using SPICE for the remote desktop, then there's no value in using
it for the smartcard.

NB, it is possible to configured multiple display protocols at the
same time (eg multiple <graphics> elements) but we've not supported
that in the QEMU driver yet. This would let you configure both VNC
and SPICE at the same time.

> However, it's a tricky proposition, because we have to maintain
> backwards compatibility; so _if_ we decide that making a higher-level
> <spice> element for fine-tuning spice parameters (rather than the
> current approach of sticking spice parameters under <graphics>), then
> yes, the XML parser will have to do consistency checks that either spice
> parameters are only provided in one location, or that the multiple
> locations are consistent.

As above, I don't think a <spice> element makes sense. The use of a
<graphics type=spice> element is the primary enabler. Only once you
have that, does it make sense to want to associate further devices
with that mechanism

Regards,
Daniel