When linux-specific commands (including guest-fsfreeze-*) were consolidated
under defined(__linux__), we forgot to account for the case where
defined(__linux__) && !defined(FIFREEZE). As a result stubs are no longer
being generated on linux hosts that don't have FIFREEZE support. Fix
this.
Tested-by: Andreas Färber <afaerber@suse.de>
Reviewed-by: Luiz Capitulino <lcapitulino@redhat.com>
In the function ga_channel_write(), the handle ov.hEvent is created
by the call to CreateEvent(). However, the handle is not closed
prior to the function return.
This patch closes the handle before the return of the function.
Kudos to Paolo Bonzini for spotting this bug.
Signed-off-by: Jeff Cody <jcody@redhat.com>
Acked-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
guest-sync leaves it as an exercise to the user as to how to reliably
obtain the response to guest-sync if the client had previously read in a
partial response (due qemu-ga previously being restarted mid-"sentence"
due to reboot, forced restart, etc).
qemu-ga handles this situation on its end by having a client precede
their guest-sync request with a 0xFF byte (invalid UTF-8), which
qemu-ga/QEMU JSON parsers will treat as a flush event. Thus we can
reliably flush the qemu-ga parser state in preparation for receiving
the guest-sync request.
guest-sync-delimited provides the same functionality for a client: when
a guest-sync-delimited is issued, qemu-ga will precede it's response
with a 0xFF byte that the client can use as an indicator to flush its
buffer/parser state in preparation for reliably receiving the
guest-sync-delimited response.
It is also useful as an optimization for clients, since, after issuing a
guest-sync-delimited, clients can safely discard all stale data read
from the channel until the 0xFF is found.
More information available on the wiki:
http://wiki.qemu.org/Features/QAPI/GuestAgent#QEMU_Guest_Agent_Protocol
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
This command returns an array of:
[ifname, hwaddr, [ipaddr, ipaddr_family, prefix] ]
for each interface in the system.
Currently, only IPv4 and IPv6 are supported.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Implement guest-suspend-disk RPC for Windows. Functionally this should be
equivalent to the posix implementation.
Signed-off-by: Gal Hammer <ghammer@redhat.com>
As the command name implies, this command suspends the guest to disk.
The suspend operation is implemented by two functions: bios_supports_mode()
and guest_suspend(). Both functions are generic enough to be used by
other suspend modes (introduced by next commits).
Both functions will try to use the scripts provided by the pm-utils
package if it's available. If it's not available, a manual method,
which consists of directly writing to '/sys/power/state', will be used.
To reap terminated children, a new signal handler is installed in the
parent to catch SIGCHLD signals and a non-blocking call to waitpid()
is done to collect their exit statuses. The statuses, however, are
discarded.
The approach used to query the guest for suspend support deserves some
explanation. It's implemented by bios_supports_mode() and shown below:
qemu-ga
|
create pipe
|
fork()
-----------------
| |
| |
| fork()
| --------------------------
| | |
| | |
| | exec('pm-is-supported')
| |
| wait()
| write exit status to pipe
| exit
|
read pipe
This might look complex, but the resulting code is quite simple.
The purpose of that approach is to allow qemu-ga to reap its children
(semi-)automatically from its SIGCHLD handler.
Implementing this the obvious way, that's, doing the exec() call from
the first child process, would force us to introduce a more complex way
to reap qemu-ga's children. Like registering PIDs to be reaped and
having a way to wait for them when returning their exit status to
qemu-ga is necessary. The approach explained above avoids that complexity.
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Implement guest-shutdown RPC for Windows. Functionally this should be
equivalent to the posix implementation.
Original patch by Gal Hammer <ghammer@redhat.com>
This allows qemu-ga to function as a Windows service:
- to install the service (will auto-start on boot):
qemu-ga --service install
- to start the service:
net start qemu-ga
- to stop the service:
net stop qemu-ga
- to uninstall service:
qemu-ga --service uninstall
Original patch by Gal Hammer <ghammer@redhat.com>
This adds a win32 channel implementation that makes qemu-ga functional
on Windows using virtio-serial (unix-listen/isa-serial not currently
implemented). Unlike with the posix implementation, we do not use
GIOChannel for the following reasons:
- glib calls stat() on an fd to check whether S_IFCHR is set, which is
the case for virtio-serial on win32. Because of that, a one-time
check to determine whether the channel is readable is done by making
a call to PeekConsoleInput(), which reports the underlying handle is
not a valid console handle, and thus we can never read from the
channel.
- if one goes as far as to "trick" glib into thinking it is a normal
file descripter, the buffering is done in such a way that data
written to the output stream will subsequently result in that same
data being read back as if it were input, causing an error loop.
furthermore, a forced flush of the channel only moves the data into a
secondary buffer managed by glib, so there's no way to prevent output
from getting read back as input.
The implementation here ties into the glib main loop by implementing a
custom GSource that continually submits asynchronous/overlapped I/O to
fill an GAChannel-managed read buffer, and tells glib to poll the
corresponding event handle for a completion whenever there is no
data/RPC in the read buffer to notify the main application about.
Various stubs and #ifdefs to compile for Windows using mingw
cross-build. Still has 1 linker error due to a dependency on the
forthcoming win32 versions of the GAChannel/transport class.
Many of the current RPC implementations are very much POSIX-specific
and require complete re-writes for Windows. There are however a small
set of core guest agent commands that are common to both, and other
commands such as guest-file-* which *may* be portable. So we introduce
commands.c for the latter, and will rename guest-agent-commands.c to
commands-posix.c in a future commit. Windows implementations will go in
commands-win32.c, eventually.
This is mostly in preparation for the win32 port, which won't use
GIO channels for reasons that will be made clearer later. Here the
GAChannel class is just a loose wrapper around GIOChannel
calls/callbacks, but we also roll in the logic/configuration for
various channel types and managing unix socket connections, which makes
the abstraction much more complete and further aids in the win32 port
since isa-serial/unix-listen will not be supported initially.
There's also a bit of refactoring in the main logic to consolidate the
exit paths so we can do common cleanup for things like pid files, which
weren't always cleaned up previously.
Not that there is blacklisting functionality we can no longer infer
the agent's capabilities via version. This patch extends the current
guest-info RPC to also return a list of dictionaries containing the name
of each supported RPC, along with a boolean indicating whether or not
the command has been disabled by a guest administrator/distro.
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This is the actual guest daemon, it listens for requests over a
virtio-serial/isa-serial/unix socket channel and routes them through
to dispatch routines, and writes the results back to the channel in
a manner similar to QMP.
A shorthand invocation:
qemu-ga -d
Is equivalent to:
qemu-ga -m virtio-serial -p /dev/virtio-ports/org.qemu.guest_agent.0 \
-f /var/run/qemu-ga.pid -d
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: Luiz Capitulino <lcapitulino@gmail.com>
