From: Daniel Veillard <veillard@redhat.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] Remote console access though socket
Date: Sat, 11 Mar 2006 15:53:55 -0500 [thread overview]
Message-ID: <20060311205355.GJ346@redhat.com> (raw)
In-Reply-To: <c1bf1cf0603081235u118aade2o120f94347602dc3b@mail.gmail.com>
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/
veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
next prev parent reply other threads:[~2006-03-11 20:54 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-08 14:52 [Qemu-devel] [PATCH] Remote console access though socket Daniel Veillard
[not found] ` <16af12af0603081035h5f61d947y6c24b7a7675eeb14@mail.gmail.com>
2006-03-08 20:35 ` Ed Swierk
2006-03-11 20:53 ` Daniel Veillard [this message]
2006-03-11 16:24 ` Oliver Gerlich
2006-03-11 20:59 ` Daniel Veillard
2006-03-11 22:22 ` Oliver Gerlich
2006-03-12 11:03 ` Daniel Veillard
2006-03-11 21:07 ` Daniel Veillard
-- strict thread matches above, loose matches on Subject: below --
2006-03-09 12:47 wanderer
2006-03-09 12:55 ` Daniel Veillard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060311205355.GJ346@redhat.com \
--to=veillard@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.