Re: [Qemu-block] [Qemu-devel] [PATCH 2/2] qemu-img: fix some spelling errors

On Mon, Apr 24, 2017 at 11:53 PM, Eric Blake wrote: > On 04/24/2017 10:47 AM, Eric Blake wrote: >> On 04/24/2017 10:37 AM, Philippe Mathieu-Daudé wrote: >> > /* > - * Returns true iff the first sector pointed to by 'buf' contains at > least > - * a non-NUL

Re: [Qemu-block] [Qemu-devel] [PATCH 1/2] qemu-img: make sure contain the consecutive number of zero bytes

On Mon, Apr 24, 2017 at 10:43 PM, Eric Blake wrote: > On 04/23/2017 09:33 AM, jemmy858...@gmail.com wrote: >> From: Lidong Chen >> >> is_allocated_sectors_min don't guarantee to contain the >> consecutive number of zero bytes. this patch fixes this bug.

Re: [Qemu-block] [PATCH 17/17] block: Make bdrv_is_allocated_above() byte-based

On 04/24/2017 06:06 PM, John Snow wrote: > > > On 04/11/2017 06:29 PM, Eric Blake wrote: >> We are gradually moving away from sector-based interfaces, towards >> byte-based. In the common case, allocation is unlikely to ever use >> values that are not naturally sector-aligned, but it is

Re: [Qemu-block] [PATCH 17/17] block: Make bdrv_is_allocated_above() byte-based

On 04/11/2017 06:29 PM, Eric Blake wrote: > We are gradually moving away from sector-based interfaces, towards > byte-based. In the common case, allocation is unlikely to ever use > values that are not naturally sector-aligned, but it is possible > that byte-based values will let us be more

Re: [Qemu-block] [Qemu-stable] [PATCH v2 1/1] qemu-img: wait for convert coroutines to complete

On 24/04/2017 21:16, Peter Lieven wrote: Am 24.04.2017 um 18:27 schrieb Anton Nefedov : On 04/21/2017 03:37 PM, Peter Lieven wrote: Am 21.04.2017 um 14:19 schrieb Anton Nefedov: On 04/21/2017 01:44 PM, Peter Lieven wrote: Am 21.04.2017 um 12:04 schrieb Anton

[Qemu-block] [PULL v2 12/12] qemu-iotests: _cleanup_qemu must be called on exit

For the tests that use the common.qemu functions for running a QEMU process, _cleanup_qemu must be called in the exit function. If it is not, if the qemu process aborts, then not all of the droppings are cleaned up (e.g. pidfile, fifos). This updates those tests that did not have a cleanup in

[Qemu-block] [PULL v2 10/12] block/rbd - update variable names to more apt names

Update 'clientname' to be 'user', which tracks better with both the QAPI and rados variable naming. Update 'name' to be 'image_name', as it indicates the rbd image. Naming it 'image' would have been ideal, but we are using that for the rados_image_t value returned by rbd_open(). Reviewed-by:

[Qemu-block] [PULL v2 11/12] block/rbd: Add support for reopen()

This adds support for reopen in rbd, for changing between r/w and r/o. Note, that this is only a flag change, but we will block a change from r/o to r/w if we are using an RBD internal snapshot. Reviewed-by: Stefan Hajnoczi Signed-off-by: Jeff Cody

[Qemu-block] [PULL v2 09/12] block: use bdrv_can_set_read_only() during reopen

Signed-off-by: Jeff Cody Reviewed-by: Stefan Hajnoczi Reviewed-by: John Snow Message-id: 00aed7ffdd7be4b9ed9ce1007d50028a72b34ebe.1491597120.git.jc...@redhat.com --- block.c | 14 -- 1 file changed, 8 insertions(+), 6

[Qemu-block] [PULL v2 06/12] block: honor BDRV_O_ALLOW_RDWR when clearing bs->read_only

The BDRV_O_ALLOW_RDWR flag allows / prohibits the changing of the BDS 'read_only' state, but there are a few places where it is ignored. In the bdrv_set_read_only() helper, make sure to honor the flag. Signed-off-by: Jeff Cody Reviewed-by: Stefan Hajnoczi

[Qemu-block] [PULL v2 03/12] qemu-iotests: exclude vxhs from image creation via protocol

The protocol VXHS does not support image creation. Some tests expect to be able to create images through the protocol. Exclude VXHS from these tests. Signed-off-by: Jeff Cody --- tests/qemu-iotests/017 | 1 + tests/qemu-iotests/020 | 1 + tests/qemu-iotests/029 | 1 +

[Qemu-block] [PULL v2 01/12] block/vxhs.c: Add support for a new block device type called "vxhs"

From: Ashish Mittal Source code for the qnio library that this code loads can be downloaded from: https://github.com/VeritasHyperScale/libqnio.git Sample command line using JSON syntax: ./x86_64-softmmu/qemu-system-x86_64 -name instance-0008 -S -vnc 0.0.0.0:0 -k en-us

[Qemu-block] [PULL v2 05/12] block: do not set BDS read_only if copy_on_read enabled

A few block drivers will set the BDS read_only flag from their .bdrv_open() function. This means the bs->read_only flag could be set after we enable copy_on_read, as the BDRV_O_COPY_ON_READ flag check occurs prior to the call to bdrv->bdrv_open(). This adds an error return to

[Qemu-block] [PULL v2 07/12] block: code movement

Move bdrv_is_read_only() up with its friends. Reviewed-by: Stefan Hajnoczi Reviewed-by: John Snow Signed-off-by: Jeff Cody Message-id: 73b2399459760c32506f9407efb9dddb3a2789de.1491597120.git.jc...@redhat.com --- block.c | 10 +-

[Qemu-block] [PULL v2 08/12] block: introduce bdrv_can_set_read_only()

Introduce check function for setting read_only flags. Will return < 0 on error, with appropriate Error value set. Does not alter any flags. Signed-off-by: Jeff Cody Reviewed-by: Stefan Hajnoczi Reviewed-by: John Snow Message-id:

[Qemu-block] [PULL v2 04/12] block: add bdrv_set_read_only() helper function

We have a helper wrapper for checking for the BDS read_only flag, add a helper wrapper to set the read_only flag as well. Reviewed-by: Stefan Hajnoczi Signed-off-by: Jeff Cody Reviewed-by: John Snow Message-id:

[Qemu-block] [PULL v2 00/12] Block patches

The following changes since commit 4c55b1d0bad8a703f0499fe62e3761a0cd288da3: Merge remote-tracking branch 'remotes/armbru/tags/pull-error-2017-04-24' into staging (2017-04-24 14:49:48 +0100) are available in the git repository at: git://github.com/codyprime/qemu-kvm-jtc.git

[Qemu-block] [PULL v2 02/12] block/vxhs.c: Add qemu-iotests for new block device type "vxhs"

From: Ashish Mittal These changes use a vxhs test server that is a part of the following repository: https://github.com/VeritasHyperScale/libqnio.git Signed-off-by: Ashish Mittal Reviewed-by: Stefan Hajnoczi Reviewed-by:

Re: [Qemu-block] [Qemu-stable] [PATCH v2 1/1] qemu-img: wait for convert coroutines to complete

> Am 24.04.2017 um 18:27 schrieb Anton Nefedov : > >> On 04/21/2017 03:37 PM, Peter Lieven wrote: >>> Am 21.04.2017 um 14:19 schrieb Anton Nefedov: On 04/21/2017 01:44 PM, Peter Lieven wrote: > Am 21.04.2017 um 12:04 schrieb Anton Nefedov: > On error

Re: [Qemu-block] [PATCH v5 13/18] qcow2: add support for LUKS encryption format

On Tue, Feb 21, 2017 at 03:13:03PM +0100, Alberto Garcia wrote: > On Tue 21 Feb 2017 12:55:07 PM CET, Daniel P. Berrange wrote: > > static int qcow2_set_up_encryption(BlockDriverState *bs, QemuOpts *opts, > > - Error **errp) > > +

Re: [Qemu-block] [PATCH v5 11/18] qcow2: convert QCow2 to use QCryptoBlock for encryption

On Tue, Feb 21, 2017 at 02:30:10PM +0100, Alberto Garcia wrote: > On Tue 21 Feb 2017 12:55:05 PM CET, Daniel P. Berrange wrote: > > +switch (s->crypt_method_header) { > > +case QCOW_CRYPT_NONE: > > +break; > > + > > +case QCOW_CRYPT_AES: > > +r->crypto_opts =

Re: [Qemu-block] [PATCH v5 09/18] qcow: convert QCow to use QCryptoBlock for encryption

On Tue, Feb 21, 2017 at 02:19:46PM +0100, Alberto Garcia wrote: > On Tue 21 Feb 2017 12:55:03 PM CET, Daniel P. Berrange wrote: > > @@ -175,8 +185,31 @@ static int qcow_open(BlockDriverState *bs, QDict > > *options, int flags, > > ret = -ENOSYS; > > goto fail; > >

Re: [Qemu-block] [PATCH v2 1/1] qemu-img: wait for convert coroutines to complete

On 04/21/2017 03:37 PM, Peter Lieven wrote: Am 21.04.2017 um 14:19 schrieb Anton Nefedov: On 04/21/2017 01:44 PM, Peter Lieven wrote: Am 21.04.2017 um 12:04 schrieb Anton Nefedov: On error path (like i/o error in one of the coroutines), it's required to - wait for coroutines completion

Re: [Qemu-block] [PATCH V2] qemu-img: simplify img_convert

Am 21.04.2017 um 11:11 hat Peter Lieven geschrieben: > img_convert has been around before there was an ImgConvertState or > a block backend, but it has never been modified to directly use > these structs. Change this by parsing parameters directly into > the ImgConvertState and directly use

Re: [Qemu-block] [Qemu-devel] [PATCH 2/2] qemu-img: fix some spelling errors

On 04/24/2017 10:47 AM, Eric Blake wrote: > On 04/24/2017 10:37 AM, Philippe Mathieu-Daudé wrote: > /* - * Returns true iff the first sector pointed to by 'buf' contains at least - * a non-NUL byte. + * Returns true if the first sector pointed to by 'buf' contains at

Re: [Qemu-block] [Qemu-devel] [PATCH 2/2] qemu-img: fix some spelling errors

On 04/24/2017 10:37 AM, Philippe Mathieu-Daudé wrote: >>> /* >>> - * Returns true iff the first sector pointed to by 'buf' contains at >>> least >>> - * a non-NUL byte. >>> + * Returns true if the first sector pointed to by 'buf' contains at >>> least >>> + * a non-NULL byte. >> >> NACK to both

Re: [Qemu-block] [Qemu-devel] [PATCH 2/2] qemu-img: fix some spelling errors

Hi Eric, On 04/24/2017 11:40 AM, Eric Blake wrote: On 04/23/2017 09:33 AM, jemmy858...@gmail.com wrote: From: Lidong Chen Fix some spelling errors in is_allocated_sectors comment. Signed-off-by: Lidong Chen --- qemu-img.c | 4 ++-- 1 file

Re: [Qemu-block] [Qemu-devel] [PATCH 1/2] qemu-img: make sure contain the consecutive number of zero bytes

On 04/23/2017 09:33 AM, jemmy858...@gmail.com wrote: > From: Lidong Chen > > is_allocated_sectors_min don't guarantee to contain the > consecutive number of zero bytes. this patch fixes this bug. This message was sent without an 'In-Reply-To' header pointing to a 0/2

Re: [Qemu-block] [Qemu-devel] [PATCH 2/2] qemu-img: fix some spelling errors

On 04/23/2017 09:33 AM, jemmy858...@gmail.com wrote: > From: Lidong Chen > > Fix some spelling errors in is_allocated_sectors comment. > > Signed-off-by: Lidong Chen > --- > qemu-img.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-)

Re: [Qemu-block] [PATCH] migration/block: optimize the performance by coalescing the same write type

the reason of MIN_CLUSTER_SIZE is 8192 is base on the performance test result. the performance is only reduce obviously when cluster_size is less than 8192. I write this code, run in guest os. to create the worst condition. #include #include #include int main() { char *zero; char

[Qemu-block] [PATCH] migration/block: optimize the performance by coalescing the same write type

From: Lidong Chen This patch optimizes the performance by coalescing the same write type. When the zero/non-zero state changes, perform the write for the accumulated cluster count. Signed-off-by: Lidong Chen --- Thanks Fam Zheng and Stefan's

Re: [Qemu-block] [PATCH v14 19/20] file-posix: Add image locking in perm operations

Am 21.04.2017 um 05:56 hat Fam Zheng geschrieben: > virtlockd in libvirt locks the first byte, so we start looking at the > file bytes from 0x10. > > The complication is in the transactional interface. To make the reopen > logic managable, and allow better reuse, the code is internally >

Re: [Qemu-block] [PATCH v2] qemu-img: use blk_co_pwrite_zeroes for zero sectors when compressed

Hi Everyone: Any suggestion about this patch? Thanks. On Sun, Apr 23, 2017 at 5:53 PM, 858585 jemmy wrote: > I test four test case for this patch. > 1.qcow2 image with lots of zero cluster, and convert with compress > 2.qcow2 image with lots of zero cluster, and

Re: [Qemu-block] proposed qcow2 extension: cluster reservations [was: [Qemu-devel] [RFC] Proposed qcow2 extension: subcluster allocation

On Sat 22 Apr 2017 07:56:57 PM CEST, Max Reitz wrote: >> So, if you got this far in reading, the question becomes whether >> having a mode where you can mark a cluster as >> mapping-reserved-but-unallocated has enough use case to be worth >> pursuing, knowing that it will burn an incompatible

Re: [Qemu-block] [Qemu-devel] [PATCH v6] migration/block: use blk_pwrite_zeroes for each zero cluster

On Mon, Apr 24, 2017 at 8:36 PM, Fam Zheng wrote: > On Mon, 04/24 20:26, 858585 jemmy wrote: >> > 2) qcow2 with cluster_size = 512 is probably too uncommon to be optimized >> > for. >> if culster_size is very small, should disable metadata check default? >> > > No, I don't think

Re: [Qemu-block] [Qemu-devel] [PATCH v6] migration/block: use blk_pwrite_zeroes for each zero cluster

On Mon, 04/24 20:26, 858585 jemmy wrote: > > 2) qcow2 with cluster_size = 512 is probably too uncommon to be optimized > > for. > if culster_size is very small, should disable metadata check default? > No, I don't think it's worth the inconsistent behavior. People who want performance shouldn't

Re: [Qemu-block] [Qemu-devel] [PATCH v6] migration/block: use blk_pwrite_zeroes for each zero cluster

On Mon, Apr 24, 2017 at 8:19 PM, Fam Zheng wrote: > On Mon, 04/24 20:09, Fam Zheng wrote: >> It's a separate problem. > > To be specific: > > 1) there is an option "overlap-check" that one can use to > disable the costly metadata check; yes, i will disable metadata check, and

Re: [Qemu-block] [Qemu-devel] [PATCH v6] migration/block: use blk_pwrite_zeroes for each zero cluster

On Mon, Apr 24, 2017 at 8:09 PM, Fam Zheng wrote: > On Mon, 04/24 19:54, 858585 jemmy wrote: >> On Mon, Apr 24, 2017 at 3:40 PM, 858585 jemmy wrote: >> > On Mon, Apr 17, 2017 at 12:00 PM, 858585 jemmy >> > wrote: >> >> On Mon, Apr

Re: [Qemu-block] [Qemu-devel] [PATCH v6] migration/block: use blk_pwrite_zeroes for each zero cluster

On Mon, 04/24 19:54, 858585 jemmy wrote: > On Mon, Apr 24, 2017 at 3:40 PM, 858585 jemmy wrote: > > On Mon, Apr 17, 2017 at 12:00 PM, 858585 jemmy > > wrote: > >> On Mon, Apr 17, 2017 at 11:49 AM, Fam Zheng wrote: > >>> On Fri,

Re: [Qemu-block] [Qemu-devel] [PATCH v6] migration/block: use blk_pwrite_zeroes for each zero cluster

On Mon, Apr 24, 2017 at 3:40 PM, 858585 jemmy wrote: > On Mon, Apr 17, 2017 at 12:00 PM, 858585 jemmy wrote: >> On Mon, Apr 17, 2017 at 11:49 AM, Fam Zheng wrote: >>> On Fri, 04/14 14:30, 858585 jemmy wrote: Do you know some

Re: [Qemu-block] proposed qcow2 extension: cluster reservations [was: [Qemu-devel] [RFC] Proposed qcow2 extension: subcluster allocation

Am 22.04.2017 um 19:56 hat Max Reitz geschrieben: > On 21.04.2017 23:09, Eric Blake wrote: > > And meanwhile, it looks like I have some patches to propose (and > > qemu-iotests to write) if I can help fix the bugs I've pointed out. > > You mean these? >

Re: [Qemu-block] [PATCH v14 04/20] qemu-img: Add --share-rw option to subcommands

On Mon, 04/24 12:13, Kevin Wolf wrote: > Am 24.04.2017 um 08:10 hat Fam Zheng geschrieben: > > On Fri, 04/21 15:25, Kevin Wolf wrote: > > > Am 21.04.2017 um 05:55 hat Fam Zheng geschrieben: > > > > Similar to share-rw qdev property, this will force the opened images to > > > > allow shared write

Re: [Qemu-block] [PATCH v14 04/20] qemu-img: Add --share-rw option to subcommands

Am 24.04.2017 um 08:10 hat Fam Zheng geschrieben: > On Fri, 04/21 15:25, Kevin Wolf wrote: > > Am 21.04.2017 um 05:55 hat Fam Zheng geschrieben: > > > Similar to share-rw qdev property, this will force the opened images to > > > allow shared write permission of other programs. > > > > > >

Re: [Qemu-block] [PATCH v5 0/4] Improve convert and dd commands

On Mon, 04/24 10:16, Daniel P. Berrange wrote: > Update to > > v1: https://lists.gnu.org/archive/html/qemu-devel/2017-01/msg05699.html > v2: https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg00728.html > v3: https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg04391.html > >

Re: [Qemu-block] [PATCH v5 4/4] qemu-img: copy *key-secret opts when opening newly created files

On Mon, 04/24 10:16, Daniel P. Berrange wrote: > The qemu-img dd/convert commands will create a image file and s/a image/an image/ > then try to open it. Historically it has been possible to open > new files without passing any options. With encrypted files > though, the *key-secret options are

Re: [Qemu-block] [PATCH v5 3/4] qemu-img: introduce --target-image-opts for 'convert' command

On Mon, Apr 24, 2017 at 05:45:12PM +0800, Fam Zheng wrote: > On Mon, 04/24 10:16, Daniel P. Berrange wrote: > > The '--image-opts' flags indicates whether the source filename > > s/flags/flag/ or s/indicates/indicate/, I think? Yes to the first, no to the second > > includes options. The target

Re: [Qemu-block] [PATCH v5 3/4] qemu-img: introduce --target-image-opts for 'convert' command

On Mon, 04/24 10:16, Daniel P. Berrange wrote: > The '--image-opts' flags indicates whether the source filename s/flags/flag/ or s/indicates/indicate/, I think? > includes options. The target filename has to remain in the > plain filename format though, since it needs to be passed to >

[Qemu-block] [PATCH v5 4/4] qemu-img: copy *key-secret opts when opening newly created files

The qemu-img dd/convert commands will create a image file and then try to open it. Historically it has been possible to open new files without passing any options. With encrypted files though, the *key-secret options are mandatory, so we need to provide those options when opening the newly created

[Qemu-block] [PATCH v5 2/4] qemu-img: fix --image-opts usage with dd command

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 opts. Reviewed-by: Max Reitz

[Qemu-block] [PATCH v5 3/4] qemu-img: introduce --target-image-opts for 'convert' command

The '--image-opts' flags 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 possible to use image-opts syntax. This adds

[Qemu-block] [PATCH v5 0/4] Improve convert and dd commands

Update to v1: https://lists.gnu.org/archive/html/qemu-devel/2017-01/msg05699.html v2: https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg00728.html v3: https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg04391.html This series is in response to Max pointing out that you cannot

[Qemu-block] [PATCH v5 1/4] qemu-img: add support for --object with 'dd' command

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: Max Reitz Reviewed-by: Eric Blake Signed-off-by: Daniel P.

Re: [Qemu-block] [Qemu-devel] [QEMU-2.8] Source QEMU crashes with: "bdrv_co_pwritev: Assertion `!(bs->open_flags & BDRV_O_INACTIVE)' failed"

On Sat, Apr 22, 2017 at 05:23:49PM +0800, Hailiang Zhang wrote: > Hi, Hi Hailiang, > I think the bellow patch can fix your problme. > [PATCH 2/4] qmp-cont: invalidate on RUN_STATE_PRELAUNCH > https://patchwork.kernel.org/patch/9591885/ Hmm, the above patch ("qmp-cont: invalidate on

Re: [Qemu-block] [Qemu-devel] [PATCH v6] migration/block: use blk_pwrite_zeroes for each zero cluster

On Mon, Apr 17, 2017 at 12:00 PM, 858585 jemmy wrote: > On Mon, Apr 17, 2017 at 11:49 AM, Fam Zheng wrote: >> On Fri, 04/14 14:30, 858585 jemmy wrote: >>> Do you know some other format which have very small cluster size? >> >> 64k is the default cluster

Re: [Qemu-block] [PATCH v14 07/20] iotests: 030: Prepare for image locking

On Fri, 04/21 15:51, Kevin Wolf wrote: > Am 21.04.2017 um 05:55 hat Fam Zheng geschrieben: > > qemu-img and qemu-io commands when guest is running need "-U" option, > > add it. > > > > Signed-off-by: Fam Zheng > > --- > > tests/qemu-iotests/030 | 24 > >

Re: [Qemu-block] [PATCH v14 04/20] qemu-img: Add --share-rw option to subcommands

On Fri, 04/21 15:25, Kevin Wolf wrote: > Am 21.04.2017 um 05:55 hat Fam Zheng geschrieben: > > Similar to share-rw qdev property, this will force the opened images to > > allow shared write permission of other programs. > > > > Signed-off-by: Fam Zheng > > General observation: