On 10/14/2010 11:52 AM, Anthony Liguori wrote: > On 10/14/2010 01:37 PM, Robert Relyea wrote: >> Anthony Liguori wrote: >> >> >>> > And how does the smart card state get migrated during migration? How >>> > do you keep it synced with QEMU? >>> > >>> > I don't understand the use-case behind this. Is this so that a local >>> > physical smart card can be passed through to a guest from a Spice >>> > client and when migration happens, the QEMU instance connects back to >>> > the Spice client? So the device is never actually migrated? >>> >> A lot of this discussion has confused me until I realized we are talking >> 2 different models. >> >> My current understanding is that qemu assumes that all devices are local >> to the qemu instance (that is on the host). When you migrate you want to >> connect to the new hardware on the new host, not feed back to some >> general client. The only exception seems to be mouse and keyboard, where >> qemu depends on some external protocol (vncclient or xdesktop or the x >> protocol itself) to transport the mouse and keyboard events. >> >> Our model has been that the smart card is local to the user/client -- >> like the mouse and keyboard. When you migrate qemu you do not migrate >> the smart card itself, since it's still physically on your client >> machine (like the mouse and keyboard), and needs to be managed by the >> local drivers on that client machine (which knows how to talk to the >> specific smart card installed there). So the daemon stays right where >> it's at and connects to the new qemu instance as it comes up. This is >> where I think I was confused about your migration question. I think you >> are assuming that the smart card itself connects to new hardware on the >> new host, meaning the daemon itself needs to move. If that is the >> semantic you are trying to present, then you are quite right, it's >> ludicrous to have the external daemon as part of the emulation. >> > > > Remote device passthrough is just a special case of passthrough. It's > got interesting characteristics in that unlike local device > passthrough, if you preserve the connection to the remove device, > migration is still possible. > > However, remote device *emulation* is the thing that I'm concerned > about. Having a device emulated outside of QEMU means that it's not > possible to participate in many of QEMU's features (like live > migration, tracing, debugging, etc.). Device creation is extremely > complicated because you have to launch the external daemon and somehow > configure that. There's always some emulation going on on the client side. The client side has the device drivers, so you are either emulating an actual device or you are emulating the abstraction you invent. Once you have the client side, you have to launch the external daemon anyway.
It seems to me that the best way to go is to provide the native host == client support like other devices and allow the passthru. If you really need client support, just run spice (which is a single client daemon that handles everything). > > I have no objection to remote device passthrough but I don't think > remote device emulation is right for QEMU today. Probably right for raw qemu. > > After talking to Alon in IRC, I think a better model for Spice would > be to integrate the smart card emulation into QEMU and then develop a > specific protocol for the smart card emulation to interface with the > physical smart card. This interface isn't really any different than > the network interface or the block interface in QEMU today. I seems to me that a second protocol is overkill. Having 2 protocols is a bit much to manage. We can do everything we need with the passthru. My worry about creating any thing else is we may not have the flexibility to handle future cards. Smart cards themselves are programmable, so the interface for new cards are pretty dynamic. bob > > Regards, > > Anthony Liguori > >> It now appears to me that qemu punts on this case, except for the >> keyboard and mouse -- well maybe not punts, but simply doesn't support >> any device that isn't on the host machine. If you look at the way qemu >> handles the sound device, for instance. Normally you want the sound to >> come out the speakers of the controlling console, not a random server >> that's hosting the guest. However, straight qemu doesn't handle things >> that way. The sound (if it comes out at all) comes out the server that >> qemu is installed on. When you migrate qemu, the sound now comes out the >> new server. >> >> This probably isn't a problem since most of the time someone is using >> the speaker, he's got the case where host == client. In that case it >> makes perfect sense to put the emulator inside qemu. In the case where >> we are running a hosted server service, it's highly unlikely anyone is >> going to be using sound (or an attached webcam, etc.). In fact migration >> for these devices are really a noop. >> >> Smart cards are really like these devices. In fact more than a few >> keyboards have built in smart card readers. The smart card model is I >> want the smart card at the same location as my keyboard and mouse. I use >> that set of smart cards to authenticate. The use case on machines >> running with a server is that some customers have a requirement that you >> need the smart card to log in and administer those machines. Those smart >> cards are ones the operator carries with him, not ones that would sit on >> some server farm. For their requirements, one needs a way to get back to >> the local client. >> >> As I said before, I don't think this requirement is unique. The only way >> to handle it is to run code on the client machine. The devices that run >> on that client are ones you don't migrate with qemu, but stay with the >> client itself and reconnect to the new instance. I agree that having a >> daemon for each devices will eventually become unweildy. It looks like >> spice is the answer for this scenario. If you have devices other than >> the mouse/keyboard/display that are located on the client == host, then >> you should assume the need for spice and not use straight qemu? >> >> In that world it makes sense to have a single protocol (passthru). It's >> ok to integrate the smart card emul directly into qemu because it's >> really only used either in the case where client != host, or in the case >> where your server hardware has some smart card installed that is uses >> for authentication. (NOTE: in this case, migrate means that the server >> will loose authentication and have to authenticate with the new smart >> card on the new host... I don't know how useful this really is, but I >> think it's important to point out that migrate with smart cards means >> something different than most devices. It means you have become a new >> entity, not a continuation of the old... it's the equivalent of pulling >> a smart card on a server and inserting a new one). >> >> So if my understanding is correct, as long as you are willing to deal >> with the card plug/unplug scenario on migration, it makes sense for qemu >> to have passthru plus a local emulated smart card which goes directly to >> local hardward. If you need to have the 'console' experience, then you >> turn on spice and emulate the card in the spice client. >> >> bob >> >> >> >> >> >> >> >> >
smime.p7s
Description: S/MIME Cryptographic Signature
