(VM) via Qemu-devel
Stefan Weil Stefan Weil via
+Andrey Drobyshev Andrey Drobyshev via
# Next, replace old addresses by a more recent one.
Aleksandar Markovic
--
2.41.0
In case when we're rebasing within one backing chain, and when target image
is larger than old backing file, bdrv_is_allocated_above() ends up setting
*pnum = 0. As a result, target offset isn't getting incremented, and we
get stuck in an infinite for loop. Let's detect this case and proceed
furt
When rebasing an image from one backing file to another, we need to
compare data from old and new backings. If the diff between that data
happens to be unaligned to the target cluster size, we might end up
doing partial writes, which would lead to copy-on-write and additional IO.
Consider the fol
The test cases considered so far:
314 (new test suite):
1. Check that compression mode isn't compatible with "-f raw" (raw
format doesn't support compression).
2. Check that rebasing an image onto no backing file preserves the data
and writes the copied clusters actually compressed.
3. Same
Add @chsize param to the function which, if non-zero, would represent
the chunk size to be used for comparison. If it's zero, then
BDRV_SECTOR_SIZE is used as default chunk size, which is the previous
behaviour.
In particular, we're going to use this param in img_rebase() to make the
write reques
Before previous commit, rebase was getting infitely stuck in case of
rebasing within the same backing chain and when overlay_size > backing_size.
Let's add this case to the rebasing test 024 to make sure it doesn't
break again.
Signed-off-by: Andrey Drobyshev
Reviewed-by: Denis V. Lunev
Reviewed
As the previous commit changes the logic of "qemu-img rebase" (it's using
write alignment now), let's add a couple more test cases which would
ensure it works correctly. In particular, the following scenarios:
024: add test case for rebase within one backing chain when the overlay
cluster si
v2 --> v3:
* Patch 3/8: fixed logic in the if statement, so that we align on blk
when blk_old_backing == NULL;
* Patch 4/8: comment fix;
* Patch 5/8: comment fix; dropped redundant "if (blk_new_backing)"
statements.
v2: https://lists.nongnu.org/archive/html/qemu-block/2023-09/msg00448.htm
Since commit bb1c05973cf ("qemu-img: Use qemu_blockalign"), buffers for
the data read from the old and new backing files are aligned using
BlockDriverState (or BlockBackend later on) referring to the target image.
However, this isn't quite right, because buf_new is only being used for
reading from
If we rebase an image whose backing file has compressed clusters, we
might end up wasting disk space since the copied clusters are now
uncompressed. In order to have better control over this, let's add
"--compress" option to the "qemu-img rebase" command.
Note that this option affects only the cl
v1 --> v2:
* Choose proper BlockBackend when aligning buf_old;
* Add new patch ("qemu-img: add chunk size parameter to
compare_buffers()");
* Rework write alignment logic; now writes are aligned to either
subcluster or cluster size, depending on whether compressionis enabled;
* Add new pa
When rebasing an image from one backing file to another, we need to
compare data from old and new backings. If the diff between that data
happens to be unaligned to the target cluster size, we might end up
doing partial writes, which would lead to copy-on-write and additional IO.
Consider the fol
The test cases considered so far:
314 (new test suite):
1. Check that compression mode isn't compatible with "-f raw" (raw
format doesn't support compression).
2. Check that rebasing an image onto no backing file preserves the data
and writes the copied clusters actually compressed.
3. Same
As the previous commit changes the logic of "qemu-img rebase" (it's using
write alignment now), let's add a couple more test cases which would
ensure it works correctly. In particular, the following scenarios:
024: add test case for rebase within one backing chain when the overlay
cluster si
In case when we're rebasing within one backing chain, and when target image
is larger than old backing file, bdrv_is_allocated_above() ends up setting
*pnum = 0. As a result, target offset isn't getting incremented, and we
get stuck in an infinite for loop. Let's detect this case and proceed
furt
Since commit bb1c05973cf ("qemu-img: Use qemu_blockalign"), buffers for
the data read from the old and new backing files are aligned using
BlockDriverState (or BlockBackend later on) referring to the target image.
However, this isn't quite right, because buf_new is only being used for
reading from
Add @chsize param to the function which, if non-zero, would represent
the chunk size to be used for comparison. If it's zero, then
BDRV_SECTOR_SIZE is used as default chunk size, which is the previous
behaviour.
In particular, we're going to use this param in img_rebase() to make the
write reques
If we rebase an image whose backing file has compressed clusters, we
might end up wasting disk space since the copied clusters are now
uncompressed. In order to have better control over this, let's add
"--compress" option to the "qemu-img rebase" command.
Note that this option affects only the cl
Before previous commit, rebase was getting infitely stuck in case of
rebasing within the same backing chain and when overlay_size > backing_size.
Let's add this case to the rebasing test 024 to make sure it doesn't
break again.
Signed-off-by: Andrey Drobyshev
Reviewed-by: Denis V. Lunev
Reviewed
In the previous commit e2f938265e0 ("tests/qemu-iotests/197: add
testcase for CoR with subclusters") we've introduced a new testcase for
copy-on-read with subclusters. Test 197 always forces qcow2 as the top
image, but allows backing image to be in any format. That last test
case didn't meet thes
Functions qcow2_get_host_offset(), get_cluster_offset(),
vmdk_co_block_status() explicitly report compressed cluster types when data
is compressed. However, this information is never passed further. Let's
make use of it by adding new BDRV_BLOCK_COMPRESSED flag for
bdrv_block_status(), so that cal
v2 --> v3:
* Make "compressed" field mandatory, not optional;
* Adjust field description in qapi/block-core.json;
* Squash patch 3 into patch 2 so that failing tests don't break bisect;
* Update even more tests' outputs now that the field is mandatory.
v2: https://lists.nongnu.org/archive/
v1 --> v2:
* Fixed line indentation;
* Fixed wording in a comment;
* Added R-b.
v1: https://lists.nongnu.org/archive/html/qemu-block/2023-06/msg00606.html
Andrey Drobyshev (3):
block: add subcluster_size field to BlockDriverInfo
block/io: align requests to subcluster_size
tests/qemu-iote
When target image is using subclusters, and we align the request during
copy-on-read, it makes sense to align to subcluster_size rather than
cluster_size. Otherwise we end up with unnecessary allocations.
This commit renames bdrv_round_to_clusters() to bdrv_round_to_subclusters()
and utilizes sub
This is going to be used in the subsequent commit as requests alignment
(in particular, during copy-on-read). This value only makes sense for
the formats which support subclusters (currently QCOW2 only). If this
field isn't set by driver's own bdrv_get_info() implementation, we
simply set it equa
Add testcase which checks that allocations during copy-on-read are
performed on the subcluster basis when subclusters are enabled in target
image.
This testcase also triggers the following assert with previous commit
not being applied, so we check that as well:
qemu-io: ../block/io.c:1236: bdrv_c
v1 --> v2:
* Add vmdk format to the 1st commit. Tweak commit message accordingly;
* Make "compressed" field in MapEntry optional.
v1: https://lists.nongnu.org/archive/html/qemu-block/2023-06/msg00184.html
Andrey Drobyshev (3):
block: add BDRV_BLOCK_COMPRESSED flag for bdrv_block_status()
The previous commit adds "compressed" boolean field to JSON output of
"qemu-img map" command. Let's tweak expected tests output accordingly.
Signed-off-by: Andrey Drobyshev
---
tests/qemu-iotests/122.out| 84
tests/qemu-iotests/154.out| 194
Functions qcow2_get_host_offset(), get_cluster_offset(),
vmdk_co_block_status() explicitly report compressed cluster types when data
is compressed. However, this information is never passed further. Let's
make use of it by adding new BDRV_BLOCK_COMPRESSED flag for
bdrv_block_status(), so that cal
Right now "qemu-img map" reports compressed blocks as containing data
but having no host offset. This is not very informative. Instead,
let's add another boolean field named "compressed" in case JSON output
mode is specified. This is achieved by utilizing new allocation status
flag BDRV_BLOCK_CO
Add testcase which checks that allocations during copy-on-read are
performed on the subcluster basis when subclusters are enabled in target
image.
This testcase also triggers the following assert with previous commit
not being applied, so we check that as well:
qemu-io: ../block/io.c:1236: bdrv_c
When target image is using subclusters, and we align the request during
copy-on-read, it makes sense to align to subcluster_size rather than
cluster_size. Otherwise we end up with unnecessary allocations.
This commit renames bdrv_round_to_clusters() to bdrv_round_to_subclusters()
and utilizes sub
This series makes IO requests performed with copy-on-read to be aligned
to subclusters rather than clusters. It also affects mirror job requests
alignment.
The initial reason for that change is the following crash discovered:
qemu-img create -f qcow2 base.qcow2 64K
qemu-img create -f qcow2 -o
e
This is going to be used in the subsequent commit as requests alignment
(in particular, during copy-on-read). This value only makes sense for
the formats which support subclusters (currently QCOW2 only). If this
field isn't set by driver's own bdrv_get_info() implementation, we
simply set it equa
The previous commit adds "compressed" boolean field to JSON output of
"qemu-img map" command. Let's tweak expected tests output accordingly.
Signed-off-by: Andrey Drobyshev
---
tests/qemu-iotests/122.out| 84
tests/qemu-iotests/154.out| 194
Functions qcow2_get_host_offset(), get_cluster_offset() explicitly
report compressed cluster types when data is compressed. However, this
information is never passed further. Let's make use of it by adding new
BDRV_BLOCK_COMPRESSED flag for bdrv_block_status(), so that caller may
know that the da
This series adds "compressed" field to the output of "qemu-img map"
command, specifying whether or not data block is compressed. Only
JSON output mode is affected. With this applied, output looks like so:
# qemu-img create -f qcow2 img.qcow2 192K
# qemu-io -c "write -c -P 0xaa 0 64K" img.qcow2
#
Right now "qemu-img map" reports compressed blocks as containing data
but having no host offset. This is not very informative. Instead,
let's add another boolean field named "compressed" in case JSON output
mode is specified. This is achieved by utilizing new allocation status
flag BDRV_BLOCK_CO
This series is adding [-c | --compress] option to "qemu-img rebase"
command, which might prove useful for saving some disk space when, for
instance, manipulating chains of backup images. Along the way I had to
make a couple of minor improvements.
The first 2 patches are a bug fix + corresponding
In case when we're rebasing within one backing chain, and when target image
is larger than old backing file, bdrv_is_allocated_above() ends up setting
*pnum = 0. As a result, target offset isn't getting incremented, and we
get stuck in an infinite for loop. Let's detect this case and proceed
furt
If we rebase an image whose backing file has compressed clusters, we
might end up wasting disk space since the copied clusters are now
uncompressed. In order to have better control over this, let's add
"--compress" option to the "qemu-img rebase" command.
Note that this option affects only the cl
When rebasing an image from one backing file to another, we need to
compare data from old and new backings. If the diff between that data
happens to be unaligned to the target cluster size, we might end up
doing partial writes, which would lead to copy-on-write and additional IO.
Consider the fol
The test cases considered so far:
1. Check that compression mode isn't compatible with "-f raw" (raw
format doesn't support compression).
2. Check that rebasing an image onto no backing file preserves the data
and writes the copied clusters actually compressed.
3. Same as 2, but with a raw b
Before previous commit, rebase was getting infitely stuck in case of
rebasing within the same backing chain and when overlay_size > backing_size.
Let's add this case to the rebasing test 024 to make sure it doesn't
break again.
Signed-off-by: Andrey Drobyshev
---
tests/qemu-iotests/024 | 57
Since commit bb1c05973cf ("qemu-img: Use qemu_blockalign"), buffers for
the data read from the old and new backing files are aligned using
BlockDriverState (or BlockBackend later on) referring to the target image.
However, this isn't quite right, because target image is only being
written to and ha
In case when we're rebasing within one backing chain, and when target image
is larger than old backing file, bdrv_is_allocated_above() ends up setting
*pnum = 0. As a result, target offset isn't getting incremented, and we
get stuck in an infinite for loop. Let's detect this case and proceed
furt
v1 -> v2:
* Avoid breaking the loop just yet, as the offsets beyond the old
backing size need to be explicitly zeroed;
* Amend the commit message accordingly;
* Alter the added test case to take the last zeroed cluster into
consideration.
v1: https://lists.nongnu.org/archive/html/qe
Before previous commit, rebase was getting infitely stuck in case of
rebasing within the same backing chain and when overlay_size > backing_size.
Let's add this case to the rebasing test 024 to make sure it doesn't
break again.
Signed-off-by: Andrey Drobyshev
---
tests/qemu-iotests/024 | 57
In case when we're rebasing within one backing chain, and when target image
is larger than old backing file, bdrv_is_allocated_above() ends up setting
*pnum = 0. As a result, target offset isn't getting incremented, and we
get stuck in an infinite for loop. Let's detect this case and break the
lo
Before previous commit, rebase was getting infitely stuck in case of
rebasing within the same backing chain and when overlay_size > backing_size.
Let's add this case to the rebasing test 024 to make sure it doesn't
break again.
Signed-off-by: Andrey Drobyshev
---
tests/qemu-iotests/024 | 48
Consider the following in-chain rebase case:
qemu-img create -f qcow2 base.qcow2 $(( 64 * 4 ))k
qemu-img create -f qcow2 -o backing_file=base.qcow2,backing_fmt=qcow2
inc1.qcow2 $(( 64 * 4 ))k
qemu-img create -f qcow2 -o backing_file=inc1.qcow2,backing_fmt=qcow2
inc2.qcow2 $(( 64 * 5 ))k
qemu-img
According to GLib changelog [1], since version 2.73.2 GLib is using
libpcre2 instead of libpcre. As a result, qemu-ga MSI installation
fails due to missing DLL when linked with the newer GLib.
This commit makes wixl to put the right libpcre version into the MSI
bundle: either libpcre-1.dll or lib
These patches extend QGA logging interface, primarily under Windows
guests. They enable QGA to write to Windows event log, much like
syslog() on *nix. In addition we get rid of hardcoded log level used by
ga_log().
v2:
* Close event_log handle when doing cleanup_agent()
* Fix switch cases indent
This patch translates GLib-specific log levels to system ones, so that
they may be used by both *nix syslog() (as a "priority" argument) and
Windows ReportEvent() (as a "wType" argument).
Currently the only codepath to write to "syslog" domain is slog()
function. However, this patch allows the in
This commit allows QGA to write to Windows event log using Win32 API's
ReportEvent() [1], much like syslog() under *nix guests.
In order to generate log message definitions we use a very basic message
text file [2], so that every QGA's message gets ID 1. The tools
"windmc" and "windres" respectiv
This commit allows QGA to write to Windows event log using Win32 API's
ReportEvent() [1], much like syslog() under *nix guests.
In order to generate log message definitions we use a very basic message
text file [2], so that every QGA's message gets ID 1. The tools
"windmc" and "windres" respectiv
This patch translates GLib-specific log levels to system ones, so that
they may be used by both *nix syslog() (as a "priority" argument) and
Windows ReportEvent() (as a "wType" argument).
Currently the only codepath to write to "syslog" domain is slog()
function. However, this patch allows the in
These patches extend QGA logging interface, primarily under Windows
guests. They enable QGA to write to Windows event log, much like
syslog() on *nix. In addition we get rid of hardcoded log level used by
ga_log().
Andrey Drobyshev (2):
qga-win: add logging to Windows event log
qga: map GLib
58 matches
Mail list logo
