The commands snapshot-drive and delete-drive-snapshot have been unused
by qemu-server since commit eba2b721 ("use qemu's blockdev-snapshot
functions") and are now going to be dropped in our QEMU builds too, so
get rid of these left-overs.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
allowing slower or overloaded systems a higher chance to finish
commands while not being to long to be problematic for sync api calls
with their 30s total budget
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
like for other drive-related operations. The default of 3 seconds is
just not enough for large (or slow) disks.
Reported in the community forum:
https://forum.proxmox.com/threads/49543/
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Using a loop of freeze, sleep 5, thaw, sleep 5, an idling Windows 11
VM with 4 cores and 8GiB RAM once took 54 seconds for thawing. It took
less than a second about 90% of the time and maximum of a few seconds
for the majortiy of other cases, but there can be outliers where 10
seconds is not enough.
And there can be hookscripts executed upon thaw, which might also not
complete instantly.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
Since the MacOS Mojave Apple ships AppleQEMUGuestAgent by default.
However, it does not fully adhere to QGA specs as they do expect each
command to be newline delimited.
This makes each command to be newline delimited which is harmless for
all other systems (Windows, Linux), but enable guest agent by default
without any changes on OSX.
Signed-off-by: Kamil Trzcinski <ayufan@ayufan.eu>
Tested-by: Dominik Csapak <d.csapak@proxmox.com>
Reviewed-by: Dominik Csapak <d.csapak@proxmox.com>
Also remove unused $confdir variable in QemuConfig, but leave it and
$lock_dir there, since those paths should only be used with
cfs_config_path anyway.
nodename() is still called in multiple places, but since it's cached by
INotify it doesn't really matter.
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
Explicitly close leftover connections in the destructor,
otherwise the IO::Multiplex instance can be leaked causing
the qmp connection to never be closed.
This could occur for instance when cancelling vzdump with
ctrl+c with extremely unlucky timing...
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Instead of our own. The code is almost the same, but the
upstream implementation uses qemu's transactional system and
performs a drain() on the block device first. This seems to
help avoid some issues we run into with qcow2 files when
creating snapshots.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
in case of e.g. a non-existant guest-agent command, it would return
{ error: {someerrorobject} }
but we did only include the 'return' property
in case we do not get any and the error property is set,
return that
i looked at all the paths were we use the QMPClient, and either
we have our own callback for the result,
or we do not rely on the result being empty upon an error, so this
should not break anything
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
The qmp command 'guest-fsfreeze-freeze' issues in linux a FIFREEZE
ioctl call on all mounted guest FS.
This ioctl call locks the filesystem and gets it into an consistent
state. For this all caches must be synced after blocking new writes
to the FS, which may need a relative long time, especially under high
IO load on the backing storage.
In windows a VSS (Volume Shadow Copy Service) request_freeze will
issued. As of the closed Windows nature the exact mechanisms cannot
be checked but some microsoft blog posts and other forum post suggest
that it should return fast but certain workloads can still trigger a
long delay resulting an similar problems.
Thus try to minimize the error probability and increase the timeout
significantly.
We use 60 minutes as timeout as this seems a limit which should not
get trespassed in a somewhat healthy system.
See:
https://forum.proxmox.com/threads/22192/
see the 'freeze_super' and 'thaw_super' function in fs/super.c from
the linux kernel tree for more details on the freeze behavior in
Linux guests.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
result sample:
first json is guest-sync result, second json is command result
{ "return": 123456}\n{"return": {}}
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
Signed-off-by: Dietmar Maurer <dietmar@proxmox.com>
example of command:
first json is guest-sync to sync and flush the client, second json is the command
{ "execute": "guest-sync", "arguments": { "id": 123456 } }{"execute":"guest-ping"}
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
