qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] Remote console access though socket


From: Daniel Veillard
Subject: Re: [Qemu-devel] [PATCH] Remote console access though socket
Date: Sat, 11 Mar 2006 15:53:55 -0500
User-agent: Mutt/1.4.1i

On Wed, Mar 08, 2006 at 12:35:13PM -0800, Ed Swierk wrote:
> Daniel Veillard wrote:
> > enclosed is a first version of a patch to allow remote access and control
> > for QEmu instances, I'm not suggesting to apply it as is (though it seems
> > to work in my limited testing) but would rather like to get comments back
> > for choices I'm facing.
> 
> This sounds pretty nice. A few general comments:
> 
> A few weeks ago I wrote a qemu daemon manager. It's a pretty simple
> script that manages multiple qemu processes, launching each one in an
> instance of screen. screen does most of the dirty work of keeping
> track of running processes, assigning a name to each process,
> attaching to a process's console, terminating a process, etc. Of
> course screen has many more features that we don't really need, but it
> might be worth looking at screen as a model for implementing the
> functions you describe.

  I don't see how this would solve the problems I asked about:
    - discovery of running instances if not using a filesystem based socket
    - being able to hook up to qemu instances which are older than
      the program you're trying to control them from.
I know screen, it's good for handling a few number of console, but it's
not really what I'm trying to get at, really.

[...]
> If qemu provides access to its console via a socket, this is just
> another resource that a manager can deal with, perhaps passing the
> desired port number to qemu via the command line.

  But for that you need to know the given port a priori, i.e. before lauch
which limits a lot the usefulness of the control tool. So far I only see
filesystem based discoveey access, I was hoping for something better, maybe
there isn't a better way ...

Daniel

-- 
Daniel Veillard      | Red Hat http://redhat.com/
address@hidden  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]