aboutsummaryrefslogtreecommitdiff
path: root/qapi-schema-guest.json
AgeCommit message (Collapse)AuthorFilesLines
2012-06-21qemu-ga: add guest-fstrim commandPaolo Bonzini1-0/+20
FITRIM is a mounted filesystem feature to discard (or "trim") blocks which are not in use by the filesystem. This is useful for solid-state drives (SSDs) and thinly-provisioned storage. Provide access to the feature from the host so that filesystems can be trimmed periodically or before migration. Here is an example using scsi_debug: # modprobe scsi_debug lbpu=1 lbpws=1 # sg_vpd -p0xb2 /dev/sdb Logical block provisioning VPD page (SBC): Unmap command supported (LBPU): 1 Write same (16) with unmap bit supported (LBWS): 1 Write same (10) with unmap bit supported (LBWS10): 0 # mke2fs /dev/sdb # cat /sys/bus/pseudo/drivers/scsi_debug/map 1-616,16257-16383 # mount /dev/sdb /run/media/pbonzini/test # dd if=/dev/zero of=/run/media/pbonzini/test/file # cat map 1-616,645-1588,1599-4026,4029-16383 # rm /run/media/pbonzini/test/file # ./qemu-ga /dev/fd/0 {"execute":"guest-fstrim"} {"return": {}} # cat map 1-612 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Luiz Capitulino <lcapitulino@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2012-05-15qemu-ga: guest-shutdown: use only async-signal-safe functionsLuiz Capitulino1-2/+1
POSIX mandates[1] that a child process of a multi-thread program uses only async-signal-safe functions before exec(). We consider qemu-ga to be multi-thread, because it uses glib. However, qmp_guest_shutdown() uses functions that are not async-signal-safe. Fix it the following way: - fclose() -> reopen_fd_to_null() - execl() -> execle() - exit() -> _exit() - drop slog() usage (which is not safe) [1] http://pubs.opengroup.org/onlinepubs/009695399/functions/fork.html 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-15qemu-ga: guest-suspend-hybrid: don't emit a success responseLuiz Capitulino1-6/+10
Today, qemu-ga may not be able to emit a success response when guest-suspend-hybrid completes. This happens because the VM may suspend before qemu-ga is able to emit a response. This semantic is a bit confusing, as it's not clear for clients if they should wait for a response or how they should check for success. This commit solves that problem by changing guest-suspend-hybrid to never emit a success response and suggests in the documentation what clients should do to check for success. Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2012-05-15qemu-ga: guest-suspend-ram: don't emit a success responseLuiz Capitulino1-6/+10
Today, qemu-ga may not be able to emit a success response when guest-suspend-ram completes. This happens because the VM may suspend before qemu-ga is able to emit a response. This semantic is a bit confusing, as it's not clear for clients if they should wait for a response or how they should check for success. This commit solves that problem by changing guest-suspend-ram to never emit a success response and suggests in the documentation what clients should do to check for success. Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2012-05-15qemu-ga: guest-suspend-disk: don't emit a success responseLuiz Capitulino1-6/+10
Today, qemu-ga may not be able to emit a success response when guest-suspend-disk completes. This happens because the VM may vanish before qemu-ga is able to emit a response. This semantic is a bit confusing, as it's not clear for clients if they should wait for a response or how they should check for success. This commit solves that problem by changing guest-suspend-disk to never emit a success response and suggests in the documentation what clients could do to check for success. Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2012-05-15qemu-ga: guest-shutdown: don't emit a success responseLuiz Capitulino1-2/+6
Today, qemu-ga may not be able to emit a success response when guest-shutdown completes. This happens because the VM may vanish before qemu-ga is able to emit a response. This semantic is a bit confusing, as it's not clear for clients if they should wait for a response or how they should check for success. This commit solves that problem by changing guest-shutdown to never emit a success response and suggests in the documentation what clients could do to check for success. Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2012-05-14fix some common typosJim Meyering1-1/+1
These were identified using: http://github.com/lyda/misspell-check and run like this to create a bourne shell script using GNU sed's -i option: git ls-files|grep -vF .bin | misspellings -f - |grep -v '^ERROR:' |perl \ -pe 's/^(.*?)\[(\d+)\]: (\w+) -> "(.*?)"$/sed -i '\''${2}s!$3!$4!'\'' $1/' Manually eliding the FP, "rela->real" and resolving "addres" to address (not "adders") we get this: sed -i '450s!thru!through!' Changelog sed -i '260s!neccessary!necessary!' coroutine-sigaltstack.c sed -i '54s!miniscule!minuscule!' disas.c sed -i '1094s!thru!through!' hw/usb/hcd-ehci.c sed -i '1095s!thru!through!' hw/usb/hcd-ehci.c sed -i '21s!unecessary!unnecessary!' qapi-schema-guest.json sed -i '307s!explictly!explicitly!' qemu-ga.c sed -i '490s!preceeding!preceding!' qga/commands-posix.c sed -i '792s!addres!address!' qga/commands-posix.c sed -i '6s!beeing!being!' tests/tcg/test-mmap.c Also, manually fix "arithmentic", spotted by Peter Maydell: sed -i 's!arithmentic!arithmetic!' coroutine-sigaltstack.c Signed-off-by: Jim Meyering <meyering@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
2012-04-30qemu-ga: persist tracking of fsfreeze state via filesystemMichael Roth1-2/+1
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-30qemu-ga: improve recovery options for fsfreezeMichael Roth1-10/+16
guest-fsfreeze-thaw relies on state information obtained from guest-fsfreeze-freeze to determine what filesystems to unfreeze. This is unreliable due to the fact that that state does not account for FIFREEZE being issued by other processes, or previous instances of qemu-ga. This means in certain situations we cannot thaw filesystems even with a responsive qemu-ga instance at our disposal. This patch allows guest-fsfreeze-thaw to be issued unconditionally. It also adds some additional logic to allow us to thaw filesystems regardless of how many times the filesystem's "frozen" refcount has been incremented by any guest processes. Also, guest-fsfreeze-freeze now operates atomically: on success all freezable filesystems are frozen, and on error all filesystems are thawed. The ambiguous "GUEST_FSFREEZE_STATUS_ERROR" state is no longer entered. Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2012-03-12qemu-ga: add guest-sync-delimitedMichael Roth1-1/+47
guest-sync leaves it as an exercise to the user as to how to reliably obtain the response to guest-sync if the client had previously read in a partial response (due qemu-ga previously being restarted mid-"sentence" due to reboot, forced restart, etc). qemu-ga handles this situation on its end by having a client precede their guest-sync request with a 0xFF byte (invalid UTF-8), which qemu-ga/QEMU JSON parsers will treat as a flush event. Thus we can reliably flush the qemu-ga parser state in preparation for receiving the guest-sync request. guest-sync-delimited provides the same functionality for a client: when a guest-sync-delimited is issued, qemu-ga will precede it's response with a 0xFF byte that the client can use as an indicator to flush its buffer/parser state in preparation for reliably receiving the guest-sync-delimited response. It is also useful as an optimization for clients, since, after issuing a guest-sync-delimited, clients can safely discard all stale data read from the channel until the 0xFF is found. More information available on the wiki: http://wiki.qemu.org/Features/QAPI/GuestAgent#QEMU_Guest_Agent_Protocol Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2012-03-12qemu-ga: add guest-network-get-interfaces commandMichal Privoznik1-0/+59
This command returns an array of: [ifname, hwaddr, [ipaddr, ipaddr_family, prefix] ] for each interface in the system. Currently, only IPv4 and IPv6 are supported. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2012-03-12qemu-ga: add guest-suspend-hybridLuiz Capitulino1-0/+23
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
2012-03-12qemu-ga: add guest-suspend-ramLuiz Capitulino1-0/+28
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
2012-03-12qemu-ga: add guest-suspend-diskLuiz Capitulino1-0/+24
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-23qemu-ga: Add schema documentation for typesMichael Roth1-21/+97
Document guest agent schema types in similar fashion to qmp schema types.
2011-12-14Merge remote-tracking branch 'stefanha/trivial-patches-next' into stagingAnthony Liguori1-1/+1
2011-12-14Fix spelling in comments, documentation and messagesStefan Weil1-1/+1
accidently->accidentally annother->another choosen->chosen consideres->considers decriptor->descriptor developement->development paramter->parameter preceed->precede preceeding->preceding priviledge->privilege propogation->propagation substraction->subtraction throught->through upto->up to usefull->useful Fix also grammar in posix-aio-compat.c Signed-off-by: Stefan Weil <sw@weilnetz.de> Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
2011-12-12guest agent: add supported command list to guest-info RPCMichael Roth1-1/+5
Not that there is blacklisting functionality we can no longer infer the agent's capabilities via version. This patch extends the current guest-info RPC to also return a list of dictionaries containing the name of each supported RPC, along with a boolean indicating whether or not the command has been disabled by a guest administrator/distro. Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-07-21guest agent: add guest agent RPCs/commandsMichael Roth1-0/+217
This adds the initial set of QMP/QAPI commands provided by the guest agent: guest-sync guest-ping guest-info guest-shutdown guest-file-open guest-file-read guest-file-write guest-file-seek guest-file-flush guest-file-close guest-fsfreeze-freeze guest-fsfreeze-thaw guest-fsfreeze-status The input/output specification for these commands are documented in the schema. Example usage: host: qemu -device virtio-serial \ -chardev socket,path=/tmp/vs0.sock,server,nowait,id=qga0 \ -device virtserialport,chardev=qga0,name=org.qemu.quest_agent.0 ... echo "{'execute':'guest-info'}" | socat stdio unix-connect:/tmp/qga0.sock guest: qemu-ga -m virtio-serial -p /dev/virtio-ports/org.qemu.guest_agent.0 \ -p /var/run/qemu-guest-agent.pid -d Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: Luiz Capitulino <lcapitulino@gmail.com>