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. 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
