Stefan Reiter [Wed, 24 Feb 2021 13:34:47 +0000 (14:34 +0100)]
pbs-restore: unref/close target block backend
Use blk_unref to drop the last reference, which will close the block
backend and flush all caches and outstanding writes.
This is especially important for restoring to Ceph, as the userspace
librbd caches will not be flushed if the application exits immediately,
leading to potentially incomplete restores.
Reported-by: Eneko Lacunza <elacunza@binovo.es> Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
Stefan Reiter [Thu, 11 Feb 2021 16:11:11 +0000 (17:11 +0100)]
Update to QEMU 5.2
Lots of patches touched and some slight changes to the build process
since QEMU switched to meson as their build system. Functionality-wise
very little rebasing required.
New patches introduced:
* pve/0058: to fix VMA backups and clean up some code in general with
new 5.2 features now available to us (namely coroutine-enabled QMP).
* extra/0002: don't build man pages for guest agent when disabled
* extra/0003: fix live-migration with hugepages
* 0017 and 0018 are adjusted to fix snapshot abort and improve
snap performance a bit
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
Fabian Ebner [Tue, 17 Nov 2020 11:38:36 +0000 (12:38 +0100)]
fix #3084: fall back to open-iscsi initiatorname
Fixes vma restore when the target is an iSCSI storage which expects that
initiatorname. Also avoids the need to always explicitly set the initiatorname
in PVE code, thus fixing moving efidisks from and to such iSCSI storages.
Stefan Reiter [Thu, 10 Dec 2020 15:23:38 +0000 (16:23 +0100)]
disable jemalloc
jemalloc does not play nice with our Rust library (proxmox-backup-qemu),
specifically it never releases memory allocated from Rust to the OS.
This leads to a problem with larger caches (e.g. for the PBS block driver).
It appears to be related to this GitHub issue:
https://github.com/jemalloc/jemalloc/issues/1398
The background_thread solution seems weirdly hacky, so let's disable
jemalloc entirely for now.
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
The idea in general is to migrate all the state, which is small for
us, in a single step once. But, QEMU only calls save state if we
return active true.
Hardcoding is-active to return true, like done initially, makes the
migration freeze, as QEMU thinks this is never done, and only stops
calling us and finishes after a few seconds.
So, add a state with an "active" boolean, set to true when
initializing a migration, and set it to false when the state was
saved.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Oguz Bektas [Mon, 10 Aug 2020 12:32:22 +0000 (14:32 +0200)]
patch for possible DOS in qemu network packet processing
fixes an assertion failure in qemu network packet processing, which can
lead to DOS'ing the qemu process on the host. this affects 'e1000e' and
'vmxnet3' network devices.
patch is cherry-picked from the commit mentioned in the oss-security email.
Stefan Reiter [Tue, 14 Jul 2020 08:45:16 +0000 (10:45 +0200)]
Fix dirty-bitmap PBS backup with multiple drives
"PVE backup: rename incremental to use-dirty-bitmap" merged two
variables (use_dirty_bitmap and incremental) into one, but they served
two different purposes. Rename the original use_dirty_bitmap to
"expect_only_dirty" so the new one doesn't conflict, and rework "PVE:
use proxmox_backup_check_incremental" around that semantic.
In practice, this had the effect that only one disk at a time would
have a bitmap added, as after the first "use_dirty_bitmap" would be set
to one and the rest would behave as if the QMP parameter of the same
name was unset.
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
* rename "incremental" param to "use-dirty-bitmap", avoids confusion
as the backup can be incrementally also with that param set to
false.
* use new proxmox_backup_check_incremental
* fix setting dirty counter and adapt to new connect API semantic
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
backup: improve QAPI info and remove all dirty-bitmaps on failed drive-job
effectively two commits merged as one:
https://pve.proxmox.com/pipermail/pve-devel/2020-July/044185.html
https://pve.proxmox.com/pipermail/pve-devel/2020-July/044194.html
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Thomas Lamprecht [Sat, 30 May 2020 13:24:11 +0000 (15:24 +0200)]
small cleanups for pbs-restore
Add trailing newline to two error messages, and drop an extra
unconditional `qdict_put_str(options, "driver", format);`
Besides that it's just formatting.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
experimentally move savevm-async back into a coroutine
Move qemu_savevm_state_{header,setup} into the main loop and
the rest of the iteration into a coroutine. The former need
to lock the iothread (and we can't unlock it in the
coroutine), and the latter can't deal with being in a
separate thread, so a coroutine it must be.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Oguz Bektas [Thu, 6 Feb 2020 14:25:49 +0000 (15:25 +0100)]
security patches for libslirp CVE-2020-8608
original commits and email can be found here[0]
A out-of-bounds heap buffer access issue was found in the SLiRP
networking implementation of the QEMU emulator. It occurs in tcp_emu()
routine while emulating IRC and other protocols due to unsafe usage of
snprintf(3) function.
A user/process could use this flaw to crash the Qemu process on the host
resulting in DoS or potentially execute arbitrary code with privileges
of the QEMU process on the host.
[0]: https://seclists.org/oss-sec/2020/q1/64
Signed-off-by: Oguz Bektas <o.bektas@proxmox.com> Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Oguz Bektas [Thu, 5 Mar 2020 12:29:13 +0000 (13:29 +0100)]
add patch for CVE-2019-20382 (vnc disconnect memory leak)
oss-security email can be found here[0]
upstream commit here[1]
this effects our vncproxy. dominik and me tested if the issue is present
on our branch and it appears that it is.
in essence when we disconnect from a vnc connection, the memory isn't
free'd afterwards which causes the qemu process to use more and more
memory with each disconnect, which could lead to a dos scenario.
we tested the patch and it seems to mitigate the problem.
projects / pve-qemu.git / log