On 04/14/2016 09:23 AM, Fam Zheng wrote:
On Thu, 04/14 09:14, Denis V. Lunev wrote:
On 04/14/2016 08:46 AM, Fam Zheng wrote:
On Thu, 04/14 08:04, Denis V. Lunev wrote:
unfortunately no. If the lock will be on the image file,
we will have get it on the target node on QEMU start
and re-acquire i
On Thu, 04/14 09:14, Denis V. Lunev wrote:
> On 04/14/2016 08:46 AM, Fam Zheng wrote:
> >On Thu, 04/14 08:04, Denis V. Lunev wrote:
> >>unfortunately no. If the lock will be on the image file,
> >>we will have get it on the target node on QEMU start
> >>and re-acquire it in bdrv_invalidate_cache.
>
On Thu, 04/14 08:04, Denis V. Lunev wrote:
> unfortunately no. If the lock will be on the image file,
> we will have get it on the target node on QEMU start
> and re-acquire it in bdrv_invalidate_cache.
>
> From my POW you should not get the lock if
> BDRV_O_INACTIVE is set.
That is what I meant.
On 04/13/2016 12:17 PM, Daniel P. Berrange wrote:
> The iSCSI block driver has a very strange approach whereby it
> does not accept options directly as part of the -drive arg,
> but instead takes them indirectly from a -iscsi arg. To make
> up -driver and -iscsi args, it takes the iSCSI target na
On 04/14/2016 05:36 AM, Fam Zheng wrote:
On Wed, 04/13 13:18, Denis V. Lunev wrote:
On 04/13/2016 12:09 PM, Fam Zheng wrote:
Too many troubles have been caused by two processes writing to the same image
unexpectedly. This series introduces automatical image locking into QEMU to
avoid such trage
On 04/13/2016 09:02 PM, Stefan Hajnoczi wrote:
On Mon, Apr 11, 2016 at 04:22:58PM +0800, Changlong Xie wrote:
+static coroutine_fn int replication_co_writev(BlockDriverState *bs,
+ int64_t sector_num,
+ int
On Wed, 04/13 13:18, Denis V. Lunev wrote:
> On 04/13/2016 12:09 PM, Fam Zheng wrote:
> >Too many troubles have been caused by two processes writing to the same image
> >unexpectedly. This series introduces automatical image locking into QEMU to
> >avoid such tragedy. With this, the user won't be a
On Wed, 04/13 10:19, Daniel P. Berrange wrote:
> On Wed, Apr 13, 2016 at 05:09:49PM +0800, Fam Zheng wrote:
> > Too many troubles have been caused by two processes writing to the same
> > image
> > unexpectedly. This series introduces automatical image locking into QEMU to
> > avoid such tragedy.
On Wed, 04/13 10:21, Daniel P. Berrange wrote:
> On Wed, Apr 13, 2016 at 05:09:54PM +0800, Fam Zheng wrote:
> > Because virtlockd in libvirt already uses the fcntl lock on the image file,
> > we
> > have to workaround this by locking a digest-mapped temporary file.
> >
> > Signed-off-by: Fam Zhen
On 04/13/2016 08:47 PM, Stefan Hajnoczi wrote:
On Mon, Apr 11, 2016 at 04:22:57PM +0800, Changlong Xie wrote:
+/*
+ * The caller of the function MUST make sure vm stopped
+ */
+void replication_start_all(ReplicationMode mode, Error **errp)
+{
+ReplicationState *rs, *next;
+
+QLIST_FOREAC
Am 23.03.2016 um 04:33 hat Jeff Cody geschrieben:
> Fixes for a regression in vpc_create(), as well as a few issues with VHD
> format
> compatibility.
Thanks, applied to the block brannch.
Kevin
Am 23.03.2016 um 04:33 hat Jeff Cody geschrieben:
> Signed-off-by: Jeff Cody
> ---
> block/vpc.c | 70
> ++---
> 1 file changed, 35 insertions(+), 35 deletions(-)
>
> diff --git a/block/vpc.c b/block/vpc.c
> index 5dd9950..0b48cf4 100644
>
Am 13.04.2016 um 17:40 hat Jeff Cody geschrieben:
> On Tue, Mar 22, 2016 at 11:33:38PM -0400, Jeff Cody wrote:
> > Commit 'b8f45cdf7827e39f9a1e6cc446f5972cc6144237' switched VPC
> > over to using blk_pwrite() instead of bdrv_pwrite_sync(). The
> > return value of bdrv_pwrite_sync() was always 0 fo
The iSCSI block driver has a very strange approach whereby it
does not accept options directly as part of the -drive arg,
but instead takes them indirectly from a -iscsi arg. To make
up -driver and -iscsi args, it takes the iSCSI target name
and uses that as an ID value for the -iscsi arg lookup.
On Wednesday 13 April 2016 15:18:20 Daniel P. Berrange wrote:
> The iSCSI block driver has a very strange approach whereby it
> does not accept options directly as part of the -drive arg,
> but instead takes them indirectly from a -iscsi arg. To make
> up -driver and -iscsi args, it takes the iSCSI
On Tue, Mar 22, 2016 at 11:33:38PM -0400, Jeff Cody wrote:
> Commit 'b8f45cdf7827e39f9a1e6cc446f5972cc6144237' switched VPC
> over to using blk_pwrite() instead of bdrv_pwrite_sync(). The
> return value of bdrv_pwrite_sync() was always 0 for success, and
> create_dynamic_disk() in one instance che
On 12 April 2016 at 17:18, Kevin Wolf wrote:
> The following changes since commit 42bb626f7ebc9197d2943b897a99e127315275ab:
>
> Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request'
> into staging (2016-04-12 09:34:52 +0100)
>
> are available in the git repository at:
>
>
>
On Tue, Apr 12, 2016 at 04:57:42PM +0200, Pino Toscano wrote:
> Hi,
>
> to overcome the limitations of the options handling [1], I'm planning
> to move more options for iSCSI also as block options, so it is possible
> to specify them with -drive.
>
> The only patch in this series is for initiator
The iSCSI block driver has a very strange approach whereby it
does not accept options directly as part of the -drive arg,
but instead takes them indirectly from a -iscsi arg. To make
up -driver and -iscsi args, it takes the iSCSI target name
and uses that as an ID value for the -iscsi arg lookup.
Signed-off-by: Ren Kimura
---
qemu-img.c | 27 ---
1 file changed, 24 insertions(+), 3 deletions(-)
diff --git a/qemu-img.c b/qemu-img.c
index 06264d9..53471a1 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -1451,6 +1451,21 @@ static void convert_select_part(ImgConvertState
When converting images, check the block status of it's backing file chain to
avoid needlessly reading zeros.
Am 29.02.2016 um 21:08 hat Jeff Cody geschrieben:
> From: Fam Zheng
>
> The "pnum < nb_sectors" condition in deciding whether to actually copy
> data is unnecessarily strict, and the qiov initialization is
> unnecessarily for bdrv_aio_write_zeroes and bdrv_aio_discard.
>
> Rewrite mirror_iterati
On Mon, Apr 11, 2016 at 04:22:58PM +0800, Changlong Xie wrote:
> +static coroutine_fn int replication_co_writev(BlockDriverState *bs,
> + int64_t sector_num,
> + int remaining_sectors,
> +
On Mon, Apr 11, 2016 at 04:22:57PM +0800, Changlong Xie wrote:
> +/*
> + * The caller of the function MUST make sure vm stopped
> + */
> +void replication_start_all(ReplicationMode mode, Error **errp)
> +{
> +ReplicationState *rs, *next;
> +
> +QLIST_FOREACH_SAFE(rs, &replication_states, no
Commit 57d6a428 broke blk_aio_write_zeroes() because in some write
functions in the call path don't have an explicit length argument but
reuse qiov->size instead. Which is great, except that write_zeroes
doesn't have a qiov, which this commit interprets as 0 bytes.
Consequently, blk_aio_write_zeroe
Kevin Wolf (2):
qemu-io: Support 'aio_write -z'
block: Fix blk_aio_write_zeroes()
block/block-backend.c | 20 +++
qemu-io-cmds.c | 64 +++-
tests/qemu-iotests/033 | 8 +++--
tests/qemu-iotests/033.out | 82 +
This allows testing blk_aio_write_zeroes().
Signed-off-by: Kevin Wolf
---
qemu-io-cmds.c | 64 +++---
1 file changed, 48 insertions(+), 16 deletions(-)
diff --git a/qemu-io-cmds.c b/qemu-io-cmds.c
index 382faa8..51ae5a5 100644
--- a/qemu-io-cm
On 04/13/2016 12:09 PM, Fam Zheng wrote:
Too many troubles have been caused by two processes writing to the same image
unexpectedly. This series introduces automatical image locking into QEMU to
avoid such tragedy. With this, the user won't be able to open the image from
two processes (e.g. using
On Wed, Apr 13, 2016 at 05:09:54PM +0800, Fam Zheng wrote:
> Because virtlockd in libvirt already uses the fcntl lock on the image file, we
> have to workaround this by locking a digest-mapped temporary file.
>
> Signed-off-by: Fam Zheng
> ---
> block/raw-posix.c | 97
>
The VM is running, qemu-io would fail the lock acquisition.
Signed-off-by: Fam Zheng
---
tests/qemu-iotests/030 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/qemu-iotests/030 b/tests/qemu-iotests/030
index 3ac2443..fa996ef 100755
--- a/tests/qemu-iotests/030
+++ b/tes
On Wed, Apr 13, 2016 at 05:09:49PM +0800, Fam Zheng wrote:
> Too many troubles have been caused by two processes writing to the same image
> unexpectedly. This series introduces automatical image locking into QEMU to
> avoid such tragedy. With this, the user won't be able to open the image from
> t
If a failure in a previous test case doesn't clean up the running qemu process
(it happens), the subsequent ones can fail because of a image locking failure.
That is not an authentic failure of the test case itself and could be sometimes
confusing. Disable image locking to avoid that.
Signed-off-
So the image lock won't complain.
Signed-off-by: Fam Zheng
---
tests/qemu-iotests/046 | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/tests/qemu-iotests/046 b/tests/qemu-iotests/046
index e0be46c..40c4bc0 100755
--- a/tests/qemu-iotests/046
+++ b/test
Now that test cases are covered, we can turn it on.
Signed-off-by: Fam Zheng
---
blockdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/blockdev.c b/blockdev.c
index 93bd43e..87d22c3 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -383,7 +383,7 @@ static void extract_common_b
The case is the temporary image is sometimes used by more than one QEMU
processes, just use the nop lock to avoid image locking failures.
Signed-off-by: Fam Zheng
---
tests/ahci-test.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/tests/ahci-test.c b/tests
Signed-off-by: Fam Zheng
---
tests/qemu-iotests/051| 2 +-
tests/qemu-iotests/051.out| 10 +-
tests/qemu-iotests/051.pc.out | 10 +-
3 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/tests/qemu-iotests/051 b/tests/qemu-iotests/051
index 88b3d91..2fee7e8
Because virtlockd in libvirt already uses the fcntl lock on the image file, we
have to workaround this by locking a digest-mapped temporary file.
Signed-off-by: Fam Zheng
---
block/raw-posix.c | 97 +++
1 file changed, 97 insertions(+)
diff --
The VM is still on, the image locking check would complain.
Signed-off-by: Fam Zheng
---
tests/qemu-iotests/140 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/qemu-iotests/140 b/tests/qemu-iotests/140
index 05e4506..412b26f 100755
--- a/tests/qemu-iotests/140
+++ b/tes
Because the source and the destination QEMU instances both open the
image, we have to disable the lock.
Signed-off-by: Fam Zheng
---
tests/qemu-iotests/091 | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/qemu-iotests/091 b/tests/qemu-iotests/091
index 32bbd56..2a3c9
Signed-off-by: Fam Zheng
---
block/gluster.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/block/gluster.c b/block/gluster.c
index 51e154c..e76ec87 100644
--- a/block/gluster.c
+++ b/block/gluster.c
@@ -672,6 +672,36 @@ static void qemu_gluster_close(Bloc
Honor the locking switch specified in CLI or QMP, and set the open flags for
the image accordingly.
Signed-off-by: Fam Zheng
---
blockdev.c | 8
1 file changed, 8 insertions(+)
diff --git a/blockdev.c b/blockdev.c
index f1f520a..93bd43e 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -382,
To allow overriding the default locking behavior when opening the image.
Signed-off-by: Fam Zheng
---
qapi/block-core.json | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/qapi/block-core.json b/qapi/block-core.json
index 1d09079..2913f3e 100644
--- a/qapi/block-core.json
Block drivers can implement this new operation .bdrv_lockf to actually lock the
image in the protocol specific way.
Signed-off-by: Fam Zheng
---
block.c | 25 +
include/block/block.h | 8
include/block/block_int.h | 5 +
3 files change
Signed-off-by: Fam Zheng
---
qemu-io.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/qemu-io.c b/qemu-io.c
index 288bba8..6bb6232 100644
--- a/qemu-io.c
+++ b/qemu-io.c
@@ -107,6 +107,7 @@ static void open_help(void)
" -r, -- open file read-only\n"
Later the block layer will automatically lock the images to avoid unexpected
concurrent accesses to the same image, which will easily corrupt the metadata
or user data, unless in some very special cases, like migration.
The exceptional cases like shared storage migration and testing should set
BDR
Too many troubles have been caused by two processes writing to the same image
unexpectedly. This series introduces automatical image locking into QEMU to
avoid such tragedy. With this, the user won't be able to open the image from
two processes (e.g. using qemu-img when the image is attached to the
From: Wen Congyang
Signed-off-by: Wen Congyang
Signed-off-by: zhanghailiang
Signed-off-by: Gonglei
Signed-off-by: Changlong Xie
---
block.c | 8 +++---
block/quorum.c| 78 +--
include/block/block.h | 4 +++
3 files chang
From: Wen Congyang
The new QMP command name is x-blockdev-change. It's just for adding/removing
quorum's child now, and doesn't support all kinds of children, all kinds of
operations, nor all block drivers. So it is experimental now.
Signed-off-by: Wen Congyang
Signed-off-by: zhanghailiang
Sig
ChangLog:
v13:
1. Rebase to the newest codes
2. Address commets from Betro and Max
p1. Add R-B, fix incorrect syntax
p2. Add missing "qemu/cutils.h" since 2.6, and rewrite quorum_add/del_child
p3. Remove unnecessary "id", add "since 2.7"
v11~v12:
1. Address comments from Max
p1. Add R-B
p2. Add R-B
From: Wen Congyang
In some cases, we want to take a quorum child offline, and take
another child online.
Signed-off-by: Wen Congyang
Signed-off-by: zhanghailiang
Signed-off-by: Gonglei
Signed-off-by: Changlong Xie
Reviewed-by: Max Reitz
Reviewed-by: Alberto Garcia
---
block.c
50 matches
Mail list logo
