Otherwise the string gets included in the QEMU binary, not the library.
Suggested-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
but accept old variant as well for now, to not invalidate bitmaps for
freshly migrated VMs.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
...so we can get the library version a binary is currently running with.
Version information is retrieved from the build environment (set by
cargo/make) and appended using 'with_after_include' to appear within the
include guard.
The version string in current-api.h is inconsequential, so ignore it in
diff. This way we only have to re-commit that file whenever the *actual*
API changes, not the version.
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
modified to avoid spawning subcommands
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
For dirty-bitmap migration, QEMU also needs to move the static state of
the library to the target. proxmox_{import,export}_state provide a means
of accessing said data in a serialized fashion.
QEMU treats the state as some unknown quantity of bytes and the result
does not need to be human-readable, so we encode it with 'bincode',
which is based on serde.
Since the quantity is only known *after* serialization, we have to
allocate the buffer ourselves. This is handled by Box::leak-ing a Rust
allocated buffer and cleaning up via the explicit
proxmox_free_state_buf function.
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
by computing and remembering the ID digest of a static string, we can
detect when the passed in key has changed without keeping a copy of it
around inbetween backup jobs.
this is a follow-up/fixup for
104fae9111fix#2866: invalidate bitmap on crypt_mode change
which implemented detection for crypt MODE changes.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
clippy complains that a `Mutex<Bool>` could just as well be
an `AtomicBool`, but we also use a `Condvar`, so it cannot.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
clippy suggests a way-too-long
for (i, index) in index.iter_mut().enumerate().take(index_count) {
*index = ...
}
which is just massive in comparison, and not at all more
readable...
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
signed and plain backups share chunks, so bitmap reusal is okay for
those combinations. switching from encrypted to not encrypted or
vice-versa could have pretty fatal consequences - either referencing
plain-text chunks in 'encrypted' backups, or referencing encrypted
chunks in 'unencrypted' backups without still having the corresponding
keys..
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
since we're about to introduce a third duplicate of this line..
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
in preparation for adding more checks to check_incremental
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
QEMU will always assume EOF when less bytes than requested are returned
by a block drivers 'read' interface, so we need to fill the buffer up to
'size' if possible.
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
Replaces the removed BufferedFixedReader and makes the API fully async
(not block_in_place or block_on which could break with many requests at
once).
A tokio::sync::Mutex needs to be used for exclusive access, since a
regular one would not work with async/await calls.
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
This is not a fatal condition, it just means that we cannot do
incremental backups client-side. This can happen if a new disk was added
the a VM since the last backup for example.
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
