Re: [vdsm] [Spice-devel] [RFC]about the implement of text-based console

[Alon Levy]

 Itamar Heim píše v Čt 18. 10. 2012 v 20:32 +0200:
  On 10/18/2012 12:13 PM, Alon Levy wrote:
   On 10/16/2012 12:18 AM, David Jaša wrote:
 [snip]
   Extending spice to provide just serial console remoting
   actually
   seems
   the easiest way to provide remote text-only console because
   most of
   the
   code path is already mature (used for client to guest agent
   communication) and e.g. spicy to just provide a device where
   e.g.
   screen
   could connect or just provide the console itself.
  
   CCing spice-devel
  
   would it allow users to script with/over it like they can with
   ssh?
  
   If I understand correctly the idea is to add another channel for
   spice that would connect to a char device in qemu that in turn
   connects to a serial port. The result is a spice client that can
   display and interact, but not a scripting extension. We could
   also create a unix domain socket to expose this connection on
   the client, and the client could then use that for scripting
   (but this will be instead of displaying, since you can't
   multiplex the console in a meaningful way - unless you run
   screen/tmux over it maybe):
  
   remote-viewer --spice-console-unix-domain-socket /tmp/spice.uds
   (This option assumes we want a single console channel - if we
   have multiple we will need to name them too)
  
   Anyone will be able to script it using for instance:
   socat UNIX-CONNECT:/tmp/spice.uds SYSTEM:echo hello world
  
   We could also turn it into a pty (socat can do that).
  
  i think using spice this way may be a very good solution, to proxy
  a
  serial console.
  only caveat is it requires client to install spice, vs. just using
  ssh.
 
 Jarda (To:) actually asked me if this feature (serial device pass
 through without any graphics) was feasible for purposes of connecting
 remotely to serial console.
 Jarda, would the solution outlined by Alon be good for you?
 
 Alon, one problem comes to my mind though: it would need either
 second
 spice server, or multi-client support (limited one would be enough to
 have simultaneously one graphics user and one serial device user). Do
 you think it is possible to implement such things without much
 effort?

If we constrain it to one graphics only (no serial connection, i.e. same 
channels as today) and one serial only (i.e. main channel - since we have to 
have that, and the new serial console channel), I think it should not pose any 
of the problems keeping usable multiple client mode from being implemented, 
i.e. handling different speed clients.

 
 David
 
 --
 
 David Jaša, RHCE
 
 SPICE QE based in Brno
 GPG Key: 22C33E24
 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
 
 
 
 
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Re: [Qemu-devel] converging around a single guest agent

[Alon Levy]

On Wed, Nov 16, 2011 at 08:53:45AM +0100, Hans de Goede wrote:
 Hi,
 
 On 11/15/2011 11:39 PM, Ayal Baron wrote:
 
 
 snip
 
 If you want to talk about convergence, the discussion should start
 around
 collecting requirements.  We can then figure out if the two sets of
 requirements
 are strictly overlapping or if there are any requirements that are
 fundamentally
 in opposition.
 
 Agreed.
 
 So vdsm guest agent goal is to ease administration of VMs.  This is not 
 saying much as it is quite broad so I will list what is provided today and 
 some things we need to add:
 
 Assistance in VM life-cycle:
 desktopShutdown - Shuts the VM down gracefully from within the guest.
 quiesce - does not exist today.  This is definitely a requirement for us.
 
 SSO support for spice sessions (automatically login into guest OS using 
 provided credentials):
 desktopLock - lock current session, used when spice session gets 
 disconnected / before giving a new user access to spice session
 desktopLogin
 desktopLogoff
 In addition, guest reports relevant info (currently active user, session 
 state)
 
 Monitoring and inventory:
 currently agent sends info periodically, which includes a lot of info which 
 should probably be broken down and served upon request. Info includes -
 - memory usage
 - NICs info (name, hw, inet, inet6)
 - appslist (list of installed apps / rpms)
 - OS type
 - guest hostname
 - internal file systems info (path, fs type, total space, used space)
 
 
 snip
 
 If we're gathering requirements and trying to come up with one agent to rule 
 them all, don't forget
 about VDI and the Spice agent. Currently the spice agent handles the 
 following:
 
 1) Paravirtual mouse (needed to get mouse coordinates right with multi 
 monitor setups)
 2) Send client monitor configuration, so that the guest os can adjust its 
 resolution
(and number and place of monitors) to match the client
 3) Copy and paste in a platform neutral manner, if anyone wishes to add this 
 to another agent
please, please contact us (me) first. This is easy to get wrong (we went 
 through 2 revisions
of the protocol for this).
 4) Allow the client to request the guest to tone down the bling (for low spec 
 clients)
 
As long as we are collecting requirements, even if as Ayal said merging
spice requirements is not the OP's intent:

 5) Window management - Agent can set location of windows, report
 existing running applications and locations, get notified when a new
 window is created. For exposing individual applications, this is a
 future requirement.

 Notes:
 1) All of these are client - guest communication, rather then the host - 
 guest communication
 which the other agents seem to focus on.
 
 2) Getting copy paste right requires a system level guest agent process as 
 well as a per user
 session agent process.
 

 Regards,
 
 Hans
 
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel