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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).