From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=59544 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PdKor-0004yr-DV for qemu-devel@nongnu.org; Thu, 13 Jan 2011 05:54:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PdKoq-0003fI-8e for qemu-devel@nongnu.org; Thu, 13 Jan 2011 05:54:17 -0500 Received: from mx1.redhat.com ([209.132.183.28]:7240) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PdKop-0003f5-Vi for qemu-devel@nongnu.org; Thu, 13 Jan 2011 05:54:16 -0500 Message-ID: <4D2ED9D1.1020803@redhat.com> Date: Thu, 13 Jan 2011 11:54:09 +0100 From: Gerd Hoffmann MIME-Version: 1.0 References: <4D2DD2F1.6030801@redhat.com> <1294913997.470174.17.camel@storm> In-Reply-To: <1294913997.470174.17.camel@storm> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [Spice-devel] spicevmv chardev, guest agents and paravirtual mouse List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: tiziano.mueller@stepping-stone.ch Cc: spice-devel , "qemu-devel@nongnu.org" Hi, >> (4) termial forwarding. Just an idea right now. Nowdays that the spice >> client side moves to gtk it would be easy to embed a termial widget, >> therby allowing easy access to the serial console using something >> like this: >> >> -chardev spicevmc,id=console,type=terminal >> -device isa-serial,index=0,chardev=console > > I guess this could be used to get more info about the state of a VM from > the host system (like "system is ready", "system is rebooting", etc), > although it needs some adjustments in the guest to use the serial > console and string parsing on the host. That is really just for a terminal / serial console. Running an guest agent protocol over a serial line instead of virtio-serial would be possible too, but that end would probably better handled by libvirt or some other management tool. > Would it therefore make sense to > have a another type to get such status messages from the guest and have > a list of states defined somewhere? If yes, is this something which > should be implemented in the spice-part or is this general qemu stuff? It is general qemu stuff and how to design that best is the whole point of this agent discussion ;) > Furthermore it would be nice if the client side could get a list of > display resolutions supported in the guest and having the possibility to > change the resolution when resizing the guest window. The vdagent > protocol already has a message to pass this info but it only sends it > when going into fullscreen mode. That is just a client implementation thing. The new spice-gtk client can send messages on window resize too. Guest is supposed to pick the closest resolution it can handle. > Yet another use case would be: authentication forwarding/injection to > the guest OS. With smartcard-support you have something like that, but > in our case we have the users authenticate against our management > backend first before they get access to a VM and it would be kind of > nice to be able to inject authentication data into the guest OS, either > via the spice client or coming from the host OS. Depends on the auth infrastructure whenever this is doable I guess. If you are using x509 certificates the smartcard support should serve just fine. I can also imagine that the guest can aquire kerberos tickets via spice-client or using some other agent for example (don't know kerberos good enougth to be sure though). cheers, Gerd