From: "Daniel P. Berrangé" <berrange@redhat.com>
To: "Denis V. Lunev" <den@virtuozzo.com>
Cc: Alexander Ivanov <alexander.ivanov@virtuozzo.com>,
qemu-devel@nongnu.org, michael.roth@amd.com, kkostiuk@redhat.com,
marcandre.lureau@gmail.com
Subject: Re: [PATCH] qga: Add an interactive mode to guest-exec via VSOCK for Linux
Date: Thu, 23 May 2024 08:50:32 +0100 [thread overview]
Message-ID: <Zk71Bl1tGqkctSwr@redhat.com> (raw)
In-Reply-To: <3438f0db-120b-493d-ab61-71311699797f@virtuozzo.com>
On Thu, May 23, 2024 at 09:12:51AM +0200, Denis V. Lunev wrote:
> On 5/22/24 18:10, Daniel P. Berrangé wrote:
> > On Wed, May 22, 2024 at 05:06:57PM +0200, Alexander Ivanov wrote:
> > > Add an interactive mode to the guest-exec command in the QEMU Guest Agent
> > > using the VSOCK communication mechanism. It enables interactive sessions
> > > with the executed command in the guest, allowing real-time input/output.
> > >
> > > Introduce "interactive" mode in the GuestExecCaptureOutputMode enumeration
> > > and add optional "cid" and "port" fields to the guest-exec response. In
> > > such a way user can execute guest-exec command, get CID and port number
> > > from the response and connect to the guest server. After connection user
> > > can communicate with the started process. All the data transmitted to the
> > > server is redirected to stdin. Data from stdout and stderr is redirected
> > > to the client. All data blocks are preceded by 32-bit headers (network
> > > byte order): most significant bit contains a sign of stream (stdout - 0,
> > > stderr - 1), all the other bits contain the payload size.
> > Every patch to 'guest-exec' takes us torwards re-inventing yet more
> > SSH/telnet functionality, but a poor simulation of it. For exmaple
> > this still lacks any separation of stdout/stderr streams, just
> > interleaving all their data back to the host. There is also zero
> > access control facilities beyond turning off the 'guest-exec'
> > command entirely.
> >
> > IMHO we should really consider "arbitrary command execution" to be
> > something to be handled by a separate process. Let the guest OS admin
> > decide separately from running QEMU GA, whether they want to enable
> > arbitrary host processes to have a trival privileged backdoor into
> > their guest.
> >
> > systemd now supports exposing SSH over VSOCK, and provides an SSH
> > proxy in the host to connect to VMs, while libvirt also has added
> > its own host SSH proxy to allow SSH based on libvirt VM name.
> >
> > For windows guests, there is something called PowerShell Direct
> > which exposes PowerShell over vmbus under HyperV. Possibly that
> > can be enabled in QEMU too if someone understands windows & vmbus
> > enough... ?
> >
>
> That makes a lot of sense. Why to support something that is
> already written. Though I have a note about Windows. The
> approach could be exactly the same - OpenSSH port for Windows
> is already known and on top of that VirtIO VSock driver is
> available too. Why not?
I've not tested it myself, but I would assume (hope) that the Powershell
Direct feature is available in Windows guests "out of the box". The OpenSSH
+ VSock option would require extra user install work. I tend to favour
things which will "just work" without extra config in the guest.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2024-05-23 7:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-22 15:06 [PATCH] qga: Add an interactive mode to guest-exec via VSOCK for Linux Alexander Ivanov
2024-05-22 15:23 ` Test scripts Alexander Ivanov
2024-05-23 9:56 ` Alex Bennée
2024-05-22 15:38 ` [PATCH] qga: Add an interactive mode to guest-exec via VSOCK for Linux Michal Prívozník
2024-05-22 16:10 ` Daniel P. Berrangé
2024-05-23 7:12 ` Denis V. Lunev
2024-05-23 7:50 ` Daniel P. Berrangé [this message]
2024-05-23 7:57 ` Alexander Ivanov
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=Zk71Bl1tGqkctSwr@redhat.com \
--to=berrange@redhat.com \
--cc=alexander.ivanov@virtuozzo.com \
--cc=den@virtuozzo.com \
--cc=kkostiuk@redhat.com \
--cc=marcandre.lureau@gmail.com \
--cc=michael.roth@amd.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.