Thomas Huth writes:
> We likely do not want to carry these legacy -drive options along forever.
> Let's emit a deprecation warning for the -drive options that have a
> replacement with the -device option, so that the (hopefully few) remaining
> users are aware of this and can
Observe the following ('qmp-shell', for brevity) invocation of the four
major types (stream, commit, mirror, backup) of live block operations:
(QEMU) block-stream device=node-D base=a.qcow2 job-id=job-block-stream
(QEMU) block-commit device=node-D base=a.qcow2 top=b.qcow2
On 2017-05-03 14:25, Vladimir Sementsov-Ogievskiy wrote:
> It will be needed in following commits for persistent bitmaps.
> If bitmap is loaded from read-only storage (and we can't mark it
> "in use" in this storage) corresponding BdrvDirtyBitmap should be
> read-only.
>
> Signed-off-by: Vladimir
On 2017-05-03 14:25, Vladimir Sementsov-Ogievskiy wrote:
> We should release them here to reload on invalidate cache.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> block.c | 4
> block/dirty-bitmap.c | 29
On 2017-05-03 14:25, Vladimir Sementsov-Ogievskiy wrote:
> Remove persistent bitmap from the storage on block-dirty-bitmap-remove.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> Reviewed-by: Max Reitz
> Reviewed-by: John Snow
>
On 2017-05-03 14:25, Vladimir Sementsov-Ogievskiy wrote:
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> tests/qemu-iotests/165 | 105
> +
> tests/qemu-iotests/165.out | 5 +++
> tests/qemu-iotests/group | 1 +
On 2017-05-03 14:25, Vladimir Sementsov-Ogievskiy wrote:
> Store persistent dirty bitmaps in qcow2 image.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> block/qcow2-bitmap.c | 475
> +++
> block/qcow2.c|
On 2017-05-03 14:25, Vladimir Sementsov-Ogievskiy wrote:
> New field BdrvDirtyBitmap.persistent means, that bitmap should be saved
> by format driver in .bdrv_close and .bdrv_inactivate. No format driver
> supports it for now.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
On 2017-05-03 14:25, Vladimir Sementsov-Ogievskiy wrote:
> Release bitmaps after 'if (bs->drv) { ... }' block. This will allow
> format driver to save persistent bitmaps, which will appear in following
> commits.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
>
On 2017-05-03 14:25, Vladimir Sementsov-Ogievskiy wrote:
> Auto loading bitmaps are bitmaps in Qcow2, with the AUTO flag set. They
> are loaded when the image is opened and become BdrvDirtyBitmaps for the
> corresponding drive.
>
> Extra data in bitmaps is not supported for now.
>
>
On 12.05.2017 12:33, Thomas Huth wrote:
> We likely do not want to carry these legacy -drive options along forever.
> Let's emit a deprecation warning for the -drive options that have a
> replacement with the -device option, so that the (hopefully few) remaining
> users are aware of this and can
On 2017-05-29 17:55, Eric Blake wrote:
> On 05/29/2017 10:46 AM, Max Reitz wrote:
>
>>> If you switch all of these to $(realpath -- "$(type -p "$QEMU_...")"),
>>> you can add:
>>
>> I'd love to, but this is what type -p outputs for me:
>>
>> $ type -p qemu-img
>> qemu-img is /usr/bin/qemu-img
>
On 05/29/2017 10:46 AM, Max Reitz wrote:
>> If you switch all of these to $(realpath -- "$(type -p "$QEMU_...")"),
>> you can add:
>
> I'd love to, but this is what type -p outputs for me:
>
> $ type -p qemu-img
> qemu-img is /usr/bin/qemu-img
Huh? That's plain 'type' output. Are you sure
On 2017-05-03 14:25, Vladimir Sementsov-Ogievskiy wrote:
> It will be needed in following commits for persistent bitmaps.
> If bitmap is loaded from read-only storage (and we can't mark it
> "in use" in this storage) corresponding BdrvDirtyBitmap should be
> read-only.
>
> Signed-off-by: Vladimir
On 2017-05-29 17:42, Eric Blake wrote:
> On 05/29/2017 10:23 AM, Max Reitz wrote:
>> A user may specify a relative path for accessing qemu, qemu-img, etc.
>> through environment variables ($QEMU_PROG and friends) or a symlink.
>>
>> If a test decides to change its working directory, relative paths
On 05/29/2017 10:23 AM, Max Reitz wrote:
> A user may specify a relative path for accessing qemu, qemu-img, etc.
> through environment variables ($QEMU_PROG and friends) or a symlink.
>
> If a test decides to change its working directory, relative paths will
> cease to work, however. Work around
On 2017-05-03 14:25, Vladimir Sementsov-Ogievskiy wrote:
> Add bitmap extension as specified in docs/specs/qcow2.txt.
> For now, just mirror extension header into Qcow2 state and check
> constraints. Also, calculate refcounts for qcow2 bitmaps, to not break
> qemu-img check.
>
> For now, disable
Reviewed-by: Eric Blake
Signed-off-by: Max Reitz
---
tests/qemu-iotests/126 | 105 +
tests/qemu-iotests/126.out | 23 ++
tests/qemu-iotests/group | 1 +
3 files changed, 129 insertions(+)
create
A user may specify a relative path for accessing qemu, qemu-img, etc.
through environment variables ($QEMU_PROG and friends) or a symlink.
If a test decides to change its working directory, relative paths will
cease to work, however. Work around this by making all of the paths to
programs that
This is a v3 for "block: Fix backing paths for filenames with colons".
Kevin reported that the test added there does not work if the test
programs are specified with relative paths (because the new test changes
its working directory), so we/I dropped the test from the queue and here
it is again.
From: Max Reitz
path_combine() naturally tries to preserve a protocol prefix. However,
it recognizes such a prefix by scanning for the first colon; which is
different from what path_has_protocol() does: There only is a protocol
prefix if there is a colon before the first
From: Max Reitz
The file drivers' *_parse_filename() implementations just strip the
optional protocol prefix off the filename. However, for e.g.
"file:foo:bar", this would lead to "foo:bar" being stored as the BDS's
filename which looks like it should be managed using the
From: "Daniel P. Berrange"
The '--image-opts' flag indicates whether the source filename
includes options. The target filename has to remain in the
plain filename format though, since it needs to be passed to
bdrv_create(). When using --skip-create though, it would be
From: Fam Zheng
Reported by Coverity.
Signed-off-by: Fam Zheng
Message-id: 20170515141014.25793-1-f...@redhat.com
Reviewed-by: Eric Blake
Signed-off-by: Max Reitz
---
qemu-img.c | 1 +
1 file changed, 1 insertion(+)
From: Eric Blake
When converting a 1.1 image down to 0.10, qemu-iotests 060 forces
a contrived failure where allocating a cluster used to replace a
zero cluster reads unaligned data. Since it is a zero cluster
rather than a data cluster being converted, changing the error
From: "Daniel P. Berrange"
The --image-opts flag can only be used to affect the parsing
of the source image. The target image has to be specified in
the traditional style regardless, since it needs to be passed
to the bdrv_create() API which does not support the new style
From: "Daniel P. Berrange"
The qemu-img dd command added --image-opts support, but missed
the corresponding --object support. This prevented passing
secrets (eg auth passwords) needed by certain disk images.
Reviewed-by: Fam Zheng
Reviewed-by: Max Reitz
From: Fam Zheng
It got lost in commit a8d16f9ca "qemu-img: Update documentation for -U".
Reported-by: Max Reitz
Signed-off-by: Fam Zheng
Message-id: 20170515103551.31313-1-f...@redhat.com
Reviewed-by: Eric Blake
From: Alberto Garcia
Commit d7086422b1c1e75e320519cfe26176db6ec97a37 added a local_err
variable global to the qcow2_amend_options() function, so there's no
need to have this other one.
Signed-off-by: Alberto Garcia
Message-id:
From: Fam Zheng
This is the case in our docker tests, as we use --net=none there. Skip
this method.
Signed-off-by: Fam Zheng
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/147 | 7 +++
1 file changed, 7 insertions(+)
diff --git
This fixes an assertion failure that was triggered by qemu-iotests 129
on some CI host, while the same test case didn't seem to fail on other
hosts.
Essentially the problem is that the blk_unref(s->target) in
mirror_exit() doesn't necessarily mean that the BlockBackend goes away
immediately. It
From: Stephen Bates
Implement NVMe Controller Memory Buffers (CMBs) which were added in
version 1.2 of the NVMe Specification. This patch adds an optional
argument (cmb_size_mb) which indicates the size of the CMB (in
MB). Currently only the Submission Queue Support (SQS) is
From: Alberto Garcia
The code that tries to reopen a BlockDriverState in stream_start()
when the creation of a new block job fails crashes because it attempts
to dereference a pointer that is known to be NULL.
This is a regression introduced in
The following changes since commit 9964e96dccf7f7c936ee854a795415d19b60:
Merge remote-tracking branch 'jasowang/tags/net-pull-request' into staging
(2017-05-23 15:01:31 +0100)
are available in the git repository at:
git://repo.or.cz/qemu/kevin.git tags/for-upstream
for you to fetch
This adds a small test for the image streaming error path for failing
block_job_create(), which would have found the null pointer dereference
in commit a170a91f.
Signed-off-by: Kevin Wolf
Reviewed-by: Alberto Garcia
Reviewed-by: Kashyap Chamarthy
On Thu 25 May 2017 06:32:16 PM CEST, Paolo Bonzini wrote:
> Another possibility is to use tg->lock, which we're holding anyway in
> both schedule_next_request and throttle_group_co_io_limits_intercept.
> This would require open-coding the CoQueue however, so I've chosen this
> alternative.
>
>
On Thu 25 May 2017 06:38:51 PM CEST, "Daniel P. Berrange"
wrote:
> Expand the image format docs to cover the new options for
> the qcow, qcow2 and luks disk image formats
>
> Signed-off-by: Daniel P. Berrange
Reviewed-by: Alberto Garcia
On Thu 25 May 2017 06:38:48 PM CEST, "Daniel P. Berrange"
wrote:
> Now that all encryption keys must be provided upfront via
> the QCryptoSecret API and associated block driver properties
> there is no need for any explicit encryption handling APIs
> in the block layer.
On 2017-05-29 14:18, Kevin Wolf wrote:
> This fixes an assertion failure that was triggered by qemu-iotests 129
> on some CI host, while the same test case didn't seem to fail on other
> hosts.
>
> Essentially the problem is that the blk_unref(s->target) in
> mirror_exit() doesn't necessarily
On 29/05/2017 14:18, Kevin Wolf wrote:
> This fixes an assertion failure that was triggered by qemu-iotests 129
> on some CI host, while the same test case didn't seem to fail on other
> hosts.
>
> Essentially the problem is that the blk_unref(s->target) in
> mirror_exit() doesn't necessarily
On 05/26/2017 10:04 PM, Eric Blake wrote:
> If a non-NBD client connects to qemu-nbd, we would end up with
> a SIGSEGV in nbd_cilent_put() because we were trying to
> unregister the client's association to the export, even though
> we skipped inserting the client into that list. Easy trigger
> in
This fixes an assertion failure that was triggered by qemu-iotests 129
on some CI host, while the same test case didn't seem to fail on other
hosts.
Essentially the problem is that the blk_unref(s->target) in
mirror_exit() doesn't necessarily mean that the BlockBackend goes away
immediately. It
On 26/05/2017 22:21, Kevin Wolf wrote:
> The qed block driver is one of the last remaining block drivers that use the
> AIO callback style interfaces. This series converts it to the coroutine model
> that other drivers are using and removes some AIO functions from the block
> layer API afterwards.
"Daniel P. Berrange" writes:
> On Thu, May 25, 2017 at 02:52:30PM -0500, Eric Blake wrote:
>> On 05/25/2017 11:38 AM, Daniel P. Berrange wrote:
>> > Currently 'qemu-img info' reports a simple "encrypted: yes"
>> > field. This is not very useful now that qcow2 can support
>>
44 matches
Mail list logo