2011-07-21 00:19:37 +04:00
|
|
|
/*
|
|
|
|
* QEMU Guest Agent
|
|
|
|
*
|
|
|
|
* Copyright IBM Corp. 2011
|
|
|
|
*
|
|
|
|
* Authors:
|
|
|
|
* Adam Litke <aglitke@linux.vnet.ibm.com>
|
|
|
|
* Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
|
|
*
|
|
|
|
* This work is licensed under the terms of the GNU GPL, version 2 or later.
|
|
|
|
* See the COPYING file in the top-level directory.
|
|
|
|
*/
|
|
|
|
#include <stdlib.h>
|
|
|
|
#include <stdio.h>
|
|
|
|
#include <stdbool.h>
|
|
|
|
#include <glib.h>
|
|
|
|
#include <getopt.h>
|
2012-01-20 08:04:34 +04:00
|
|
|
#ifndef _WIN32
|
2011-07-21 00:19:37 +04:00
|
|
|
#include <syslog.h>
|
qemu-ga: add guest-suspend-disk
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>
2012-02-28 18:03:03 +04:00
|
|
|
#include <sys/wait.h>
|
qemu-ga: persist tracking of fsfreeze state via filesystem
Currently, qemu-ga may die/get killed/go away for whatever reason after
guest-fsfreeze-freeze has been issued, and before guest-fsfreeze-thaw
has been issued. This means the only way to unfreeze the guest is via
VNC/network/console access, but obtaining that access after-the-fact can
often be very difficult when filesystems are frozen. Logins will almost
always hang, for instance. In many cases the only recourse would be to
reboot the guest without any quiescing of volatile state, which makes
this a corner-case worth giving some attention to.
A likely failsafe for this situation would be to use a watchdog to
restart qemu-ga if it goes away. There are some precautions qemu-ga
needs to take in order to avoid immediately hanging itself on I/O,
however, namely, we must disable logging and defer to processing/creation
of user-specific logfiles, along with creation of the pid file if we're
running as a daemon. We also need to disable non-fsfreeze-safe commands,
as we normally would when processing the guest-fsfreeze-freeze command.
To track when we need to do this in a way that persists between multiple
invocations of qemu-ga, we create a file on the guest filesystem before
issuing the fsfreeze, and delete it when doing the thaw. On qemu-ga
startup, we check for the existance of this file to determine
the need to take the above precautions.
We're forced to do it this way since a more traditional approach such as
reading/writing state to a dedicated state file will cause
access/modification time updates, respectively, both of which will hang
if the file resides on a frozen filesystem. Both can occur even if
relatime is enabled. Checking for file existence will not update the
access time, however, so it's a safe way to check for fsfreeze state.
An actual watchdog-based restart of qemu-ga can itself cause an access
time update that would thus hang the invocation of qemu-ga, but the
logic to workaround that can be handled via the watchdog, so we don't
address that here (for relatime we'd periodically touch the qemu-ga
binary if the file $qga_statedir/qga.state.isfrozen is not present, this
avoids qemu-ga updates or the 1 day relatime threshold causing an
access-time update if we try to respawn qemu-ga shortly after it goes
away)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2012-04-19 01:28:01 +04:00
|
|
|
#include <sys/stat.h>
|
2012-01-20 08:04:34 +04:00
|
|
|
#endif
|
2012-12-17 21:19:43 +04:00
|
|
|
#include "qapi/qmp/json-streamer.h"
|
|
|
|
#include "qapi/qmp/json-parser.h"
|
|
|
|
#include "qapi/qmp/qint.h"
|
|
|
|
#include "qapi/qmp/qjson.h"
|
2011-07-21 00:19:37 +04:00
|
|
|
#include "qga/guest-agent-core.h"
|
2012-12-17 21:20:00 +04:00
|
|
|
#include "qemu/module.h"
|
2011-07-21 00:19:37 +04:00
|
|
|
#include "signal.h"
|
2012-12-17 21:19:43 +04:00
|
|
|
#include "qapi/qmp/qerror.h"
|
|
|
|
#include "qapi/qmp/dispatch.h"
|
2012-01-19 10:18:20 +04:00
|
|
|
#include "qga/channel.h"
|
2012-01-22 02:42:27 +04:00
|
|
|
#ifdef _WIN32
|
|
|
|
#include "qga/service-win32.h"
|
|
|
|
#include <windows.h>
|
|
|
|
#endif
|
2012-12-12 07:55:55 +04:00
|
|
|
#ifdef __linux__
|
|
|
|
#include <linux/fs.h>
|
|
|
|
#ifdef FIFREEZE
|
|
|
|
#define CONFIG_FSFREEZE
|
|
|
|
#endif
|
|
|
|
#endif
|
2011-07-21 00:19:37 +04:00
|
|
|
|
qemu-ga: add initial win32 support
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.
2012-01-21 05:01:30 +04:00
|
|
|
#ifndef _WIN32
|
2011-07-21 00:19:37 +04:00
|
|
|
#define QGA_VIRTIO_PATH_DEFAULT "/dev/virtio-ports/org.qemu.guest_agent.0"
|
qemu-ga: add initial win32 support
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.
2012-01-21 05:01:30 +04:00
|
|
|
#else
|
|
|
|
#define QGA_VIRTIO_PATH_DEFAULT "\\\\.\\Global\\org.qemu.guest_agent.0"
|
|
|
|
#endif
|
2012-10-04 01:35:58 +04:00
|
|
|
#define QGA_STATEDIR_DEFAULT CONFIG_QEMU_LOCALSTATEDIR "/run"
|
|
|
|
#define QGA_PIDFILE_DEFAULT QGA_STATEDIR_DEFAULT "/qemu-ga.pid"
|
2012-12-12 07:55:55 +04:00
|
|
|
#ifdef CONFIG_FSFREEZE
|
|
|
|
#define QGA_FSFREEZE_HOOK_DEFAULT CONFIG_QEMU_CONFDIR "/fsfreeze-hook"
|
|
|
|
#endif
|
2012-02-07 23:56:48 +04:00
|
|
|
#define QGA_SENTINEL_BYTE 0xFF
|
2011-07-21 00:19:37 +04:00
|
|
|
|
|
|
|
struct GAState {
|
|
|
|
JSONMessageParser parser;
|
|
|
|
GMainLoop *main_loop;
|
2012-01-19 10:18:20 +04:00
|
|
|
GAChannel *channel;
|
2011-07-21 00:19:37 +04:00
|
|
|
bool virtio; /* fastpath to check for virtio to deal with poll() quirks */
|
|
|
|
GACommandState *command_state;
|
|
|
|
GLogLevelFlags log_level;
|
|
|
|
FILE *log_file;
|
|
|
|
bool logging_enabled;
|
2012-01-22 02:42:27 +04:00
|
|
|
#ifdef _WIN32
|
|
|
|
GAService service;
|
|
|
|
#endif
|
2012-02-07 23:56:48 +04:00
|
|
|
bool delimit_response;
|
2012-04-18 04:01:45 +04:00
|
|
|
bool frozen;
|
|
|
|
GList *blacklist;
|
qemu-ga: persist tracking of fsfreeze state via filesystem
Currently, qemu-ga may die/get killed/go away for whatever reason after
guest-fsfreeze-freeze has been issued, and before guest-fsfreeze-thaw
has been issued. This means the only way to unfreeze the guest is via
VNC/network/console access, but obtaining that access after-the-fact can
often be very difficult when filesystems are frozen. Logins will almost
always hang, for instance. In many cases the only recourse would be to
reboot the guest without any quiescing of volatile state, which makes
this a corner-case worth giving some attention to.
A likely failsafe for this situation would be to use a watchdog to
restart qemu-ga if it goes away. There are some precautions qemu-ga
needs to take in order to avoid immediately hanging itself on I/O,
however, namely, we must disable logging and defer to processing/creation
of user-specific logfiles, along with creation of the pid file if we're
running as a daemon. We also need to disable non-fsfreeze-safe commands,
as we normally would when processing the guest-fsfreeze-freeze command.
To track when we need to do this in a way that persists between multiple
invocations of qemu-ga, we create a file on the guest filesystem before
issuing the fsfreeze, and delete it when doing the thaw. On qemu-ga
startup, we check for the existance of this file to determine
the need to take the above precautions.
We're forced to do it this way since a more traditional approach such as
reading/writing state to a dedicated state file will cause
access/modification time updates, respectively, both of which will hang
if the file resides on a frozen filesystem. Both can occur even if
relatime is enabled. Checking for file existence will not update the
access time, however, so it's a safe way to check for fsfreeze state.
An actual watchdog-based restart of qemu-ga can itself cause an access
time update that would thus hang the invocation of qemu-ga, but the
logic to workaround that can be handled via the watchdog, so we don't
address that here (for relatime we'd periodically touch the qemu-ga
binary if the file $qga_statedir/qga.state.isfrozen is not present, this
avoids qemu-ga updates or the 1 day relatime threshold causing an
access-time update if we try to respawn qemu-ga shortly after it goes
away)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2012-04-19 01:28:01 +04:00
|
|
|
const char *state_filepath_isfrozen;
|
|
|
|
struct {
|
|
|
|
const char *log_filepath;
|
|
|
|
const char *pid_filepath;
|
|
|
|
} deferred_options;
|
2012-12-12 07:55:55 +04:00
|
|
|
#ifdef CONFIG_FSFREEZE
|
|
|
|
const char *fsfreeze_hook;
|
|
|
|
#endif
|
2011-07-21 00:19:37 +04:00
|
|
|
};
|
|
|
|
|
2012-02-07 23:56:48 +04:00
|
|
|
struct GAState *ga_state;
|
2011-07-21 00:19:37 +04:00
|
|
|
|
2012-04-18 04:01:45 +04:00
|
|
|
/* commands that are safe to issue while filesystems are frozen */
|
|
|
|
static const char *ga_freeze_whitelist[] = {
|
|
|
|
"guest-ping",
|
|
|
|
"guest-info",
|
|
|
|
"guest-sync",
|
|
|
|
"guest-fsfreeze-status",
|
|
|
|
"guest-fsfreeze-thaw",
|
|
|
|
NULL
|
|
|
|
};
|
|
|
|
|
2012-01-22 02:42:27 +04:00
|
|
|
#ifdef _WIN32
|
|
|
|
DWORD WINAPI service_ctrl_handler(DWORD ctrl, DWORD type, LPVOID data,
|
|
|
|
LPVOID ctx);
|
|
|
|
VOID WINAPI service_main(DWORD argc, TCHAR *argv[]);
|
|
|
|
#endif
|
|
|
|
|
2011-07-21 00:19:37 +04:00
|
|
|
static void quit_handler(int sig)
|
|
|
|
{
|
2012-04-18 04:01:45 +04:00
|
|
|
/* if we're frozen, don't exit unless we're absolutely forced to,
|
|
|
|
* because it's basically impossible for graceful exit to complete
|
|
|
|
* unless all log/pid files are on unfreezable filesystems. there's
|
|
|
|
* also a very likely chance killing the agent before unfreezing
|
|
|
|
* the filesystems is a mistake (or will be viewed as one later).
|
|
|
|
*/
|
|
|
|
if (ga_is_frozen(ga_state)) {
|
|
|
|
return;
|
|
|
|
}
|
2011-08-28 23:45:40 +04:00
|
|
|
g_debug("received signal num %d, quitting", sig);
|
2011-07-21 00:19:37 +04:00
|
|
|
|
|
|
|
if (g_main_loop_is_running(ga_state->main_loop)) {
|
|
|
|
g_main_loop_quit(ga_state->main_loop);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-01-22 02:42:27 +04:00
|
|
|
#ifndef _WIN32
|
2012-01-19 10:18:20 +04:00
|
|
|
static gboolean register_signal_handlers(void)
|
2011-07-21 00:19:37 +04:00
|
|
|
{
|
qemu-ga: guest-suspend: make the API synchronous
Currently, qemu-ga has a SIGCHLD handler that automatically reaps terminated
children processes. The idea is to avoid having qemu-ga commands blocked
waiting for children to terminate.
That approach has two problems:
1. qemu-ga is unable to detect errors in the child, meaning that qemu-ga
returns success even if the child fails to perform its task
2. if a command does depend on the child exit status, the command has to
play tricks to bypass the automatic reaper
Case 2 impacts the guest-suspend-* API, because it has to execute an external
program to check for suspend support. Today, to bypass the automatic reaper,
suspend code has to double fork and pass exit status information through a
pipe. Besides being complex, this is prone to race condition bugs. Indeed,
the current code does have such bugs.
Making the guest-suspend-* API synchronous (ie. by dropping the SIGCHLD
handler and calling waitpid() from commands) is a much simpler approach,
which fixes current race conditions bugs and enables commands to detect
errors in the child.
This commit does just that. There's a side effect though, guest-shutdown
will generate zombies if shutting down fails. This will be fixed by the
next commit.
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2012-05-11 23:19:46 +04:00
|
|
|
struct sigaction sigact;
|
2011-07-21 00:19:37 +04:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
memset(&sigact, 0, sizeof(struct sigaction));
|
|
|
|
sigact.sa_handler = quit_handler;
|
|
|
|
|
|
|
|
ret = sigaction(SIGINT, &sigact, NULL);
|
|
|
|
if (ret == -1) {
|
|
|
|
g_error("error configuring signal handler: %s", strerror(errno));
|
|
|
|
}
|
|
|
|
ret = sigaction(SIGTERM, &sigact, NULL);
|
|
|
|
if (ret == -1) {
|
|
|
|
g_error("error configuring signal handler: %s", strerror(errno));
|
|
|
|
}
|
qemu-ga: add guest-suspend-disk
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>
2012-02-28 18:03:03 +04:00
|
|
|
|
2012-01-19 10:18:20 +04:00
|
|
|
return true;
|
2011-07-21 00:19:37 +04:00
|
|
|
}
|
2012-05-10 23:50:41 +04:00
|
|
|
|
|
|
|
/* TODO: use this in place of all post-fork() fclose(std*) callers */
|
|
|
|
void reopen_fd_to_null(int fd)
|
|
|
|
{
|
|
|
|
int nullfd;
|
|
|
|
|
|
|
|
nullfd = open("/dev/null", O_RDWR);
|
|
|
|
if (nullfd < 0) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
dup2(nullfd, fd);
|
|
|
|
|
|
|
|
if (nullfd != fd) {
|
|
|
|
close(nullfd);
|
|
|
|
}
|
|
|
|
}
|
2012-01-20 08:04:34 +04:00
|
|
|
#endif
|
2011-07-21 00:19:37 +04:00
|
|
|
|
|
|
|
static void usage(const char *cmd)
|
|
|
|
{
|
|
|
|
printf(
|
2012-04-17 20:28:27 +04:00
|
|
|
"Usage: %s [-m <method> -p <path>] [<options>]\n"
|
2011-07-21 00:19:37 +04:00
|
|
|
"QEMU Guest Agent %s\n"
|
|
|
|
"\n"
|
|
|
|
" -m, --method transport method: one of unix-listen, virtio-serial, or\n"
|
|
|
|
" isa-serial (virtio-serial is the default)\n"
|
2012-04-17 20:28:27 +04:00
|
|
|
" -p, --path device/socket path (the default for virtio-serial is:\n"
|
|
|
|
" %s)\n"
|
2011-07-21 00:19:37 +04:00
|
|
|
" -l, --logfile set logfile path, logs to stderr by default\n"
|
|
|
|
" -f, --pidfile specify pidfile (default is %s)\n"
|
2012-12-12 07:55:55 +04:00
|
|
|
#ifdef CONFIG_FSFREEZE
|
|
|
|
" -F, --fsfreeze-hook\n"
|
|
|
|
" enable fsfreeze hook. Accepts an optional argument that\n"
|
|
|
|
" specifies script to run on freeze/thaw. Script will be\n"
|
|
|
|
" called with 'freeze'/'thaw' arguments accordingly.\n"
|
|
|
|
" (default is %s)\n"
|
|
|
|
" If using -F with an argument, do not follow -F with a\n"
|
|
|
|
" space.\n"
|
|
|
|
" (for example: -F/var/run/fsfreezehook.sh)\n"
|
|
|
|
#endif
|
qemu-ga: persist tracking of fsfreeze state via filesystem
Currently, qemu-ga may die/get killed/go away for whatever reason after
guest-fsfreeze-freeze has been issued, and before guest-fsfreeze-thaw
has been issued. This means the only way to unfreeze the guest is via
VNC/network/console access, but obtaining that access after-the-fact can
often be very difficult when filesystems are frozen. Logins will almost
always hang, for instance. In many cases the only recourse would be to
reboot the guest without any quiescing of volatile state, which makes
this a corner-case worth giving some attention to.
A likely failsafe for this situation would be to use a watchdog to
restart qemu-ga if it goes away. There are some precautions qemu-ga
needs to take in order to avoid immediately hanging itself on I/O,
however, namely, we must disable logging and defer to processing/creation
of user-specific logfiles, along with creation of the pid file if we're
running as a daemon. We also need to disable non-fsfreeze-safe commands,
as we normally would when processing the guest-fsfreeze-freeze command.
To track when we need to do this in a way that persists between multiple
invocations of qemu-ga, we create a file on the guest filesystem before
issuing the fsfreeze, and delete it when doing the thaw. On qemu-ga
startup, we check for the existance of this file to determine
the need to take the above precautions.
We're forced to do it this way since a more traditional approach such as
reading/writing state to a dedicated state file will cause
access/modification time updates, respectively, both of which will hang
if the file resides on a frozen filesystem. Both can occur even if
relatime is enabled. Checking for file existence will not update the
access time, however, so it's a safe way to check for fsfreeze state.
An actual watchdog-based restart of qemu-ga can itself cause an access
time update that would thus hang the invocation of qemu-ga, but the
logic to workaround that can be handled via the watchdog, so we don't
address that here (for relatime we'd periodically touch the qemu-ga
binary if the file $qga_statedir/qga.state.isfrozen is not present, this
avoids qemu-ga updates or the 1 day relatime threshold causing an
access-time update if we try to respawn qemu-ga shortly after it goes
away)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2012-04-19 01:28:01 +04:00
|
|
|
" -t, --statedir specify dir to store state information (absolute paths\n"
|
|
|
|
" only, default is %s)\n"
|
2011-07-21 00:19:37 +04:00
|
|
|
" -v, --verbose log extra debugging information\n"
|
|
|
|
" -V, --version print version information and exit\n"
|
|
|
|
" -d, --daemonize become a daemon\n"
|
2012-01-22 02:42:27 +04:00
|
|
|
#ifdef _WIN32
|
|
|
|
" -s, --service service commands: install, uninstall\n"
|
2012-01-20 08:04:34 +04:00
|
|
|
#endif
|
2012-04-17 20:28:27 +04:00
|
|
|
" -b, --blacklist comma-separated list of RPCs to disable (no spaces, \"?\"\n"
|
2011-12-07 08:03:42 +04:00
|
|
|
" to list available RPCs)\n"
|
2011-07-21 00:19:37 +04:00
|
|
|
" -h, --help display this help and exit\n"
|
|
|
|
"\n"
|
|
|
|
"Report bugs to <mdroth@linux.vnet.ibm.com>\n"
|
2012-05-14 18:33:48 +04:00
|
|
|
, cmd, QEMU_VERSION, QGA_VIRTIO_PATH_DEFAULT, QGA_PIDFILE_DEFAULT,
|
2012-12-12 07:55:55 +04:00
|
|
|
#ifdef CONFIG_FSFREEZE
|
|
|
|
QGA_FSFREEZE_HOOK_DEFAULT,
|
|
|
|
#endif
|
qemu-ga: persist tracking of fsfreeze state via filesystem
Currently, qemu-ga may die/get killed/go away for whatever reason after
guest-fsfreeze-freeze has been issued, and before guest-fsfreeze-thaw
has been issued. This means the only way to unfreeze the guest is via
VNC/network/console access, but obtaining that access after-the-fact can
often be very difficult when filesystems are frozen. Logins will almost
always hang, for instance. In many cases the only recourse would be to
reboot the guest without any quiescing of volatile state, which makes
this a corner-case worth giving some attention to.
A likely failsafe for this situation would be to use a watchdog to
restart qemu-ga if it goes away. There are some precautions qemu-ga
needs to take in order to avoid immediately hanging itself on I/O,
however, namely, we must disable logging and defer to processing/creation
of user-specific logfiles, along with creation of the pid file if we're
running as a daemon. We also need to disable non-fsfreeze-safe commands,
as we normally would when processing the guest-fsfreeze-freeze command.
To track when we need to do this in a way that persists between multiple
invocations of qemu-ga, we create a file on the guest filesystem before
issuing the fsfreeze, and delete it when doing the thaw. On qemu-ga
startup, we check for the existance of this file to determine
the need to take the above precautions.
We're forced to do it this way since a more traditional approach such as
reading/writing state to a dedicated state file will cause
access/modification time updates, respectively, both of which will hang
if the file resides on a frozen filesystem. Both can occur even if
relatime is enabled. Checking for file existence will not update the
access time, however, so it's a safe way to check for fsfreeze state.
An actual watchdog-based restart of qemu-ga can itself cause an access
time update that would thus hang the invocation of qemu-ga, but the
logic to workaround that can be handled via the watchdog, so we don't
address that here (for relatime we'd periodically touch the qemu-ga
binary if the file $qga_statedir/qga.state.isfrozen is not present, this
avoids qemu-ga updates or the 1 day relatime threshold causing an
access-time update if we try to respawn qemu-ga shortly after it goes
away)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2012-04-19 01:28:01 +04:00
|
|
|
QGA_STATEDIR_DEFAULT);
|
2011-07-21 00:19:37 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
static const char *ga_log_level_str(GLogLevelFlags level)
|
|
|
|
{
|
|
|
|
switch (level & G_LOG_LEVEL_MASK) {
|
|
|
|
case G_LOG_LEVEL_ERROR:
|
|
|
|
return "error";
|
|
|
|
case G_LOG_LEVEL_CRITICAL:
|
|
|
|
return "critical";
|
|
|
|
case G_LOG_LEVEL_WARNING:
|
|
|
|
return "warning";
|
|
|
|
case G_LOG_LEVEL_MESSAGE:
|
|
|
|
return "message";
|
|
|
|
case G_LOG_LEVEL_INFO:
|
|
|
|
return "info";
|
|
|
|
case G_LOG_LEVEL_DEBUG:
|
|
|
|
return "debug";
|
|
|
|
default:
|
|
|
|
return "user";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
bool ga_logging_enabled(GAState *s)
|
|
|
|
{
|
|
|
|
return s->logging_enabled;
|
|
|
|
}
|
|
|
|
|
|
|
|
void ga_disable_logging(GAState *s)
|
|
|
|
{
|
|
|
|
s->logging_enabled = false;
|
|
|
|
}
|
|
|
|
|
|
|
|
void ga_enable_logging(GAState *s)
|
|
|
|
{
|
|
|
|
s->logging_enabled = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ga_log(const gchar *domain, GLogLevelFlags level,
|
|
|
|
const gchar *msg, gpointer opaque)
|
|
|
|
{
|
|
|
|
GAState *s = opaque;
|
|
|
|
GTimeVal time;
|
|
|
|
const char *level_str = ga_log_level_str(level);
|
|
|
|
|
|
|
|
if (!ga_logging_enabled(s)) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
level &= G_LOG_LEVEL_MASK;
|
2012-01-20 08:04:34 +04:00
|
|
|
#ifndef _WIN32
|
2011-08-12 00:38:11 +04:00
|
|
|
if (domain && strcmp(domain, "syslog") == 0) {
|
2011-07-21 00:19:37 +04:00
|
|
|
syslog(LOG_INFO, "%s: %s", level_str, msg);
|
|
|
|
} else if (level & s->log_level) {
|
2012-01-20 08:04:34 +04:00
|
|
|
#else
|
|
|
|
if (level & s->log_level) {
|
|
|
|
#endif
|
2011-07-21 00:19:37 +04:00
|
|
|
g_get_current_time(&time);
|
|
|
|
fprintf(s->log_file,
|
|
|
|
"%lu.%lu: %s: %s\n", time.tv_sec, time.tv_usec, level_str, msg);
|
|
|
|
fflush(s->log_file);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-02-07 23:56:48 +04:00
|
|
|
void ga_set_response_delimited(GAState *s)
|
|
|
|
{
|
|
|
|
s->delimit_response = true;
|
|
|
|
}
|
|
|
|
|
2013-01-09 01:26:26 +04:00
|
|
|
static FILE *ga_open_logfile(const char *logfile)
|
|
|
|
{
|
|
|
|
FILE *f;
|
|
|
|
|
|
|
|
f = fopen(logfile, "a");
|
|
|
|
if (!f) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
qemu_set_cloexec(fileno(f));
|
|
|
|
return f;
|
|
|
|
}
|
|
|
|
|
qemu-ga: persist tracking of fsfreeze state via filesystem
Currently, qemu-ga may die/get killed/go away for whatever reason after
guest-fsfreeze-freeze has been issued, and before guest-fsfreeze-thaw
has been issued. This means the only way to unfreeze the guest is via
VNC/network/console access, but obtaining that access after-the-fact can
often be very difficult when filesystems are frozen. Logins will almost
always hang, for instance. In many cases the only recourse would be to
reboot the guest without any quiescing of volatile state, which makes
this a corner-case worth giving some attention to.
A likely failsafe for this situation would be to use a watchdog to
restart qemu-ga if it goes away. There are some precautions qemu-ga
needs to take in order to avoid immediately hanging itself on I/O,
however, namely, we must disable logging and defer to processing/creation
of user-specific logfiles, along with creation of the pid file if we're
running as a daemon. We also need to disable non-fsfreeze-safe commands,
as we normally would when processing the guest-fsfreeze-freeze command.
To track when we need to do this in a way that persists between multiple
invocations of qemu-ga, we create a file on the guest filesystem before
issuing the fsfreeze, and delete it when doing the thaw. On qemu-ga
startup, we check for the existance of this file to determine
the need to take the above precautions.
We're forced to do it this way since a more traditional approach such as
reading/writing state to a dedicated state file will cause
access/modification time updates, respectively, both of which will hang
if the file resides on a frozen filesystem. Both can occur even if
relatime is enabled. Checking for file existence will not update the
access time, however, so it's a safe way to check for fsfreeze state.
An actual watchdog-based restart of qemu-ga can itself cause an access
time update that would thus hang the invocation of qemu-ga, but the
logic to workaround that can be handled via the watchdog, so we don't
address that here (for relatime we'd periodically touch the qemu-ga
binary if the file $qga_statedir/qga.state.isfrozen is not present, this
avoids qemu-ga updates or the 1 day relatime threshold causing an
access-time update if we try to respawn qemu-ga shortly after it goes
away)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2012-04-19 01:28:01 +04:00
|
|
|
#ifndef _WIN32
|
|
|
|
static bool ga_open_pidfile(const char *pidfile)
|
|
|
|
{
|
|
|
|
int pidfd;
|
|
|
|
char pidstr[32];
|
|
|
|
|
2013-01-09 01:26:25 +04:00
|
|
|
pidfd = qemu_open(pidfile, O_CREAT|O_WRONLY, S_IRUSR|S_IWUSR);
|
qemu-ga: persist tracking of fsfreeze state via filesystem
Currently, qemu-ga may die/get killed/go away for whatever reason after
guest-fsfreeze-freeze has been issued, and before guest-fsfreeze-thaw
has been issued. This means the only way to unfreeze the guest is via
VNC/network/console access, but obtaining that access after-the-fact can
often be very difficult when filesystems are frozen. Logins will almost
always hang, for instance. In many cases the only recourse would be to
reboot the guest without any quiescing of volatile state, which makes
this a corner-case worth giving some attention to.
A likely failsafe for this situation would be to use a watchdog to
restart qemu-ga if it goes away. There are some precautions qemu-ga
needs to take in order to avoid immediately hanging itself on I/O,
however, namely, we must disable logging and defer to processing/creation
of user-specific logfiles, along with creation of the pid file if we're
running as a daemon. We also need to disable non-fsfreeze-safe commands,
as we normally would when processing the guest-fsfreeze-freeze command.
To track when we need to do this in a way that persists between multiple
invocations of qemu-ga, we create a file on the guest filesystem before
issuing the fsfreeze, and delete it when doing the thaw. On qemu-ga
startup, we check for the existance of this file to determine
the need to take the above precautions.
We're forced to do it this way since a more traditional approach such as
reading/writing state to a dedicated state file will cause
access/modification time updates, respectively, both of which will hang
if the file resides on a frozen filesystem. Both can occur even if
relatime is enabled. Checking for file existence will not update the
access time, however, so it's a safe way to check for fsfreeze state.
An actual watchdog-based restart of qemu-ga can itself cause an access
time update that would thus hang the invocation of qemu-ga, but the
logic to workaround that can be handled via the watchdog, so we don't
address that here (for relatime we'd periodically touch the qemu-ga
binary if the file $qga_statedir/qga.state.isfrozen is not present, this
avoids qemu-ga updates or the 1 day relatime threshold causing an
access-time update if we try to respawn qemu-ga shortly after it goes
away)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2012-04-19 01:28:01 +04:00
|
|
|
if (pidfd == -1 || lockf(pidfd, F_TLOCK, 0)) {
|
|
|
|
g_critical("Cannot lock pid file, %s", strerror(errno));
|
2012-08-22 15:55:52 +04:00
|
|
|
if (pidfd != -1) {
|
|
|
|
close(pidfd);
|
|
|
|
}
|
qemu-ga: persist tracking of fsfreeze state via filesystem
Currently, qemu-ga may die/get killed/go away for whatever reason after
guest-fsfreeze-freeze has been issued, and before guest-fsfreeze-thaw
has been issued. This means the only way to unfreeze the guest is via
VNC/network/console access, but obtaining that access after-the-fact can
often be very difficult when filesystems are frozen. Logins will almost
always hang, for instance. In many cases the only recourse would be to
reboot the guest without any quiescing of volatile state, which makes
this a corner-case worth giving some attention to.
A likely failsafe for this situation would be to use a watchdog to
restart qemu-ga if it goes away. There are some precautions qemu-ga
needs to take in order to avoid immediately hanging itself on I/O,
however, namely, we must disable logging and defer to processing/creation
of user-specific logfiles, along with creation of the pid file if we're
running as a daemon. We also need to disable non-fsfreeze-safe commands,
as we normally would when processing the guest-fsfreeze-freeze command.
To track when we need to do this in a way that persists between multiple
invocations of qemu-ga, we create a file on the guest filesystem before
issuing the fsfreeze, and delete it when doing the thaw. On qemu-ga
startup, we check for the existance of this file to determine
the need to take the above precautions.
We're forced to do it this way since a more traditional approach such as
reading/writing state to a dedicated state file will cause
access/modification time updates, respectively, both of which will hang
if the file resides on a frozen filesystem. Both can occur even if
relatime is enabled. Checking for file existence will not update the
access time, however, so it's a safe way to check for fsfreeze state.
An actual watchdog-based restart of qemu-ga can itself cause an access
time update that would thus hang the invocation of qemu-ga, but the
logic to workaround that can be handled via the watchdog, so we don't
address that here (for relatime we'd periodically touch the qemu-ga
binary if the file $qga_statedir/qga.state.isfrozen is not present, this
avoids qemu-ga updates or the 1 day relatime threshold causing an
access-time update if we try to respawn qemu-ga shortly after it goes
away)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2012-04-19 01:28:01 +04:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2013-01-11 14:24:58 +04:00
|
|
|
if (ftruncate(pidfd, 0)) {
|
qemu-ga: persist tracking of fsfreeze state via filesystem
Currently, qemu-ga may die/get killed/go away for whatever reason after
guest-fsfreeze-freeze has been issued, and before guest-fsfreeze-thaw
has been issued. This means the only way to unfreeze the guest is via
VNC/network/console access, but obtaining that access after-the-fact can
often be very difficult when filesystems are frozen. Logins will almost
always hang, for instance. In many cases the only recourse would be to
reboot the guest without any quiescing of volatile state, which makes
this a corner-case worth giving some attention to.
A likely failsafe for this situation would be to use a watchdog to
restart qemu-ga if it goes away. There are some precautions qemu-ga
needs to take in order to avoid immediately hanging itself on I/O,
however, namely, we must disable logging and defer to processing/creation
of user-specific logfiles, along with creation of the pid file if we're
running as a daemon. We also need to disable non-fsfreeze-safe commands,
as we normally would when processing the guest-fsfreeze-freeze command.
To track when we need to do this in a way that persists between multiple
invocations of qemu-ga, we create a file on the guest filesystem before
issuing the fsfreeze, and delete it when doing the thaw. On qemu-ga
startup, we check for the existance of this file to determine
the need to take the above precautions.
We're forced to do it this way since a more traditional approach such as
reading/writing state to a dedicated state file will cause
access/modification time updates, respectively, both of which will hang
if the file resides on a frozen filesystem. Both can occur even if
relatime is enabled. Checking for file existence will not update the
access time, however, so it's a safe way to check for fsfreeze state.
An actual watchdog-based restart of qemu-ga can itself cause an access
time update that would thus hang the invocation of qemu-ga, but the
logic to workaround that can be handled via the watchdog, so we don't
address that here (for relatime we'd periodically touch the qemu-ga
binary if the file $qga_statedir/qga.state.isfrozen is not present, this
avoids qemu-ga updates or the 1 day relatime threshold causing an
access-time update if we try to respawn qemu-ga shortly after it goes
away)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2012-04-19 01:28:01 +04:00
|
|
|
g_critical("Failed to truncate pid file");
|
|
|
|
goto fail;
|
|
|
|
}
|
2012-10-04 01:40:01 +04:00
|
|
|
snprintf(pidstr, sizeof(pidstr), "%d\n", getpid());
|
qemu-ga: persist tracking of fsfreeze state via filesystem
Currently, qemu-ga may die/get killed/go away for whatever reason after
guest-fsfreeze-freeze has been issued, and before guest-fsfreeze-thaw
has been issued. This means the only way to unfreeze the guest is via
VNC/network/console access, but obtaining that access after-the-fact can
often be very difficult when filesystems are frozen. Logins will almost
always hang, for instance. In many cases the only recourse would be to
reboot the guest without any quiescing of volatile state, which makes
this a corner-case worth giving some attention to.
A likely failsafe for this situation would be to use a watchdog to
restart qemu-ga if it goes away. There are some precautions qemu-ga
needs to take in order to avoid immediately hanging itself on I/O,
however, namely, we must disable logging and defer to processing/creation
of user-specific logfiles, along with creation of the pid file if we're
running as a daemon. We also need to disable non-fsfreeze-safe commands,
as we normally would when processing the guest-fsfreeze-freeze command.
To track when we need to do this in a way that persists between multiple
invocations of qemu-ga, we create a file on the guest filesystem before
issuing the fsfreeze, and delete it when doing the thaw. On qemu-ga
startup, we check for the existance of this file to determine
the need to take the above precautions.
We're forced to do it this way since a more traditional approach such as
reading/writing state to a dedicated state file will cause
access/modification time updates, respectively, both of which will hang
if the file resides on a frozen filesystem. Both can occur even if
relatime is enabled. Checking for file existence will not update the
access time, however, so it's a safe way to check for fsfreeze state.
An actual watchdog-based restart of qemu-ga can itself cause an access
time update that would thus hang the invocation of qemu-ga, but the
logic to workaround that can be handled via the watchdog, so we don't
address that here (for relatime we'd periodically touch the qemu-ga
binary if the file $qga_statedir/qga.state.isfrozen is not present, this
avoids qemu-ga updates or the 1 day relatime threshold causing an
access-time update if we try to respawn qemu-ga shortly after it goes
away)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2012-04-19 01:28:01 +04:00
|
|
|
if (write(pidfd, pidstr, strlen(pidstr)) != strlen(pidstr)) {
|
|
|
|
g_critical("Failed to write pid file");
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
2013-01-11 14:24:59 +04:00
|
|
|
/* keep pidfile open & locked forever */
|
qemu-ga: persist tracking of fsfreeze state via filesystem
Currently, qemu-ga may die/get killed/go away for whatever reason after
guest-fsfreeze-freeze has been issued, and before guest-fsfreeze-thaw
has been issued. This means the only way to unfreeze the guest is via
VNC/network/console access, but obtaining that access after-the-fact can
often be very difficult when filesystems are frozen. Logins will almost
always hang, for instance. In many cases the only recourse would be to
reboot the guest without any quiescing of volatile state, which makes
this a corner-case worth giving some attention to.
A likely failsafe for this situation would be to use a watchdog to
restart qemu-ga if it goes away. There are some precautions qemu-ga
needs to take in order to avoid immediately hanging itself on I/O,
however, namely, we must disable logging and defer to processing/creation
of user-specific logfiles, along with creation of the pid file if we're
running as a daemon. We also need to disable non-fsfreeze-safe commands,
as we normally would when processing the guest-fsfreeze-freeze command.
To track when we need to do this in a way that persists between multiple
invocations of qemu-ga, we create a file on the guest filesystem before
issuing the fsfreeze, and delete it when doing the thaw. On qemu-ga
startup, we check for the existance of this file to determine
the need to take the above precautions.
We're forced to do it this way since a more traditional approach such as
reading/writing state to a dedicated state file will cause
access/modification time updates, respectively, both of which will hang
if the file resides on a frozen filesystem. Both can occur even if
relatime is enabled. Checking for file existence will not update the
access time, however, so it's a safe way to check for fsfreeze state.
An actual watchdog-based restart of qemu-ga can itself cause an access
time update that would thus hang the invocation of qemu-ga, but the
logic to workaround that can be handled via the watchdog, so we don't
address that here (for relatime we'd periodically touch the qemu-ga
binary if the file $qga_statedir/qga.state.isfrozen is not present, this
avoids qemu-ga updates or the 1 day relatime threshold causing an
access-time update if we try to respawn qemu-ga shortly after it goes
away)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2012-04-19 01:28:01 +04:00
|
|
|
return true;
|
|
|
|
|
|
|
|
fail:
|
|
|
|
unlink(pidfile);
|
2013-01-11 14:24:59 +04:00
|
|
|
close(pidfd);
|
qemu-ga: persist tracking of fsfreeze state via filesystem
Currently, qemu-ga may die/get killed/go away for whatever reason after
guest-fsfreeze-freeze has been issued, and before guest-fsfreeze-thaw
has been issued. This means the only way to unfreeze the guest is via
VNC/network/console access, but obtaining that access after-the-fact can
often be very difficult when filesystems are frozen. Logins will almost
always hang, for instance. In many cases the only recourse would be to
reboot the guest without any quiescing of volatile state, which makes
this a corner-case worth giving some attention to.
A likely failsafe for this situation would be to use a watchdog to
restart qemu-ga if it goes away. There are some precautions qemu-ga
needs to take in order to avoid immediately hanging itself on I/O,
however, namely, we must disable logging and defer to processing/creation
of user-specific logfiles, along with creation of the pid file if we're
running as a daemon. We also need to disable non-fsfreeze-safe commands,
as we normally would when processing the guest-fsfreeze-freeze command.
To track when we need to do this in a way that persists between multiple
invocations of qemu-ga, we create a file on the guest filesystem before
issuing the fsfreeze, and delete it when doing the thaw. On qemu-ga
startup, we check for the existance of this file to determine
the need to take the above precautions.
We're forced to do it this way since a more traditional approach such as
reading/writing state to a dedicated state file will cause
access/modification time updates, respectively, both of which will hang
if the file resides on a frozen filesystem. Both can occur even if
relatime is enabled. Checking for file existence will not update the
access time, however, so it's a safe way to check for fsfreeze state.
An actual watchdog-based restart of qemu-ga can itself cause an access
time update that would thus hang the invocation of qemu-ga, but the
logic to workaround that can be handled via the watchdog, so we don't
address that here (for relatime we'd periodically touch the qemu-ga
binary if the file $qga_statedir/qga.state.isfrozen is not present, this
avoids qemu-ga updates or the 1 day relatime threshold causing an
access-time update if we try to respawn qemu-ga shortly after it goes
away)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2012-04-19 01:28:01 +04:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
#else /* _WIN32 */
|
|
|
|
static bool ga_open_pidfile(const char *pidfile)
|
|
|
|
{
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2012-04-18 04:01:45 +04:00
|
|
|
static gint ga_strcmp(gconstpointer str1, gconstpointer str2)
|
|
|
|
{
|
|
|
|
return strcmp(str1, str2);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* disable commands that aren't safe for fsfreeze */
|
|
|
|
static void ga_disable_non_whitelisted(void)
|
|
|
|
{
|
|
|
|
char **list_head, **list;
|
|
|
|
bool whitelisted;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
list_head = list = qmp_get_command_list();
|
|
|
|
while (*list != NULL) {
|
|
|
|
whitelisted = false;
|
|
|
|
i = 0;
|
|
|
|
while (ga_freeze_whitelist[i] != NULL) {
|
|
|
|
if (strcmp(*list, ga_freeze_whitelist[i]) == 0) {
|
|
|
|
whitelisted = true;
|
|
|
|
}
|
|
|
|
i++;
|
|
|
|
}
|
|
|
|
if (!whitelisted) {
|
|
|
|
g_debug("disabling command: %s", *list);
|
|
|
|
qmp_disable_command(*list);
|
|
|
|
}
|
|
|
|
g_free(*list);
|
|
|
|
list++;
|
|
|
|
}
|
|
|
|
g_free(list_head);
|
|
|
|
}
|
|
|
|
|
2012-05-09 09:12:04 +04:00
|
|
|
/* [re-]enable all commands, except those explicitly blacklisted by user */
|
2012-04-18 04:01:45 +04:00
|
|
|
static void ga_enable_non_blacklisted(GList *blacklist)
|
|
|
|
{
|
|
|
|
char **list_head, **list;
|
|
|
|
|
|
|
|
list_head = list = qmp_get_command_list();
|
|
|
|
while (*list != NULL) {
|
|
|
|
if (g_list_find_custom(blacklist, *list, ga_strcmp) == NULL &&
|
|
|
|
!qmp_command_is_enabled(*list)) {
|
|
|
|
g_debug("enabling command: %s", *list);
|
|
|
|
qmp_enable_command(*list);
|
|
|
|
}
|
|
|
|
g_free(*list);
|
|
|
|
list++;
|
|
|
|
}
|
|
|
|
g_free(list_head);
|
|
|
|
}
|
|
|
|
|
qemu-ga: persist tracking of fsfreeze state via filesystem
Currently, qemu-ga may die/get killed/go away for whatever reason after
guest-fsfreeze-freeze has been issued, and before guest-fsfreeze-thaw
has been issued. This means the only way to unfreeze the guest is via
VNC/network/console access, but obtaining that access after-the-fact can
often be very difficult when filesystems are frozen. Logins will almost
always hang, for instance. In many cases the only recourse would be to
reboot the guest without any quiescing of volatile state, which makes
this a corner-case worth giving some attention to.
A likely failsafe for this situation would be to use a watchdog to
restart qemu-ga if it goes away. There are some precautions qemu-ga
needs to take in order to avoid immediately hanging itself on I/O,
however, namely, we must disable logging and defer to processing/creation
of user-specific logfiles, along with creation of the pid file if we're
running as a daemon. We also need to disable non-fsfreeze-safe commands,
as we normally would when processing the guest-fsfreeze-freeze command.
To track when we need to do this in a way that persists between multiple
invocations of qemu-ga, we create a file on the guest filesystem before
issuing the fsfreeze, and delete it when doing the thaw. On qemu-ga
startup, we check for the existance of this file to determine
the need to take the above precautions.
We're forced to do it this way since a more traditional approach such as
reading/writing state to a dedicated state file will cause
access/modification time updates, respectively, both of which will hang
if the file resides on a frozen filesystem. Both can occur even if
relatime is enabled. Checking for file existence will not update the
access time, however, so it's a safe way to check for fsfreeze state.
An actual watchdog-based restart of qemu-ga can itself cause an access
time update that would thus hang the invocation of qemu-ga, but the
logic to workaround that can be handled via the watchdog, so we don't
address that here (for relatime we'd periodically touch the qemu-ga
binary if the file $qga_statedir/qga.state.isfrozen is not present, this
avoids qemu-ga updates or the 1 day relatime threshold causing an
access-time update if we try to respawn qemu-ga shortly after it goes
away)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2012-04-19 01:28:01 +04:00
|
|
|
static bool ga_create_file(const char *path)
|
|
|
|
{
|
|
|
|
int fd = open(path, O_CREAT | O_WRONLY, S_IWUSR | S_IRUSR);
|
|
|
|
if (fd == -1) {
|
|
|
|
g_warning("unable to open/create file %s: %s", path, strerror(errno));
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
close(fd);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool ga_delete_file(const char *path)
|
|
|
|
{
|
|
|
|
int ret = unlink(path);
|
|
|
|
if (ret == -1) {
|
|
|
|
g_warning("unable to delete file: %s: %s", path, strerror(errno));
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2012-04-18 04:01:45 +04:00
|
|
|
bool ga_is_frozen(GAState *s)
|
|
|
|
{
|
|
|
|
return s->frozen;
|
|
|
|
}
|
|
|
|
|
|
|
|
void ga_set_frozen(GAState *s)
|
|
|
|
{
|
|
|
|
if (ga_is_frozen(s)) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
/* disable all non-whitelisted (for frozen state) commands */
|
|
|
|
ga_disable_non_whitelisted();
|
|
|
|
g_warning("disabling logging due to filesystem freeze");
|
|
|
|
ga_disable_logging(s);
|
|
|
|
s->frozen = true;
|
qemu-ga: persist tracking of fsfreeze state via filesystem
Currently, qemu-ga may die/get killed/go away for whatever reason after
guest-fsfreeze-freeze has been issued, and before guest-fsfreeze-thaw
has been issued. This means the only way to unfreeze the guest is via
VNC/network/console access, but obtaining that access after-the-fact can
often be very difficult when filesystems are frozen. Logins will almost
always hang, for instance. In many cases the only recourse would be to
reboot the guest without any quiescing of volatile state, which makes
this a corner-case worth giving some attention to.
A likely failsafe for this situation would be to use a watchdog to
restart qemu-ga if it goes away. There are some precautions qemu-ga
needs to take in order to avoid immediately hanging itself on I/O,
however, namely, we must disable logging and defer to processing/creation
of user-specific logfiles, along with creation of the pid file if we're
running as a daemon. We also need to disable non-fsfreeze-safe commands,
as we normally would when processing the guest-fsfreeze-freeze command.
To track when we need to do this in a way that persists between multiple
invocations of qemu-ga, we create a file on the guest filesystem before
issuing the fsfreeze, and delete it when doing the thaw. On qemu-ga
startup, we check for the existance of this file to determine
the need to take the above precautions.
We're forced to do it this way since a more traditional approach such as
reading/writing state to a dedicated state file will cause
access/modification time updates, respectively, both of which will hang
if the file resides on a frozen filesystem. Both can occur even if
relatime is enabled. Checking for file existence will not update the
access time, however, so it's a safe way to check for fsfreeze state.
An actual watchdog-based restart of qemu-ga can itself cause an access
time update that would thus hang the invocation of qemu-ga, but the
logic to workaround that can be handled via the watchdog, so we don't
address that here (for relatime we'd periodically touch the qemu-ga
binary if the file $qga_statedir/qga.state.isfrozen is not present, this
avoids qemu-ga updates or the 1 day relatime threshold causing an
access-time update if we try to respawn qemu-ga shortly after it goes
away)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2012-04-19 01:28:01 +04:00
|
|
|
if (!ga_create_file(s->state_filepath_isfrozen)) {
|
|
|
|
g_warning("unable to create %s, fsfreeze may not function properly",
|
|
|
|
s->state_filepath_isfrozen);
|
|
|
|
}
|
2012-04-18 04:01:45 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
void ga_unset_frozen(GAState *s)
|
|
|
|
{
|
|
|
|
if (!ga_is_frozen(s)) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
qemu-ga: persist tracking of fsfreeze state via filesystem
Currently, qemu-ga may die/get killed/go away for whatever reason after
guest-fsfreeze-freeze has been issued, and before guest-fsfreeze-thaw
has been issued. This means the only way to unfreeze the guest is via
VNC/network/console access, but obtaining that access after-the-fact can
often be very difficult when filesystems are frozen. Logins will almost
always hang, for instance. In many cases the only recourse would be to
reboot the guest without any quiescing of volatile state, which makes
this a corner-case worth giving some attention to.
A likely failsafe for this situation would be to use a watchdog to
restart qemu-ga if it goes away. There are some precautions qemu-ga
needs to take in order to avoid immediately hanging itself on I/O,
however, namely, we must disable logging and defer to processing/creation
of user-specific logfiles, along with creation of the pid file if we're
running as a daemon. We also need to disable non-fsfreeze-safe commands,
as we normally would when processing the guest-fsfreeze-freeze command.
To track when we need to do this in a way that persists between multiple
invocations of qemu-ga, we create a file on the guest filesystem before
issuing the fsfreeze, and delete it when doing the thaw. On qemu-ga
startup, we check for the existance of this file to determine
the need to take the above precautions.
We're forced to do it this way since a more traditional approach such as
reading/writing state to a dedicated state file will cause
access/modification time updates, respectively, both of which will hang
if the file resides on a frozen filesystem. Both can occur even if
relatime is enabled. Checking for file existence will not update the
access time, however, so it's a safe way to check for fsfreeze state.
An actual watchdog-based restart of qemu-ga can itself cause an access
time update that would thus hang the invocation of qemu-ga, but the
logic to workaround that can be handled via the watchdog, so we don't
address that here (for relatime we'd periodically touch the qemu-ga
binary if the file $qga_statedir/qga.state.isfrozen is not present, this
avoids qemu-ga updates or the 1 day relatime threshold causing an
access-time update if we try to respawn qemu-ga shortly after it goes
away)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2012-04-19 01:28:01 +04:00
|
|
|
/* if we delayed creation/opening of pid/log files due to being
|
|
|
|
* in a frozen state at start up, do it now
|
|
|
|
*/
|
|
|
|
if (s->deferred_options.log_filepath) {
|
2013-01-09 01:26:26 +04:00
|
|
|
s->log_file = ga_open_logfile(s->deferred_options.log_filepath);
|
qemu-ga: persist tracking of fsfreeze state via filesystem
Currently, qemu-ga may die/get killed/go away for whatever reason after
guest-fsfreeze-freeze has been issued, and before guest-fsfreeze-thaw
has been issued. This means the only way to unfreeze the guest is via
VNC/network/console access, but obtaining that access after-the-fact can
often be very difficult when filesystems are frozen. Logins will almost
always hang, for instance. In many cases the only recourse would be to
reboot the guest without any quiescing of volatile state, which makes
this a corner-case worth giving some attention to.
A likely failsafe for this situation would be to use a watchdog to
restart qemu-ga if it goes away. There are some precautions qemu-ga
needs to take in order to avoid immediately hanging itself on I/O,
however, namely, we must disable logging and defer to processing/creation
of user-specific logfiles, along with creation of the pid file if we're
running as a daemon. We also need to disable non-fsfreeze-safe commands,
as we normally would when processing the guest-fsfreeze-freeze command.
To track when we need to do this in a way that persists between multiple
invocations of qemu-ga, we create a file on the guest filesystem before
issuing the fsfreeze, and delete it when doing the thaw. On qemu-ga
startup, we check for the existance of this file to determine
the need to take the above precautions.
We're forced to do it this way since a more traditional approach such as
reading/writing state to a dedicated state file will cause
access/modification time updates, respectively, both of which will hang
if the file resides on a frozen filesystem. Both can occur even if
relatime is enabled. Checking for file existence will not update the
access time, however, so it's a safe way to check for fsfreeze state.
An actual watchdog-based restart of qemu-ga can itself cause an access
time update that would thus hang the invocation of qemu-ga, but the
logic to workaround that can be handled via the watchdog, so we don't
address that here (for relatime we'd periodically touch the qemu-ga
binary if the file $qga_statedir/qga.state.isfrozen is not present, this
avoids qemu-ga updates or the 1 day relatime threshold causing an
access-time update if we try to respawn qemu-ga shortly after it goes
away)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2012-04-19 01:28:01 +04:00
|
|
|
if (!s->log_file) {
|
|
|
|
s->log_file = stderr;
|
|
|
|
}
|
|
|
|
s->deferred_options.log_filepath = NULL;
|
|
|
|
}
|
2012-04-18 04:01:45 +04:00
|
|
|
ga_enable_logging(s);
|
qemu-ga: persist tracking of fsfreeze state via filesystem
Currently, qemu-ga may die/get killed/go away for whatever reason after
guest-fsfreeze-freeze has been issued, and before guest-fsfreeze-thaw
has been issued. This means the only way to unfreeze the guest is via
VNC/network/console access, but obtaining that access after-the-fact can
often be very difficult when filesystems are frozen. Logins will almost
always hang, for instance. In many cases the only recourse would be to
reboot the guest without any quiescing of volatile state, which makes
this a corner-case worth giving some attention to.
A likely failsafe for this situation would be to use a watchdog to
restart qemu-ga if it goes away. There are some precautions qemu-ga
needs to take in order to avoid immediately hanging itself on I/O,
however, namely, we must disable logging and defer to processing/creation
of user-specific logfiles, along with creation of the pid file if we're
running as a daemon. We also need to disable non-fsfreeze-safe commands,
as we normally would when processing the guest-fsfreeze-freeze command.
To track when we need to do this in a way that persists between multiple
invocations of qemu-ga, we create a file on the guest filesystem before
issuing the fsfreeze, and delete it when doing the thaw. On qemu-ga
startup, we check for the existance of this file to determine
the need to take the above precautions.
We're forced to do it this way since a more traditional approach such as
reading/writing state to a dedicated state file will cause
access/modification time updates, respectively, both of which will hang
if the file resides on a frozen filesystem. Both can occur even if
relatime is enabled. Checking for file existence will not update the
access time, however, so it's a safe way to check for fsfreeze state.
An actual watchdog-based restart of qemu-ga can itself cause an access
time update that would thus hang the invocation of qemu-ga, but the
logic to workaround that can be handled via the watchdog, so we don't
address that here (for relatime we'd periodically touch the qemu-ga
binary if the file $qga_statedir/qga.state.isfrozen is not present, this
avoids qemu-ga updates or the 1 day relatime threshold causing an
access-time update if we try to respawn qemu-ga shortly after it goes
away)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2012-04-19 01:28:01 +04:00
|
|
|
g_warning("logging re-enabled due to filesystem unfreeze");
|
|
|
|
if (s->deferred_options.pid_filepath) {
|
|
|
|
if (!ga_open_pidfile(s->deferred_options.pid_filepath)) {
|
|
|
|
g_warning("failed to create/open pid file");
|
|
|
|
}
|
|
|
|
s->deferred_options.pid_filepath = NULL;
|
|
|
|
}
|
2012-04-18 04:01:45 +04:00
|
|
|
|
|
|
|
/* enable all disabled, non-blacklisted commands */
|
|
|
|
ga_enable_non_blacklisted(s->blacklist);
|
|
|
|
s->frozen = false;
|
qemu-ga: persist tracking of fsfreeze state via filesystem
Currently, qemu-ga may die/get killed/go away for whatever reason after
guest-fsfreeze-freeze has been issued, and before guest-fsfreeze-thaw
has been issued. This means the only way to unfreeze the guest is via
VNC/network/console access, but obtaining that access after-the-fact can
often be very difficult when filesystems are frozen. Logins will almost
always hang, for instance. In many cases the only recourse would be to
reboot the guest without any quiescing of volatile state, which makes
this a corner-case worth giving some attention to.
A likely failsafe for this situation would be to use a watchdog to
restart qemu-ga if it goes away. There are some precautions qemu-ga
needs to take in order to avoid immediately hanging itself on I/O,
however, namely, we must disable logging and defer to processing/creation
of user-specific logfiles, along with creation of the pid file if we're
running as a daemon. We also need to disable non-fsfreeze-safe commands,
as we normally would when processing the guest-fsfreeze-freeze command.
To track when we need to do this in a way that persists between multiple
invocations of qemu-ga, we create a file on the guest filesystem before
issuing the fsfreeze, and delete it when doing the thaw. On qemu-ga
startup, we check for the existance of this file to determine
the need to take the above precautions.
We're forced to do it this way since a more traditional approach such as
reading/writing state to a dedicated state file will cause
access/modification time updates, respectively, both of which will hang
if the file resides on a frozen filesystem. Both can occur even if
relatime is enabled. Checking for file existence will not update the
access time, however, so it's a safe way to check for fsfreeze state.
An actual watchdog-based restart of qemu-ga can itself cause an access
time update that would thus hang the invocation of qemu-ga, but the
logic to workaround that can be handled via the watchdog, so we don't
address that here (for relatime we'd periodically touch the qemu-ga
binary if the file $qga_statedir/qga.state.isfrozen is not present, this
avoids qemu-ga updates or the 1 day relatime threshold causing an
access-time update if we try to respawn qemu-ga shortly after it goes
away)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2012-04-19 01:28:01 +04:00
|
|
|
if (!ga_delete_file(s->state_filepath_isfrozen)) {
|
|
|
|
g_warning("unable to delete %s, fsfreeze may not function properly",
|
|
|
|
s->state_filepath_isfrozen);
|
|
|
|
}
|
2012-04-18 04:01:45 +04:00
|
|
|
}
|
|
|
|
|
2012-12-12 07:55:55 +04:00
|
|
|
#ifdef CONFIG_FSFREEZE
|
|
|
|
const char *ga_fsfreeze_hook(GAState *s)
|
|
|
|
{
|
|
|
|
return s->fsfreeze_hook;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2011-07-21 00:19:37 +04:00
|
|
|
static void become_daemon(const char *pidfile)
|
|
|
|
{
|
qemu-ga: persist tracking of fsfreeze state via filesystem
Currently, qemu-ga may die/get killed/go away for whatever reason after
guest-fsfreeze-freeze has been issued, and before guest-fsfreeze-thaw
has been issued. This means the only way to unfreeze the guest is via
VNC/network/console access, but obtaining that access after-the-fact can
often be very difficult when filesystems are frozen. Logins will almost
always hang, for instance. In many cases the only recourse would be to
reboot the guest without any quiescing of volatile state, which makes
this a corner-case worth giving some attention to.
A likely failsafe for this situation would be to use a watchdog to
restart qemu-ga if it goes away. There are some precautions qemu-ga
needs to take in order to avoid immediately hanging itself on I/O,
however, namely, we must disable logging and defer to processing/creation
of user-specific logfiles, along with creation of the pid file if we're
running as a daemon. We also need to disable non-fsfreeze-safe commands,
as we normally would when processing the guest-fsfreeze-freeze command.
To track when we need to do this in a way that persists between multiple
invocations of qemu-ga, we create a file on the guest filesystem before
issuing the fsfreeze, and delete it when doing the thaw. On qemu-ga
startup, we check for the existance of this file to determine
the need to take the above precautions.
We're forced to do it this way since a more traditional approach such as
reading/writing state to a dedicated state file will cause
access/modification time updates, respectively, both of which will hang
if the file resides on a frozen filesystem. Both can occur even if
relatime is enabled. Checking for file existence will not update the
access time, however, so it's a safe way to check for fsfreeze state.
An actual watchdog-based restart of qemu-ga can itself cause an access
time update that would thus hang the invocation of qemu-ga, but the
logic to workaround that can be handled via the watchdog, so we don't
address that here (for relatime we'd periodically touch the qemu-ga
binary if the file $qga_statedir/qga.state.isfrozen is not present, this
avoids qemu-ga updates or the 1 day relatime threshold causing an
access-time update if we try to respawn qemu-ga shortly after it goes
away)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2012-04-19 01:28:01 +04:00
|
|
|
#ifndef _WIN32
|
2011-07-21 00:19:37 +04:00
|
|
|
pid_t pid, sid;
|
|
|
|
|
|
|
|
pid = fork();
|
|
|
|
if (pid < 0) {
|
|
|
|
exit(EXIT_FAILURE);
|
|
|
|
}
|
|
|
|
if (pid > 0) {
|
|
|
|
exit(EXIT_SUCCESS);
|
|
|
|
}
|
|
|
|
|
qemu-ga: persist tracking of fsfreeze state via filesystem
Currently, qemu-ga may die/get killed/go away for whatever reason after
guest-fsfreeze-freeze has been issued, and before guest-fsfreeze-thaw
has been issued. This means the only way to unfreeze the guest is via
VNC/network/console access, but obtaining that access after-the-fact can
often be very difficult when filesystems are frozen. Logins will almost
always hang, for instance. In many cases the only recourse would be to
reboot the guest without any quiescing of volatile state, which makes
this a corner-case worth giving some attention to.
A likely failsafe for this situation would be to use a watchdog to
restart qemu-ga if it goes away. There are some precautions qemu-ga
needs to take in order to avoid immediately hanging itself on I/O,
however, namely, we must disable logging and defer to processing/creation
of user-specific logfiles, along with creation of the pid file if we're
running as a daemon. We also need to disable non-fsfreeze-safe commands,
as we normally would when processing the guest-fsfreeze-freeze command.
To track when we need to do this in a way that persists between multiple
invocations of qemu-ga, we create a file on the guest filesystem before
issuing the fsfreeze, and delete it when doing the thaw. On qemu-ga
startup, we check for the existance of this file to determine
the need to take the above precautions.
We're forced to do it this way since a more traditional approach such as
reading/writing state to a dedicated state file will cause
access/modification time updates, respectively, both of which will hang
if the file resides on a frozen filesystem. Both can occur even if
relatime is enabled. Checking for file existence will not update the
access time, however, so it's a safe way to check for fsfreeze state.
An actual watchdog-based restart of qemu-ga can itself cause an access
time update that would thus hang the invocation of qemu-ga, but the
logic to workaround that can be handled via the watchdog, so we don't
address that here (for relatime we'd periodically touch the qemu-ga
binary if the file $qga_statedir/qga.state.isfrozen is not present, this
avoids qemu-ga updates or the 1 day relatime threshold causing an
access-time update if we try to respawn qemu-ga shortly after it goes
away)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2012-04-19 01:28:01 +04:00
|
|
|
if (pidfile) {
|
|
|
|
if (!ga_open_pidfile(pidfile)) {
|
|
|
|
g_critical("failed to create pidfile");
|
|
|
|
exit(EXIT_FAILURE);
|
|
|
|
}
|
2011-07-21 00:19:37 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
umask(0);
|
|
|
|
sid = setsid();
|
|
|
|
if (sid < 0) {
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
if ((chdir("/")) < 0) {
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
2012-05-10 23:50:42 +04:00
|
|
|
reopen_fd_to_null(STDIN_FILENO);
|
|
|
|
reopen_fd_to_null(STDOUT_FILENO);
|
|
|
|
reopen_fd_to_null(STDERR_FILENO);
|
2011-07-21 00:19:37 +04:00
|
|
|
return;
|
|
|
|
|
|
|
|
fail:
|
2012-08-24 09:03:03 +04:00
|
|
|
if (pidfile) {
|
|
|
|
unlink(pidfile);
|
|
|
|
}
|
2011-07-21 00:19:37 +04:00
|
|
|
g_critical("failed to daemonize");
|
|
|
|
exit(EXIT_FAILURE);
|
2012-01-20 08:04:34 +04:00
|
|
|
#endif
|
qemu-ga: persist tracking of fsfreeze state via filesystem
Currently, qemu-ga may die/get killed/go away for whatever reason after
guest-fsfreeze-freeze has been issued, and before guest-fsfreeze-thaw
has been issued. This means the only way to unfreeze the guest is via
VNC/network/console access, but obtaining that access after-the-fact can
often be very difficult when filesystems are frozen. Logins will almost
always hang, for instance. In many cases the only recourse would be to
reboot the guest without any quiescing of volatile state, which makes
this a corner-case worth giving some attention to.
A likely failsafe for this situation would be to use a watchdog to
restart qemu-ga if it goes away. There are some precautions qemu-ga
needs to take in order to avoid immediately hanging itself on I/O,
however, namely, we must disable logging and defer to processing/creation
of user-specific logfiles, along with creation of the pid file if we're
running as a daemon. We also need to disable non-fsfreeze-safe commands,
as we normally would when processing the guest-fsfreeze-freeze command.
To track when we need to do this in a way that persists between multiple
invocations of qemu-ga, we create a file on the guest filesystem before
issuing the fsfreeze, and delete it when doing the thaw. On qemu-ga
startup, we check for the existance of this file to determine
the need to take the above precautions.
We're forced to do it this way since a more traditional approach such as
reading/writing state to a dedicated state file will cause
access/modification time updates, respectively, both of which will hang
if the file resides on a frozen filesystem. Both can occur even if
relatime is enabled. Checking for file existence will not update the
access time, however, so it's a safe way to check for fsfreeze state.
An actual watchdog-based restart of qemu-ga can itself cause an access
time update that would thus hang the invocation of qemu-ga, but the
logic to workaround that can be handled via the watchdog, so we don't
address that here (for relatime we'd periodically touch the qemu-ga
binary if the file $qga_statedir/qga.state.isfrozen is not present, this
avoids qemu-ga updates or the 1 day relatime threshold causing an
access-time update if we try to respawn qemu-ga shortly after it goes
away)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2012-04-19 01:28:01 +04:00
|
|
|
}
|
2011-07-21 00:19:37 +04:00
|
|
|
|
2012-01-19 10:18:20 +04:00
|
|
|
static int send_response(GAState *s, QObject *payload)
|
2011-07-21 00:19:37 +04:00
|
|
|
{
|
|
|
|
const char *buf;
|
2012-02-07 23:56:48 +04:00
|
|
|
QString *payload_qstr, *response_qstr;
|
2012-01-19 10:18:20 +04:00
|
|
|
GIOStatus status;
|
2011-07-21 00:19:37 +04:00
|
|
|
|
2012-01-19 10:18:20 +04:00
|
|
|
g_assert(payload && s->channel);
|
2011-07-21 00:19:37 +04:00
|
|
|
|
|
|
|
payload_qstr = qobject_to_json(payload);
|
|
|
|
if (!payload_qstr) {
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2012-02-07 23:56:48 +04:00
|
|
|
if (s->delimit_response) {
|
|
|
|
s->delimit_response = false;
|
|
|
|
response_qstr = qstring_new();
|
|
|
|
qstring_append_chr(response_qstr, QGA_SENTINEL_BYTE);
|
|
|
|
qstring_append(response_qstr, qstring_get_str(payload_qstr));
|
|
|
|
QDECREF(payload_qstr);
|
|
|
|
} else {
|
|
|
|
response_qstr = payload_qstr;
|
|
|
|
}
|
|
|
|
|
|
|
|
qstring_append_chr(response_qstr, '\n');
|
|
|
|
buf = qstring_get_str(response_qstr);
|
2012-01-19 10:18:20 +04:00
|
|
|
status = ga_channel_write_all(s->channel, buf, strlen(buf));
|
2012-02-07 23:56:48 +04:00
|
|
|
QDECREF(response_qstr);
|
2012-01-19 10:18:20 +04:00
|
|
|
if (status != G_IO_STATUS_NORMAL) {
|
|
|
|
return -EIO;
|
2011-07-21 00:19:37 +04:00
|
|
|
}
|
2012-01-19 10:18:20 +04:00
|
|
|
|
|
|
|
return 0;
|
2011-07-21 00:19:37 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
static void process_command(GAState *s, QDict *req)
|
|
|
|
{
|
|
|
|
QObject *rsp = NULL;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
g_assert(req);
|
|
|
|
g_debug("processing command");
|
|
|
|
rsp = qmp_dispatch(QOBJECT(req));
|
|
|
|
if (rsp) {
|
2012-01-19 10:18:20 +04:00
|
|
|
ret = send_response(s, rsp);
|
2011-07-21 00:19:37 +04:00
|
|
|
if (ret) {
|
2012-01-19 10:18:20 +04:00
|
|
|
g_warning("error sending response: %s", strerror(ret));
|
2011-07-21 00:19:37 +04:00
|
|
|
}
|
|
|
|
qobject_decref(rsp);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* handle requests/control events coming in over the channel */
|
|
|
|
static void process_event(JSONMessageParser *parser, QList *tokens)
|
|
|
|
{
|
|
|
|
GAState *s = container_of(parser, GAState, parser);
|
|
|
|
QObject *obj;
|
|
|
|
QDict *qdict;
|
|
|
|
Error *err = NULL;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
g_assert(s && parser);
|
|
|
|
|
|
|
|
g_debug("process_event: called");
|
|
|
|
obj = json_parser_parse_err(tokens, NULL, &err);
|
|
|
|
if (err || !obj || qobject_type(obj) != QTYPE_QDICT) {
|
|
|
|
qobject_decref(obj);
|
|
|
|
qdict = qdict_new();
|
|
|
|
if (!err) {
|
|
|
|
g_warning("failed to parse event: unknown error");
|
|
|
|
error_set(&err, QERR_JSON_PARSING);
|
|
|
|
} else {
|
|
|
|
g_warning("failed to parse event: %s", error_get_pretty(err));
|
|
|
|
}
|
2012-08-01 23:30:13 +04:00
|
|
|
qdict_put_obj(qdict, "error", qmp_build_error_object(err));
|
2011-07-21 00:19:37 +04:00
|
|
|
error_free(err);
|
|
|
|
} else {
|
|
|
|
qdict = qobject_to_qdict(obj);
|
|
|
|
}
|
|
|
|
|
|
|
|
g_assert(qdict);
|
|
|
|
|
|
|
|
/* handle host->guest commands */
|
|
|
|
if (qdict_haskey(qdict, "execute")) {
|
|
|
|
process_command(s, qdict);
|
|
|
|
} else {
|
|
|
|
if (!qdict_haskey(qdict, "error")) {
|
|
|
|
QDECREF(qdict);
|
|
|
|
qdict = qdict_new();
|
|
|
|
g_warning("unrecognized payload format");
|
|
|
|
error_set(&err, QERR_UNSUPPORTED);
|
2012-08-01 23:30:13 +04:00
|
|
|
qdict_put_obj(qdict, "error", qmp_build_error_object(err));
|
2011-07-21 00:19:37 +04:00
|
|
|
error_free(err);
|
|
|
|
}
|
2012-01-19 10:18:20 +04:00
|
|
|
ret = send_response(s, QOBJECT(qdict));
|
2011-07-21 00:19:37 +04:00
|
|
|
if (ret) {
|
2012-01-19 10:18:20 +04:00
|
|
|
g_warning("error sending error response: %s", strerror(ret));
|
2011-07-21 00:19:37 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
QDECREF(qdict);
|
|
|
|
}
|
|
|
|
|
2012-01-19 10:18:20 +04:00
|
|
|
/* false return signals GAChannel to close the current client connection */
|
|
|
|
static gboolean channel_event_cb(GIOCondition condition, gpointer data)
|
2011-07-21 00:19:37 +04:00
|
|
|
{
|
|
|
|
GAState *s = data;
|
2012-01-19 10:18:20 +04:00
|
|
|
gchar buf[QGA_READ_COUNT_DEFAULT+1];
|
2011-07-21 00:19:37 +04:00
|
|
|
gsize count;
|
|
|
|
GError *err = NULL;
|
2012-01-19 10:18:20 +04:00
|
|
|
GIOStatus status = ga_channel_read(s->channel, buf, QGA_READ_COUNT_DEFAULT, &count);
|
2011-07-21 00:19:37 +04:00
|
|
|
if (err != NULL) {
|
|
|
|
g_warning("error reading channel: %s", err->message);
|
|
|
|
g_error_free(err);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
switch (status) {
|
|
|
|
case G_IO_STATUS_ERROR:
|
2012-01-19 10:18:20 +04:00
|
|
|
g_warning("error reading channel");
|
2011-07-21 00:19:37 +04:00
|
|
|
return false;
|
|
|
|
case G_IO_STATUS_NORMAL:
|
2012-01-19 10:18:20 +04:00
|
|
|
buf[count] = 0;
|
2011-07-21 00:19:37 +04:00
|
|
|
g_debug("read data, count: %d, data: %s", (int)count, buf);
|
|
|
|
json_message_parser_feed(&s->parser, (char *)buf, (int)count);
|
2012-01-19 10:18:20 +04:00
|
|
|
break;
|
|
|
|
case G_IO_STATUS_EOF:
|
|
|
|
g_debug("received EOF");
|
|
|
|
if (!s->virtio) {
|
|
|
|
return false;
|
|
|
|
}
|
2013-01-11 14:24:57 +04:00
|
|
|
/* fall through */
|
2011-07-21 00:19:37 +04:00
|
|
|
case G_IO_STATUS_AGAIN:
|
|
|
|
/* virtio causes us to spin here when no process is attached to
|
|
|
|
* host-side chardev. sleep a bit to mitigate this
|
|
|
|
*/
|
|
|
|
if (s->virtio) {
|
|
|
|
usleep(100*1000);
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
default:
|
|
|
|
g_warning("unknown channel read status, closing");
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2012-01-19 10:18:20 +04:00
|
|
|
static gboolean channel_init(GAState *s, const gchar *method, const gchar *path)
|
2011-07-21 00:19:37 +04:00
|
|
|
{
|
2012-01-19 10:18:20 +04:00
|
|
|
GAChannelMethod channel_method;
|
2011-07-21 00:19:37 +04:00
|
|
|
|
2012-01-19 10:18:20 +04:00
|
|
|
if (method == NULL) {
|
|
|
|
method = "virtio-serial";
|
2011-07-21 00:19:37 +04:00
|
|
|
}
|
|
|
|
|
2012-01-19 10:18:20 +04:00
|
|
|
if (path == NULL) {
|
|
|
|
if (strcmp(method, "virtio-serial") != 0) {
|
2011-07-21 00:19:37 +04:00
|
|
|
g_critical("must specify a path for this channel");
|
2012-01-19 10:18:20 +04:00
|
|
|
return false;
|
2011-07-21 00:19:37 +04:00
|
|
|
}
|
|
|
|
/* try the default path for the virtio-serial port */
|
2012-01-19 10:18:20 +04:00
|
|
|
path = QGA_VIRTIO_PATH_DEFAULT;
|
2011-07-21 00:19:37 +04:00
|
|
|
}
|
|
|
|
|
2012-01-19 10:18:20 +04:00
|
|
|
if (strcmp(method, "virtio-serial") == 0) {
|
|
|
|
s->virtio = true; /* virtio requires special handling in some cases */
|
|
|
|
channel_method = GA_CHANNEL_VIRTIO_SERIAL;
|
|
|
|
} else if (strcmp(method, "isa-serial") == 0) {
|
|
|
|
channel_method = GA_CHANNEL_ISA_SERIAL;
|
|
|
|
} else if (strcmp(method, "unix-listen") == 0) {
|
|
|
|
channel_method = GA_CHANNEL_UNIX_LISTEN;
|
2011-07-21 00:19:37 +04:00
|
|
|
} else {
|
2012-01-19 10:18:20 +04:00
|
|
|
g_critical("unsupported channel method/type: %s", method);
|
|
|
|
return false;
|
2011-07-21 00:19:37 +04:00
|
|
|
}
|
|
|
|
|
2012-01-19 10:18:20 +04:00
|
|
|
s->channel = ga_channel_new(channel_method, path, channel_event_cb, s);
|
|
|
|
if (!s->channel) {
|
|
|
|
g_critical("failed to create guest agent channel");
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
2011-07-21 00:19:37 +04:00
|
|
|
}
|
|
|
|
|
2012-01-22 02:42:27 +04:00
|
|
|
#ifdef _WIN32
|
|
|
|
DWORD WINAPI service_ctrl_handler(DWORD ctrl, DWORD type, LPVOID data,
|
|
|
|
LPVOID ctx)
|
|
|
|
{
|
|
|
|
DWORD ret = NO_ERROR;
|
|
|
|
GAService *service = &ga_state->service;
|
|
|
|
|
|
|
|
switch (ctrl)
|
|
|
|
{
|
|
|
|
case SERVICE_CONTROL_STOP:
|
|
|
|
case SERVICE_CONTROL_SHUTDOWN:
|
|
|
|
quit_handler(SIGTERM);
|
|
|
|
service->status.dwCurrentState = SERVICE_STOP_PENDING;
|
|
|
|
SetServiceStatus(service->status_handle, &service->status);
|
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
|
|
|
ret = ERROR_CALL_NOT_IMPLEMENTED;
|
|
|
|
}
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
VOID WINAPI service_main(DWORD argc, TCHAR *argv[])
|
|
|
|
{
|
|
|
|
GAService *service = &ga_state->service;
|
|
|
|
|
|
|
|
service->status_handle = RegisterServiceCtrlHandlerEx(QGA_SERVICE_NAME,
|
|
|
|
service_ctrl_handler, NULL);
|
|
|
|
|
|
|
|
if (service->status_handle == 0) {
|
|
|
|
g_critical("Failed to register extended requests function!\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
service->status.dwServiceType = SERVICE_WIN32;
|
|
|
|
service->status.dwCurrentState = SERVICE_RUNNING;
|
|
|
|
service->status.dwControlsAccepted = SERVICE_ACCEPT_STOP | SERVICE_ACCEPT_SHUTDOWN;
|
|
|
|
service->status.dwWin32ExitCode = NO_ERROR;
|
|
|
|
service->status.dwServiceSpecificExitCode = NO_ERROR;
|
|
|
|
service->status.dwCheckPoint = 0;
|
|
|
|
service->status.dwWaitHint = 0;
|
|
|
|
SetServiceStatus(service->status_handle, &service->status);
|
|
|
|
|
|
|
|
g_main_loop_run(ga_state->main_loop);
|
|
|
|
|
|
|
|
service->status.dwCurrentState = SERVICE_STOPPED;
|
|
|
|
SetServiceStatus(service->status_handle, &service->status);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2011-07-21 00:19:37 +04:00
|
|
|
int main(int argc, char **argv)
|
|
|
|
{
|
2012-12-12 07:55:55 +04:00
|
|
|
const char *sopt = "hVvdm:p:l:f:F::b:s:t:";
|
qemu-ga: persist tracking of fsfreeze state via filesystem
Currently, qemu-ga may die/get killed/go away for whatever reason after
guest-fsfreeze-freeze has been issued, and before guest-fsfreeze-thaw
has been issued. This means the only way to unfreeze the guest is via
VNC/network/console access, but obtaining that access after-the-fact can
often be very difficult when filesystems are frozen. Logins will almost
always hang, for instance. In many cases the only recourse would be to
reboot the guest without any quiescing of volatile state, which makes
this a corner-case worth giving some attention to.
A likely failsafe for this situation would be to use a watchdog to
restart qemu-ga if it goes away. There are some precautions qemu-ga
needs to take in order to avoid immediately hanging itself on I/O,
however, namely, we must disable logging and defer to processing/creation
of user-specific logfiles, along with creation of the pid file if we're
running as a daemon. We also need to disable non-fsfreeze-safe commands,
as we normally would when processing the guest-fsfreeze-freeze command.
To track when we need to do this in a way that persists between multiple
invocations of qemu-ga, we create a file on the guest filesystem before
issuing the fsfreeze, and delete it when doing the thaw. On qemu-ga
startup, we check for the existance of this file to determine
the need to take the above precautions.
We're forced to do it this way since a more traditional approach such as
reading/writing state to a dedicated state file will cause
access/modification time updates, respectively, both of which will hang
if the file resides on a frozen filesystem. Both can occur even if
relatime is enabled. Checking for file existence will not update the
access time, however, so it's a safe way to check for fsfreeze state.
An actual watchdog-based restart of qemu-ga can itself cause an access
time update that would thus hang the invocation of qemu-ga, but the
logic to workaround that can be handled via the watchdog, so we don't
address that here (for relatime we'd periodically touch the qemu-ga
binary if the file $qga_statedir/qga.state.isfrozen is not present, this
avoids qemu-ga updates or the 1 day relatime threshold causing an
access-time update if we try to respawn qemu-ga shortly after it goes
away)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2012-04-19 01:28:01 +04:00
|
|
|
const char *method = NULL, *path = NULL;
|
|
|
|
const char *log_filepath = NULL;
|
|
|
|
const char *pid_filepath = QGA_PIDFILE_DEFAULT;
|
2012-12-12 07:55:55 +04:00
|
|
|
#ifdef CONFIG_FSFREEZE
|
|
|
|
const char *fsfreeze_hook = NULL;
|
|
|
|
#endif
|
qemu-ga: persist tracking of fsfreeze state via filesystem
Currently, qemu-ga may die/get killed/go away for whatever reason after
guest-fsfreeze-freeze has been issued, and before guest-fsfreeze-thaw
has been issued. This means the only way to unfreeze the guest is via
VNC/network/console access, but obtaining that access after-the-fact can
often be very difficult when filesystems are frozen. Logins will almost
always hang, for instance. In many cases the only recourse would be to
reboot the guest without any quiescing of volatile state, which makes
this a corner-case worth giving some attention to.
A likely failsafe for this situation would be to use a watchdog to
restart qemu-ga if it goes away. There are some precautions qemu-ga
needs to take in order to avoid immediately hanging itself on I/O,
however, namely, we must disable logging and defer to processing/creation
of user-specific logfiles, along with creation of the pid file if we're
running as a daemon. We also need to disable non-fsfreeze-safe commands,
as we normally would when processing the guest-fsfreeze-freeze command.
To track when we need to do this in a way that persists between multiple
invocations of qemu-ga, we create a file on the guest filesystem before
issuing the fsfreeze, and delete it when doing the thaw. On qemu-ga
startup, we check for the existance of this file to determine
the need to take the above precautions.
We're forced to do it this way since a more traditional approach such as
reading/writing state to a dedicated state file will cause
access/modification time updates, respectively, both of which will hang
if the file resides on a frozen filesystem. Both can occur even if
relatime is enabled. Checking for file existence will not update the
access time, however, so it's a safe way to check for fsfreeze state.
An actual watchdog-based restart of qemu-ga can itself cause an access
time update that would thus hang the invocation of qemu-ga, but the
logic to workaround that can be handled via the watchdog, so we don't
address that here (for relatime we'd periodically touch the qemu-ga
binary if the file $qga_statedir/qga.state.isfrozen is not present, this
avoids qemu-ga updates or the 1 day relatime threshold causing an
access-time update if we try to respawn qemu-ga shortly after it goes
away)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2012-04-19 01:28:01 +04:00
|
|
|
const char *state_dir = QGA_STATEDIR_DEFAULT;
|
2012-01-22 02:42:27 +04:00
|
|
|
#ifdef _WIN32
|
|
|
|
const char *service = NULL;
|
|
|
|
#endif
|
2011-07-21 00:19:37 +04:00
|
|
|
const struct option lopt[] = {
|
|
|
|
{ "help", 0, NULL, 'h' },
|
|
|
|
{ "version", 0, NULL, 'V' },
|
2012-01-22 02:42:27 +04:00
|
|
|
{ "logfile", 1, NULL, 'l' },
|
|
|
|
{ "pidfile", 1, NULL, 'f' },
|
2012-12-12 07:55:55 +04:00
|
|
|
#ifdef CONFIG_FSFREEZE
|
|
|
|
{ "fsfreeze-hook", 2, NULL, 'F' },
|
|
|
|
#endif
|
2011-07-21 00:19:37 +04:00
|
|
|
{ "verbose", 0, NULL, 'v' },
|
2012-01-22 02:42:27 +04:00
|
|
|
{ "method", 1, NULL, 'm' },
|
|
|
|
{ "path", 1, NULL, 'p' },
|
2011-07-21 00:19:37 +04:00
|
|
|
{ "daemonize", 0, NULL, 'd' },
|
2012-01-22 02:42:27 +04:00
|
|
|
{ "blacklist", 1, NULL, 'b' },
|
|
|
|
#ifdef _WIN32
|
|
|
|
{ "service", 1, NULL, 's' },
|
2012-04-18 04:01:45 +04:00
|
|
|
#endif
|
qemu-ga: persist tracking of fsfreeze state via filesystem
Currently, qemu-ga may die/get killed/go away for whatever reason after
guest-fsfreeze-freeze has been issued, and before guest-fsfreeze-thaw
has been issued. This means the only way to unfreeze the guest is via
VNC/network/console access, but obtaining that access after-the-fact can
often be very difficult when filesystems are frozen. Logins will almost
always hang, for instance. In many cases the only recourse would be to
reboot the guest without any quiescing of volatile state, which makes
this a corner-case worth giving some attention to.
A likely failsafe for this situation would be to use a watchdog to
restart qemu-ga if it goes away. There are some precautions qemu-ga
needs to take in order to avoid immediately hanging itself on I/O,
however, namely, we must disable logging and defer to processing/creation
of user-specific logfiles, along with creation of the pid file if we're
running as a daemon. We also need to disable non-fsfreeze-safe commands,
as we normally would when processing the guest-fsfreeze-freeze command.
To track when we need to do this in a way that persists between multiple
invocations of qemu-ga, we create a file on the guest filesystem before
issuing the fsfreeze, and delete it when doing the thaw. On qemu-ga
startup, we check for the existance of this file to determine
the need to take the above precautions.
We're forced to do it this way since a more traditional approach such as
reading/writing state to a dedicated state file will cause
access/modification time updates, respectively, both of which will hang
if the file resides on a frozen filesystem. Both can occur even if
relatime is enabled. Checking for file existence will not update the
access time, however, so it's a safe way to check for fsfreeze state.
An actual watchdog-based restart of qemu-ga can itself cause an access
time update that would thus hang the invocation of qemu-ga, but the
logic to workaround that can be handled via the watchdog, so we don't
address that here (for relatime we'd periodically touch the qemu-ga
binary if the file $qga_statedir/qga.state.isfrozen is not present, this
avoids qemu-ga updates or the 1 day relatime threshold causing an
access-time update if we try to respawn qemu-ga shortly after it goes
away)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2012-04-19 01:28:01 +04:00
|
|
|
{ "statedir", 1, NULL, 't' },
|
2011-07-21 00:19:37 +04:00
|
|
|
{ NULL, 0, NULL, 0 }
|
|
|
|
};
|
2011-12-07 08:03:42 +04:00
|
|
|
int opt_ind = 0, ch, daemonize = 0, i, j, len;
|
2011-07-21 00:19:37 +04:00
|
|
|
GLogLevelFlags log_level = G_LOG_LEVEL_ERROR | G_LOG_LEVEL_CRITICAL;
|
2012-04-18 04:01:45 +04:00
|
|
|
GList *blacklist = NULL;
|
2011-07-21 00:19:37 +04:00
|
|
|
GAState *s;
|
|
|
|
|
2011-12-07 08:03:42 +04:00
|
|
|
module_call_init(MODULE_INIT_QAPI);
|
|
|
|
|
2011-07-21 00:19:37 +04:00
|
|
|
while ((ch = getopt_long(argc, argv, sopt, lopt, &opt_ind)) != -1) {
|
|
|
|
switch (ch) {
|
|
|
|
case 'm':
|
|
|
|
method = optarg;
|
|
|
|
break;
|
|
|
|
case 'p':
|
|
|
|
path = optarg;
|
|
|
|
break;
|
|
|
|
case 'l':
|
qemu-ga: persist tracking of fsfreeze state via filesystem
Currently, qemu-ga may die/get killed/go away for whatever reason after
guest-fsfreeze-freeze has been issued, and before guest-fsfreeze-thaw
has been issued. This means the only way to unfreeze the guest is via
VNC/network/console access, but obtaining that access after-the-fact can
often be very difficult when filesystems are frozen. Logins will almost
always hang, for instance. In many cases the only recourse would be to
reboot the guest without any quiescing of volatile state, which makes
this a corner-case worth giving some attention to.
A likely failsafe for this situation would be to use a watchdog to
restart qemu-ga if it goes away. There are some precautions qemu-ga
needs to take in order to avoid immediately hanging itself on I/O,
however, namely, we must disable logging and defer to processing/creation
of user-specific logfiles, along with creation of the pid file if we're
running as a daemon. We also need to disable non-fsfreeze-safe commands,
as we normally would when processing the guest-fsfreeze-freeze command.
To track when we need to do this in a way that persists between multiple
invocations of qemu-ga, we create a file on the guest filesystem before
issuing the fsfreeze, and delete it when doing the thaw. On qemu-ga
startup, we check for the existance of this file to determine
the need to take the above precautions.
We're forced to do it this way since a more traditional approach such as
reading/writing state to a dedicated state file will cause
access/modification time updates, respectively, both of which will hang
if the file resides on a frozen filesystem. Both can occur even if
relatime is enabled. Checking for file existence will not update the
access time, however, so it's a safe way to check for fsfreeze state.
An actual watchdog-based restart of qemu-ga can itself cause an access
time update that would thus hang the invocation of qemu-ga, but the
logic to workaround that can be handled via the watchdog, so we don't
address that here (for relatime we'd periodically touch the qemu-ga
binary if the file $qga_statedir/qga.state.isfrozen is not present, this
avoids qemu-ga updates or the 1 day relatime threshold causing an
access-time update if we try to respawn qemu-ga shortly after it goes
away)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2012-04-19 01:28:01 +04:00
|
|
|
log_filepath = optarg;
|
2011-07-21 00:19:37 +04:00
|
|
|
break;
|
|
|
|
case 'f':
|
qemu-ga: persist tracking of fsfreeze state via filesystem
Currently, qemu-ga may die/get killed/go away for whatever reason after
guest-fsfreeze-freeze has been issued, and before guest-fsfreeze-thaw
has been issued. This means the only way to unfreeze the guest is via
VNC/network/console access, but obtaining that access after-the-fact can
often be very difficult when filesystems are frozen. Logins will almost
always hang, for instance. In many cases the only recourse would be to
reboot the guest without any quiescing of volatile state, which makes
this a corner-case worth giving some attention to.
A likely failsafe for this situation would be to use a watchdog to
restart qemu-ga if it goes away. There are some precautions qemu-ga
needs to take in order to avoid immediately hanging itself on I/O,
however, namely, we must disable logging and defer to processing/creation
of user-specific logfiles, along with creation of the pid file if we're
running as a daemon. We also need to disable non-fsfreeze-safe commands,
as we normally would when processing the guest-fsfreeze-freeze command.
To track when we need to do this in a way that persists between multiple
invocations of qemu-ga, we create a file on the guest filesystem before
issuing the fsfreeze, and delete it when doing the thaw. On qemu-ga
startup, we check for the existance of this file to determine
the need to take the above precautions.
We're forced to do it this way since a more traditional approach such as
reading/writing state to a dedicated state file will cause
access/modification time updates, respectively, both of which will hang
if the file resides on a frozen filesystem. Both can occur even if
relatime is enabled. Checking for file existence will not update the
access time, however, so it's a safe way to check for fsfreeze state.
An actual watchdog-based restart of qemu-ga can itself cause an access
time update that would thus hang the invocation of qemu-ga, but the
logic to workaround that can be handled via the watchdog, so we don't
address that here (for relatime we'd periodically touch the qemu-ga
binary if the file $qga_statedir/qga.state.isfrozen is not present, this
avoids qemu-ga updates or the 1 day relatime threshold causing an
access-time update if we try to respawn qemu-ga shortly after it goes
away)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2012-04-19 01:28:01 +04:00
|
|
|
pid_filepath = optarg;
|
2011-07-21 00:19:37 +04:00
|
|
|
break;
|
2012-12-12 07:55:55 +04:00
|
|
|
#ifdef CONFIG_FSFREEZE
|
|
|
|
case 'F':
|
|
|
|
fsfreeze_hook = optarg ? optarg : QGA_FSFREEZE_HOOK_DEFAULT;
|
|
|
|
break;
|
|
|
|
#endif
|
qemu-ga: persist tracking of fsfreeze state via filesystem
Currently, qemu-ga may die/get killed/go away for whatever reason after
guest-fsfreeze-freeze has been issued, and before guest-fsfreeze-thaw
has been issued. This means the only way to unfreeze the guest is via
VNC/network/console access, but obtaining that access after-the-fact can
often be very difficult when filesystems are frozen. Logins will almost
always hang, for instance. In many cases the only recourse would be to
reboot the guest without any quiescing of volatile state, which makes
this a corner-case worth giving some attention to.
A likely failsafe for this situation would be to use a watchdog to
restart qemu-ga if it goes away. There are some precautions qemu-ga
needs to take in order to avoid immediately hanging itself on I/O,
however, namely, we must disable logging and defer to processing/creation
of user-specific logfiles, along with creation of the pid file if we're
running as a daemon. We also need to disable non-fsfreeze-safe commands,
as we normally would when processing the guest-fsfreeze-freeze command.
To track when we need to do this in a way that persists between multiple
invocations of qemu-ga, we create a file on the guest filesystem before
issuing the fsfreeze, and delete it when doing the thaw. On qemu-ga
startup, we check for the existance of this file to determine
the need to take the above precautions.
We're forced to do it this way since a more traditional approach such as
reading/writing state to a dedicated state file will cause
access/modification time updates, respectively, both of which will hang
if the file resides on a frozen filesystem. Both can occur even if
relatime is enabled. Checking for file existence will not update the
access time, however, so it's a safe way to check for fsfreeze state.
An actual watchdog-based restart of qemu-ga can itself cause an access
time update that would thus hang the invocation of qemu-ga, but the
logic to workaround that can be handled via the watchdog, so we don't
address that here (for relatime we'd periodically touch the qemu-ga
binary if the file $qga_statedir/qga.state.isfrozen is not present, this
avoids qemu-ga updates or the 1 day relatime threshold causing an
access-time update if we try to respawn qemu-ga shortly after it goes
away)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2012-04-19 01:28:01 +04:00
|
|
|
case 't':
|
|
|
|
state_dir = optarg;
|
|
|
|
break;
|
2011-07-21 00:19:37 +04:00
|
|
|
case 'v':
|
|
|
|
/* enable all log levels */
|
|
|
|
log_level = G_LOG_LEVEL_MASK;
|
|
|
|
break;
|
|
|
|
case 'V':
|
2012-05-14 18:33:48 +04:00
|
|
|
printf("QEMU Guest Agent %s\n", QEMU_VERSION);
|
2011-07-21 00:19:37 +04:00
|
|
|
return 0;
|
|
|
|
case 'd':
|
|
|
|
daemonize = 1;
|
|
|
|
break;
|
2011-12-07 08:03:42 +04:00
|
|
|
case 'b': {
|
|
|
|
char **list_head, **list;
|
2012-08-02 16:45:54 +04:00
|
|
|
if (is_help_option(optarg)) {
|
2011-12-07 08:03:42 +04:00
|
|
|
list_head = list = qmp_get_command_list();
|
|
|
|
while (*list != NULL) {
|
|
|
|
printf("%s\n", *list);
|
|
|
|
g_free(*list);
|
|
|
|
list++;
|
|
|
|
}
|
|
|
|
g_free(list_head);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
for (j = 0, i = 0, len = strlen(optarg); i < len; i++) {
|
|
|
|
if (optarg[i] == ',') {
|
|
|
|
optarg[i] = 0;
|
2012-04-18 04:01:45 +04:00
|
|
|
blacklist = g_list_append(blacklist, &optarg[j]);
|
2011-12-07 08:03:42 +04:00
|
|
|
j = i + 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (j < i) {
|
2012-04-18 04:01:45 +04:00
|
|
|
blacklist = g_list_append(blacklist, &optarg[j]);
|
2011-12-07 08:03:42 +04:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
2012-01-22 02:42:27 +04:00
|
|
|
#ifdef _WIN32
|
|
|
|
case 's':
|
|
|
|
service = optarg;
|
|
|
|
if (strcmp(service, "install") == 0) {
|
qemu-ga: persist tracking of fsfreeze state via filesystem
Currently, qemu-ga may die/get killed/go away for whatever reason after
guest-fsfreeze-freeze has been issued, and before guest-fsfreeze-thaw
has been issued. This means the only way to unfreeze the guest is via
VNC/network/console access, but obtaining that access after-the-fact can
often be very difficult when filesystems are frozen. Logins will almost
always hang, for instance. In many cases the only recourse would be to
reboot the guest without any quiescing of volatile state, which makes
this a corner-case worth giving some attention to.
A likely failsafe for this situation would be to use a watchdog to
restart qemu-ga if it goes away. There are some precautions qemu-ga
needs to take in order to avoid immediately hanging itself on I/O,
however, namely, we must disable logging and defer to processing/creation
of user-specific logfiles, along with creation of the pid file if we're
running as a daemon. We also need to disable non-fsfreeze-safe commands,
as we normally would when processing the guest-fsfreeze-freeze command.
To track when we need to do this in a way that persists between multiple
invocations of qemu-ga, we create a file on the guest filesystem before
issuing the fsfreeze, and delete it when doing the thaw. On qemu-ga
startup, we check for the existance of this file to determine
the need to take the above precautions.
We're forced to do it this way since a more traditional approach such as
reading/writing state to a dedicated state file will cause
access/modification time updates, respectively, both of which will hang
if the file resides on a frozen filesystem. Both can occur even if
relatime is enabled. Checking for file existence will not update the
access time, however, so it's a safe way to check for fsfreeze state.
An actual watchdog-based restart of qemu-ga can itself cause an access
time update that would thus hang the invocation of qemu-ga, but the
logic to workaround that can be handled via the watchdog, so we don't
address that here (for relatime we'd periodically touch the qemu-ga
binary if the file $qga_statedir/qga.state.isfrozen is not present, this
avoids qemu-ga updates or the 1 day relatime threshold causing an
access-time update if we try to respawn qemu-ga shortly after it goes
away)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2012-04-19 01:28:01 +04:00
|
|
|
return ga_install_service(path, log_filepath);
|
2012-01-22 02:42:27 +04:00
|
|
|
} else if (strcmp(service, "uninstall") == 0) {
|
|
|
|
return ga_uninstall_service();
|
|
|
|
} else {
|
|
|
|
printf("Unknown service command.\n");
|
|
|
|
return EXIT_FAILURE;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
#endif
|
2011-07-21 00:19:37 +04:00
|
|
|
case 'h':
|
|
|
|
usage(argv[0]);
|
|
|
|
return 0;
|
|
|
|
case '?':
|
|
|
|
g_print("Unknown option, try '%s --help' for more information.\n",
|
|
|
|
argv[0]);
|
|
|
|
return EXIT_FAILURE;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-08-21 07:09:37 +04:00
|
|
|
s = g_malloc0(sizeof(GAState));
|
2011-07-21 00:19:37 +04:00
|
|
|
s->log_level = log_level;
|
qemu-ga: persist tracking of fsfreeze state via filesystem
Currently, qemu-ga may die/get killed/go away for whatever reason after
guest-fsfreeze-freeze has been issued, and before guest-fsfreeze-thaw
has been issued. This means the only way to unfreeze the guest is via
VNC/network/console access, but obtaining that access after-the-fact can
often be very difficult when filesystems are frozen. Logins will almost
always hang, for instance. In many cases the only recourse would be to
reboot the guest without any quiescing of volatile state, which makes
this a corner-case worth giving some attention to.
A likely failsafe for this situation would be to use a watchdog to
restart qemu-ga if it goes away. There are some precautions qemu-ga
needs to take in order to avoid immediately hanging itself on I/O,
however, namely, we must disable logging and defer to processing/creation
of user-specific logfiles, along with creation of the pid file if we're
running as a daemon. We also need to disable non-fsfreeze-safe commands,
as we normally would when processing the guest-fsfreeze-freeze command.
To track when we need to do this in a way that persists between multiple
invocations of qemu-ga, we create a file on the guest filesystem before
issuing the fsfreeze, and delete it when doing the thaw. On qemu-ga
startup, we check for the existance of this file to determine
the need to take the above precautions.
We're forced to do it this way since a more traditional approach such as
reading/writing state to a dedicated state file will cause
access/modification time updates, respectively, both of which will hang
if the file resides on a frozen filesystem. Both can occur even if
relatime is enabled. Checking for file existence will not update the
access time, however, so it's a safe way to check for fsfreeze state.
An actual watchdog-based restart of qemu-ga can itself cause an access
time update that would thus hang the invocation of qemu-ga, but the
logic to workaround that can be handled via the watchdog, so we don't
address that here (for relatime we'd periodically touch the qemu-ga
binary if the file $qga_statedir/qga.state.isfrozen is not present, this
avoids qemu-ga updates or the 1 day relatime threshold causing an
access-time update if we try to respawn qemu-ga shortly after it goes
away)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2012-04-19 01:28:01 +04:00
|
|
|
s->log_file = stderr;
|
2012-12-12 07:55:55 +04:00
|
|
|
#ifdef CONFIG_FSFREEZE
|
|
|
|
s->fsfreeze_hook = fsfreeze_hook;
|
|
|
|
#endif
|
2011-07-21 00:19:37 +04:00
|
|
|
g_log_set_default_handler(ga_log, s);
|
|
|
|
g_log_set_fatal_mask(NULL, G_LOG_LEVEL_ERROR);
|
qemu-ga: persist tracking of fsfreeze state via filesystem
Currently, qemu-ga may die/get killed/go away for whatever reason after
guest-fsfreeze-freeze has been issued, and before guest-fsfreeze-thaw
has been issued. This means the only way to unfreeze the guest is via
VNC/network/console access, but obtaining that access after-the-fact can
often be very difficult when filesystems are frozen. Logins will almost
always hang, for instance. In many cases the only recourse would be to
reboot the guest without any quiescing of volatile state, which makes
this a corner-case worth giving some attention to.
A likely failsafe for this situation would be to use a watchdog to
restart qemu-ga if it goes away. There are some precautions qemu-ga
needs to take in order to avoid immediately hanging itself on I/O,
however, namely, we must disable logging and defer to processing/creation
of user-specific logfiles, along with creation of the pid file if we're
running as a daemon. We also need to disable non-fsfreeze-safe commands,
as we normally would when processing the guest-fsfreeze-freeze command.
To track when we need to do this in a way that persists between multiple
invocations of qemu-ga, we create a file on the guest filesystem before
issuing the fsfreeze, and delete it when doing the thaw. On qemu-ga
startup, we check for the existance of this file to determine
the need to take the above precautions.
We're forced to do it this way since a more traditional approach such as
reading/writing state to a dedicated state file will cause
access/modification time updates, respectively, both of which will hang
if the file resides on a frozen filesystem. Both can occur even if
relatime is enabled. Checking for file existence will not update the
access time, however, so it's a safe way to check for fsfreeze state.
An actual watchdog-based restart of qemu-ga can itself cause an access
time update that would thus hang the invocation of qemu-ga, but the
logic to workaround that can be handled via the watchdog, so we don't
address that here (for relatime we'd periodically touch the qemu-ga
binary if the file $qga_statedir/qga.state.isfrozen is not present, this
avoids qemu-ga updates or the 1 day relatime threshold causing an
access-time update if we try to respawn qemu-ga shortly after it goes
away)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2012-04-19 01:28:01 +04:00
|
|
|
ga_enable_logging(s);
|
|
|
|
s->state_filepath_isfrozen = g_strdup_printf("%s/qga.state.isfrozen",
|
|
|
|
state_dir);
|
2012-04-18 04:01:45 +04:00
|
|
|
s->frozen = false;
|
qemu-ga: persist tracking of fsfreeze state via filesystem
Currently, qemu-ga may die/get killed/go away for whatever reason after
guest-fsfreeze-freeze has been issued, and before guest-fsfreeze-thaw
has been issued. This means the only way to unfreeze the guest is via
VNC/network/console access, but obtaining that access after-the-fact can
often be very difficult when filesystems are frozen. Logins will almost
always hang, for instance. In many cases the only recourse would be to
reboot the guest without any quiescing of volatile state, which makes
this a corner-case worth giving some attention to.
A likely failsafe for this situation would be to use a watchdog to
restart qemu-ga if it goes away. There are some precautions qemu-ga
needs to take in order to avoid immediately hanging itself on I/O,
however, namely, we must disable logging and defer to processing/creation
of user-specific logfiles, along with creation of the pid file if we're
running as a daemon. We also need to disable non-fsfreeze-safe commands,
as we normally would when processing the guest-fsfreeze-freeze command.
To track when we need to do this in a way that persists between multiple
invocations of qemu-ga, we create a file on the guest filesystem before
issuing the fsfreeze, and delete it when doing the thaw. On qemu-ga
startup, we check for the existance of this file to determine
the need to take the above precautions.
We're forced to do it this way since a more traditional approach such as
reading/writing state to a dedicated state file will cause
access/modification time updates, respectively, both of which will hang
if the file resides on a frozen filesystem. Both can occur even if
relatime is enabled. Checking for file existence will not update the
access time, however, so it's a safe way to check for fsfreeze state.
An actual watchdog-based restart of qemu-ga can itself cause an access
time update that would thus hang the invocation of qemu-ga, but the
logic to workaround that can be handled via the watchdog, so we don't
address that here (for relatime we'd periodically touch the qemu-ga
binary if the file $qga_statedir/qga.state.isfrozen is not present, this
avoids qemu-ga updates or the 1 day relatime threshold causing an
access-time update if we try to respawn qemu-ga shortly after it goes
away)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2012-04-19 01:28:01 +04:00
|
|
|
#ifndef _WIN32
|
|
|
|
/* check if a previous instance of qemu-ga exited with filesystems' state
|
|
|
|
* marked as frozen. this could be a stale value (a non-qemu-ga process
|
|
|
|
* or reboot may have since unfrozen them), but better to require an
|
|
|
|
* uneeded unfreeze than to risk hanging on start-up
|
|
|
|
*/
|
|
|
|
struct stat st;
|
|
|
|
if (stat(s->state_filepath_isfrozen, &st) == -1) {
|
|
|
|
/* it's okay if the file doesn't exist, but if we can't access for
|
|
|
|
* some other reason, such as permissions, there's a configuration
|
|
|
|
* that needs to be addressed. so just bail now before we get into
|
|
|
|
* more trouble later
|
|
|
|
*/
|
|
|
|
if (errno != ENOENT) {
|
|
|
|
g_critical("unable to access state file at path %s: %s",
|
|
|
|
s->state_filepath_isfrozen, strerror(errno));
|
|
|
|
return EXIT_FAILURE;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
g_warning("previous instance appears to have exited with frozen"
|
|
|
|
" filesystems. deferring logging/pidfile creation and"
|
|
|
|
" disabling non-fsfreeze-safe commands until"
|
|
|
|
" guest-fsfreeze-thaw is issued, or filesystems are"
|
|
|
|
" manually unfrozen and the file %s is removed",
|
|
|
|
s->state_filepath_isfrozen);
|
|
|
|
s->frozen = true;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
if (ga_is_frozen(s)) {
|
|
|
|
if (daemonize) {
|
|
|
|
/* delay opening/locking of pidfile till filesystem are unfrozen */
|
|
|
|
s->deferred_options.pid_filepath = pid_filepath;
|
|
|
|
become_daemon(NULL);
|
|
|
|
}
|
|
|
|
if (log_filepath) {
|
|
|
|
/* delay opening the log file till filesystems are unfrozen */
|
|
|
|
s->deferred_options.log_filepath = log_filepath;
|
|
|
|
}
|
|
|
|
ga_disable_logging(s);
|
|
|
|
ga_disable_non_whitelisted();
|
|
|
|
} else {
|
|
|
|
if (daemonize) {
|
|
|
|
become_daemon(pid_filepath);
|
|
|
|
}
|
|
|
|
if (log_filepath) {
|
2013-01-09 01:26:26 +04:00
|
|
|
FILE *log_file = ga_open_logfile(log_filepath);
|
2012-05-15 01:42:35 +04:00
|
|
|
if (!log_file) {
|
qemu-ga: persist tracking of fsfreeze state via filesystem
Currently, qemu-ga may die/get killed/go away for whatever reason after
guest-fsfreeze-freeze has been issued, and before guest-fsfreeze-thaw
has been issued. This means the only way to unfreeze the guest is via
VNC/network/console access, but obtaining that access after-the-fact can
often be very difficult when filesystems are frozen. Logins will almost
always hang, for instance. In many cases the only recourse would be to
reboot the guest without any quiescing of volatile state, which makes
this a corner-case worth giving some attention to.
A likely failsafe for this situation would be to use a watchdog to
restart qemu-ga if it goes away. There are some precautions qemu-ga
needs to take in order to avoid immediately hanging itself on I/O,
however, namely, we must disable logging and defer to processing/creation
of user-specific logfiles, along with creation of the pid file if we're
running as a daemon. We also need to disable non-fsfreeze-safe commands,
as we normally would when processing the guest-fsfreeze-freeze command.
To track when we need to do this in a way that persists between multiple
invocations of qemu-ga, we create a file on the guest filesystem before
issuing the fsfreeze, and delete it when doing the thaw. On qemu-ga
startup, we check for the existance of this file to determine
the need to take the above precautions.
We're forced to do it this way since a more traditional approach such as
reading/writing state to a dedicated state file will cause
access/modification time updates, respectively, both of which will hang
if the file resides on a frozen filesystem. Both can occur even if
relatime is enabled. Checking for file existence will not update the
access time, however, so it's a safe way to check for fsfreeze state.
An actual watchdog-based restart of qemu-ga can itself cause an access
time update that would thus hang the invocation of qemu-ga, but the
logic to workaround that can be handled via the watchdog, so we don't
address that here (for relatime we'd periodically touch the qemu-ga
binary if the file $qga_statedir/qga.state.isfrozen is not present, this
avoids qemu-ga updates or the 1 day relatime threshold causing an
access-time update if we try to respawn qemu-ga shortly after it goes
away)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2012-04-19 01:28:01 +04:00
|
|
|
g_critical("unable to open specified log file: %s",
|
|
|
|
strerror(errno));
|
|
|
|
goto out_bad;
|
|
|
|
}
|
2012-05-15 01:42:35 +04:00
|
|
|
s->log_file = log_file;
|
qemu-ga: persist tracking of fsfreeze state via filesystem
Currently, qemu-ga may die/get killed/go away for whatever reason after
guest-fsfreeze-freeze has been issued, and before guest-fsfreeze-thaw
has been issued. This means the only way to unfreeze the guest is via
VNC/network/console access, but obtaining that access after-the-fact can
often be very difficult when filesystems are frozen. Logins will almost
always hang, for instance. In many cases the only recourse would be to
reboot the guest without any quiescing of volatile state, which makes
this a corner-case worth giving some attention to.
A likely failsafe for this situation would be to use a watchdog to
restart qemu-ga if it goes away. There are some precautions qemu-ga
needs to take in order to avoid immediately hanging itself on I/O,
however, namely, we must disable logging and defer to processing/creation
of user-specific logfiles, along with creation of the pid file if we're
running as a daemon. We also need to disable non-fsfreeze-safe commands,
as we normally would when processing the guest-fsfreeze-freeze command.
To track when we need to do this in a way that persists between multiple
invocations of qemu-ga, we create a file on the guest filesystem before
issuing the fsfreeze, and delete it when doing the thaw. On qemu-ga
startup, we check for the existance of this file to determine
the need to take the above precautions.
We're forced to do it this way since a more traditional approach such as
reading/writing state to a dedicated state file will cause
access/modification time updates, respectively, both of which will hang
if the file resides on a frozen filesystem. Both can occur even if
relatime is enabled. Checking for file existence will not update the
access time, however, so it's a safe way to check for fsfreeze state.
An actual watchdog-based restart of qemu-ga can itself cause an access
time update that would thus hang the invocation of qemu-ga, but the
logic to workaround that can be handled via the watchdog, so we don't
address that here (for relatime we'd periodically touch the qemu-ga
binary if the file $qga_statedir/qga.state.isfrozen is not present, this
avoids qemu-ga updates or the 1 day relatime threshold causing an
access-time update if we try to respawn qemu-ga shortly after it goes
away)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2012-04-19 01:28:01 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-04-18 04:01:45 +04:00
|
|
|
if (blacklist) {
|
|
|
|
s->blacklist = blacklist;
|
|
|
|
do {
|
|
|
|
g_debug("disabling command: %s", (char *)blacklist->data);
|
|
|
|
qmp_disable_command(blacklist->data);
|
|
|
|
blacklist = g_list_next(blacklist);
|
|
|
|
} while (blacklist);
|
|
|
|
}
|
2011-07-20 00:41:55 +04:00
|
|
|
s->command_state = ga_command_state_new();
|
|
|
|
ga_command_state_init(s, s->command_state);
|
|
|
|
ga_command_state_init_all(s->command_state);
|
2012-01-19 10:18:20 +04:00
|
|
|
json_message_parser_init(&s->parser, process_event);
|
2011-07-21 00:19:37 +04:00
|
|
|
ga_state = s;
|
2012-01-20 08:04:34 +04:00
|
|
|
#ifndef _WIN32
|
2012-01-19 10:18:20 +04:00
|
|
|
if (!register_signal_handlers()) {
|
|
|
|
g_critical("failed to register signal handlers");
|
|
|
|
goto out_bad;
|
|
|
|
}
|
2012-01-20 08:04:34 +04:00
|
|
|
#endif
|
2011-07-21 00:19:37 +04:00
|
|
|
|
2012-01-19 10:18:20 +04:00
|
|
|
s->main_loop = g_main_loop_new(NULL, false);
|
|
|
|
if (!channel_init(ga_state, method, path)) {
|
|
|
|
g_critical("failed to initialize guest agent channel");
|
|
|
|
goto out_bad;
|
|
|
|
}
|
2012-01-22 02:42:27 +04:00
|
|
|
#ifndef _WIN32
|
2011-07-21 00:19:37 +04:00
|
|
|
g_main_loop_run(ga_state->main_loop);
|
2012-01-22 02:42:27 +04:00
|
|
|
#else
|
|
|
|
if (daemonize) {
|
|
|
|
SERVICE_TABLE_ENTRY service_table[] = {
|
|
|
|
{ (char *)QGA_SERVICE_NAME, service_main }, { NULL, NULL } };
|
|
|
|
StartServiceCtrlDispatcher(service_table);
|
|
|
|
} else {
|
|
|
|
g_main_loop_run(ga_state->main_loop);
|
|
|
|
}
|
|
|
|
#endif
|
2011-07-21 00:19:37 +04:00
|
|
|
|
2011-07-20 00:41:55 +04:00
|
|
|
ga_command_state_cleanup_all(ga_state->command_state);
|
2012-01-19 10:18:20 +04:00
|
|
|
ga_channel_free(ga_state->channel);
|
2011-07-21 00:19:37 +04:00
|
|
|
|
2012-01-19 10:18:20 +04:00
|
|
|
if (daemonize) {
|
qemu-ga: persist tracking of fsfreeze state via filesystem
Currently, qemu-ga may die/get killed/go away for whatever reason after
guest-fsfreeze-freeze has been issued, and before guest-fsfreeze-thaw
has been issued. This means the only way to unfreeze the guest is via
VNC/network/console access, but obtaining that access after-the-fact can
often be very difficult when filesystems are frozen. Logins will almost
always hang, for instance. In many cases the only recourse would be to
reboot the guest without any quiescing of volatile state, which makes
this a corner-case worth giving some attention to.
A likely failsafe for this situation would be to use a watchdog to
restart qemu-ga if it goes away. There are some precautions qemu-ga
needs to take in order to avoid immediately hanging itself on I/O,
however, namely, we must disable logging and defer to processing/creation
of user-specific logfiles, along with creation of the pid file if we're
running as a daemon. We also need to disable non-fsfreeze-safe commands,
as we normally would when processing the guest-fsfreeze-freeze command.
To track when we need to do this in a way that persists between multiple
invocations of qemu-ga, we create a file on the guest filesystem before
issuing the fsfreeze, and delete it when doing the thaw. On qemu-ga
startup, we check for the existance of this file to determine
the need to take the above precautions.
We're forced to do it this way since a more traditional approach such as
reading/writing state to a dedicated state file will cause
access/modification time updates, respectively, both of which will hang
if the file resides on a frozen filesystem. Both can occur even if
relatime is enabled. Checking for file existence will not update the
access time, however, so it's a safe way to check for fsfreeze state.
An actual watchdog-based restart of qemu-ga can itself cause an access
time update that would thus hang the invocation of qemu-ga, but the
logic to workaround that can be handled via the watchdog, so we don't
address that here (for relatime we'd periodically touch the qemu-ga
binary if the file $qga_statedir/qga.state.isfrozen is not present, this
avoids qemu-ga updates or the 1 day relatime threshold causing an
access-time update if we try to respawn qemu-ga shortly after it goes
away)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2012-04-19 01:28:01 +04:00
|
|
|
unlink(pid_filepath);
|
2012-01-19 10:18:20 +04:00
|
|
|
}
|
2011-07-21 00:19:37 +04:00
|
|
|
return 0;
|
2012-01-19 10:18:20 +04:00
|
|
|
|
|
|
|
out_bad:
|
|
|
|
if (daemonize) {
|
qemu-ga: persist tracking of fsfreeze state via filesystem
Currently, qemu-ga may die/get killed/go away for whatever reason after
guest-fsfreeze-freeze has been issued, and before guest-fsfreeze-thaw
has been issued. This means the only way to unfreeze the guest is via
VNC/network/console access, but obtaining that access after-the-fact can
often be very difficult when filesystems are frozen. Logins will almost
always hang, for instance. In many cases the only recourse would be to
reboot the guest without any quiescing of volatile state, which makes
this a corner-case worth giving some attention to.
A likely failsafe for this situation would be to use a watchdog to
restart qemu-ga if it goes away. There are some precautions qemu-ga
needs to take in order to avoid immediately hanging itself on I/O,
however, namely, we must disable logging and defer to processing/creation
of user-specific logfiles, along with creation of the pid file if we're
running as a daemon. We also need to disable non-fsfreeze-safe commands,
as we normally would when processing the guest-fsfreeze-freeze command.
To track when we need to do this in a way that persists between multiple
invocations of qemu-ga, we create a file on the guest filesystem before
issuing the fsfreeze, and delete it when doing the thaw. On qemu-ga
startup, we check for the existance of this file to determine
the need to take the above precautions.
We're forced to do it this way since a more traditional approach such as
reading/writing state to a dedicated state file will cause
access/modification time updates, respectively, both of which will hang
if the file resides on a frozen filesystem. Both can occur even if
relatime is enabled. Checking for file existence will not update the
access time, however, so it's a safe way to check for fsfreeze state.
An actual watchdog-based restart of qemu-ga can itself cause an access
time update that would thus hang the invocation of qemu-ga, but the
logic to workaround that can be handled via the watchdog, so we don't
address that here (for relatime we'd periodically touch the qemu-ga
binary if the file $qga_statedir/qga.state.isfrozen is not present, this
avoids qemu-ga updates or the 1 day relatime threshold causing an
access-time update if we try to respawn qemu-ga shortly after it goes
away)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2012-04-19 01:28:01 +04:00
|
|
|
unlink(pid_filepath);
|
2012-01-19 10:18:20 +04:00
|
|
|
}
|
|
|
|
return EXIT_FAILURE;
|
2011-07-21 00:19:37 +04:00
|
|
|
}
|