ned-off-by: Wang Yong
Thanks, this patch fixs the problem in
http://lists.nongnu.org/archive/html/qemu-devel/2017-08/msg03358.html.
Reviewed-by: Xie Changlong
> ---
> block/replication.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/block
在 5/5/2017 12:52 AM, Kevin Wolf 写道:
+/* Returns whether the image file can be written to right now */
+bool bdrv_is_writable(BlockDriverState *bs)
+{
+return !bdrv_is_read_only(bs) && !(bs->open_flags & BDRV_O_INACTIVE);
+}
+
This commit use BDRV_O_INACTIVE to judge whether the image fil
在 8/10/2017 4:01 PM, Fam Zheng 写道:
People get surprised when, after "qemu-imc create -f raw /dev/sdX", they
s/qemu-imc/qemu-img/
still see qcow2 with "qemu-img info", if previously the bdev had a qcow2
--
Thanks
-Xie
在 8/10/2017 8:26 PM, Vladimir Sementsov-Ogievskiy 写道:
09.08.2017 17:11, Vladimir Sementsov-Ogievskiy wrote:
Hi Wen!
I'm trying to understand block/replication code and have a question.
Why should we block the region from intersecting cow requests when
read? If I understand correctly
regardl
o.c| 42 --
block/mirror.c| 5 -
block/replication.c | 17 -
For replication part:
Reviewed-by: Xie Changlong
block/stream.c| 21 +
qemu-img.c| 10 +++---
7 fi
---
include/block/block_backup.h | 11 +--
block/backup.c | 33 -
block/replication.c | 12
Reviewed-by: Xie Changlong
3 files changed, 29 insertions(+), 27 deletions(-)
diff --git a/include/block/block_backup.h b/include
在 6/19/2017 6:49 PM, Kevin Wolf 写道:
'info block' shows nothing, but we can't add drive who's id
is'drive-virtio-disk1' too.
Yes, the old BlockBackend is only fully freed when the guest actually
unplugs the device. Specifically, we would have to free the QemuOpts
in DriveInfo that keeps the ID re
在 6/19/2017 3:27 PM, Kevin Wolf 写道:
Am 18.06.2017 um 09:21 hat Xie Changlong geschrieben:
In device hot-remove scenario, if we don't probe acpiphp module on
the guest, 'device_del' will never emit DEVICE_DELETED event(because
guest will not write to __EJ0) . So we can confirm
Resend
在 6/18/2017 3:21 PM, Xie Changlong 写道:
Hi all
In device hot-remove scenario, if we don't probe acpiphp module on the
guest, 'device_del' will never emit DEVICE_DELETED event(because guest
will not write to __EJ0) . So we can confirm that hot-remove failed. But
IIUC, th
Hi all
In device hot-remove scenario, if we don't probe acpiphp module on the
guest, 'device_del' will never emit DEVICE_DELETED event(because guest
will not write to __EJ0) . So we can confirm that hot-remove failed. But
IIUC, there is no event such as DEVICE_ADDED, so
1) How can we confirm
On 04/12/2017 10:05 PM, zhanghailiang wrote:
We use these two options to identify which disk is
shared
Signed-off-by: zhanghailiang
Signed-off-by: Wen Congyang
Signed-off-by: Zhang Chen
---
v4:
- Add proper comment for primary_disk (Stefan)
v2:
- Move g_free(s->shared_disk_id) to the common
On 04/18/2017 09:36 AM, Hailiang Zhang wrote:
On 2017/4/18 9:23, Eric Blake wrote:
On 03/17/2017 08:15 AM, Kevin Wolf wrote:
From: Changlong Xie
Even if hidden_disk, secondary_disk are backing files, they all need
write permissions in replication scenario. Otherwise we will encouter
below e
12 matches
Mail list logo
