Re: [Qemu-block] [Qemu-devel] storing machine data in qcow images?

On Mon, May 28, 2018 at 08:10:32PM +0200, Max Reitz wrote: > As someone who is just naive and doesn't see the big picture, I don't > see what's wrong with using a tar file that contains the image and > additional data. FWIW an OVA file is exactly this: an uncompressed tar file containing disk

Re: [Qemu-block] [Qemu-devel] storing machine data in qcow images?

Am 28.05.2018 um 20:30 hat Richard W.M. Jones geschrieben: > On Mon, May 28, 2018 at 08:10:32PM +0200, Max Reitz wrote: > > As someone who is just naive and doesn't see the big picture, I don't > > see what's wrong with using a tar file that contains the image and > > additional data. > > FWIW an

Re: [Qemu-block] [Qemu-devel] storing machine data in qcow images?

On 2018-05-28 20:38, Kevin Wolf wrote: > Am 28.05.2018 um 20:30 hat Richard W.M. Jones geschrieben: >> On Mon, May 28, 2018 at 08:10:32PM +0200, Max Reitz wrote: >>> As someone who is just naive and doesn't see the big picture, I don't >>> see what's wrong with using a tar file that contains the

Re: [Qemu-block] [Qemu-devel] storing machine data in qcow images?

On 2018-05-24 13:32, Richard W.M. Jones wrote: > I read the whole thread and the fundamental problem is that you're > mixing layers. Let qcow2 be a disk image format, and let management > layers deal with metadata and how to run qemu. > > What's going to happen when you have (eg) an OVA file

Re: [Qemu-block] [Qemu-devel] storing machine data in qcow images?

Am 28.05.2018 um 20:44 hat Max Reitz geschrieben: > On 2018-05-28 20:38, Kevin Wolf wrote: > > Am 28.05.2018 um 20:30 hat Richard W.M. Jones geschrieben: > >> On Mon, May 28, 2018 at 08:10:32PM +0200, Max Reitz wrote: > >>> As someone who is just naive and doesn't see the big picture, I don't >

Re: [Qemu-block] [Qemu-devel] storing machine data in qcow images?

On Mon, May 28, 2018 at 10:20:54PM +0100, Richard W.M. Jones wrote: > On Mon, May 28, 2018 at 08:38:33PM +0200, Kevin Wolf wrote: > > Just accessing the image file within a tar archive is possible and we > > could write a block driver for that (I actually think we should do > > this), but it

Re: [Qemu-block] [Qemu-devel] storing machine data in qcow images?

On Mon, May 28, 2018 at 08:38:33PM +0200, Kevin Wolf wrote: > Just accessing the image file within a tar archive is possible and we > could write a block driver for that (I actually think we should do > this), but it restricts you because certain operations like resizing > aren't really possible

[Qemu-block] [PATCH v4 12/21] hw: Do not include "sysemu/block-backend.h" if it is not necessary

Remove those unneeded includes to speed up the compilation process a little bit. (Continue 7eceff5b5a1fa cleanup) Signed-off-by: Philippe Mathieu-Daudé --- hw/arm/collie.c | 1 - hw/arm/gumstix.c | 1 - hw/arm/mainstone.c |

[Qemu-block] [PATCH v4 15/21] hw/block/nvme: Include "qemu/cutils.h" directly in the source file

Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Thomas Huth --- hw/block/nvme.h | 1 - hw/block/nvme.c | 1 + 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/block/nvme.h b/hw/block/nvme.h index 8f3981121d..cabcf20c32 100644 --- a/hw/block/nvme.h +++ b/hw/block/nvme.h @@ -1,6

[Qemu-block] [PATCH v4 14/21] hw: Do not include "sysemu/blockdev.h" if it is not necessary

Remove those unneeded includes to speed up the compilation process a little bit. Code change produced with: $ git grep '#include "sysemu/blockdev.h"' | \ cut -d: -f-1 | \ xargs egrep -L "(BlockInterfaceType|DriveInfo|drive_get|blk_legacy_dinfo|blockdev_mark_auto_del)" | \

[Qemu-block] [PATCH v4 11/21] hw: Do not include "exec/address-spaces.h" if it is not necessary

Code change produced with: $ git grep '#include "exec/address-spaces.h"' hw include/hw | \ cut -d: -f-1 | \ xargs egrep -L "(get_system_|address_space_)" | \ xargs sed -i.bak '/#include "exec\/address-spaces.h"/d' Signed-off-by: Philippe Mathieu-Daudé ---

[Qemu-block] [PATCH v4 20/21] hw/ide: Remove unused include

There is no need to include pci.h in this file. (Continue f23c81073a cleanup). Signed-off-by: Philippe Mathieu-Daudé --- hw/ide/core.c | 1 - 1 file changed, 1 deletion(-) diff --git a/hw/ide/core.c b/hw/ide/core.c index 866c659498..cc9ca28c33 100644 --- a/hw/ide/core.c +++ b/hw/ide/core.c @@

Re: [Qemu-block] [PATCH v4 15/21] hw/block/nvme: Include "qemu/cutils.h" directly in the source file

On 05/28/2018 08:27 PM, Philippe Mathieu-Daudé wrote: I forgot to add this commit description: "block/nvme.h" does not require any declaration of "qemu/cutils.h". Simplify dependencies by directly include it in the source file where the declarations are used. > Signed-off-by: Philippe

Re: [Qemu-block] [PATCH v6 04/10] qcow2: Implement copy offloading

On Mon, 05/28 11:36, Fam Zheng wrote: > The two callbacks are implemented quite similarly to the read/write > functions: bdrv_co_copy_range_from maps for read and calls into bs->file > or bs->backing depending on the allocation status; bdrv_co_copy_range_to > maps for write and calls into

Re: [Qemu-block] [ovirt-users] Re: Libvirt ERROR cannot access backing file after importing VM from OpenStack

Am 28.05.2018 um 16:06 hat Tomáš Golembiovský geschrieben: > > On Mon, 28 May 2018 13:37:59 +0200 > Kevin Wolf wrote: > > > Am 28.05.2018 um 12:27 hat Arik Hadas geschrieben: > > > On Mon, May 28, 2018 at 11:25 AM, Kevin Wolf wrote: > > > > > > > [ Adding

Re: [Qemu-block] [Qemu-devel] [PATCH 0/8] block: more byte-based cleanups: vectored I/O

Am 25.04.2018 um 20:32 hat Eric Blake geschrieben: > Based-on: <20180424192506.149089-1-ebl...@redhat.com> > ([PATCH v2 0/6] block: byte-based AIO read/write) > Based-on: <20180424220157.177385-1-ebl...@redhat.com> > ([PATCH] block: Merge .bdrv_co_writev{, _flags} in drivers) > > My quest

Re: [Qemu-block] [Qemu-devel] [PATCH 2/8] qcow: Switch get_cluster_offset to be byte-based

Am 25.04.2018 um 20:32 hat Eric Blake geschrieben: > We are gradually moving away from sector-based interfaces, towards > byte-based. Make the change for the internal helper function > get_cluster_offset(), by changing n_start and n_end to by byte > offsets rather than sector indices within the

Re: [Qemu-block] [Qemu-devel] [PATCH 3/8] qcow: Switch qcow_co_readv to byte-based calls

Am 25.04.2018 um 20:32 hat Eric Blake geschrieben: > We are gradually moving away from sector-based interfaces, towards > byte-based. Make the change for the internals of the qcow > driver read function, by iterating over offset/bytes instead of > sector_num/nb_sectors, and repurposing

Re: [Qemu-block] [Qemu-devel] [PATCH 4/8] qcow: Switch qcow_co_writev to byte-based calls

Am 25.04.2018 um 20:32 hat Eric Blake geschrieben: > We are gradually moving away from sector-based interfaces, towards > byte-based. Make the change for the internals of the qcow > driver write function, by iterating over offset/bytes instead of > sector_num/nb_sectors, and repurposing

Re: [Qemu-block] [ovirt-users] Libvirt ERROR cannot access backing file after importing VM from OpenStack

Am 28.05.2018 um 12:27 hat Arik Hadas geschrieben: > On Mon, May 28, 2018 at 11:25 AM, Kevin Wolf wrote: > > > [ Adding qemu-block ] > > > > Am 27.05.2018 um 10:36 hat Arik Hadas geschrieben: > > > On Thu, May 24, 2018 at 6:13 PM, Nir Soffer wrote: > > > >

Re: [Qemu-block] [PATCH 42/42] qemu-iotests: Test job-* with block jobs

On 2018-05-17 15:50, Kevin Wolf wrote: > Am 15.05.2018 um 01:44 hat Max Reitz geschrieben: >> On 2018-05-09 18:26, Kevin Wolf wrote: >>> This adds a test case that tests the new job-* QMP commands with >>> mirror and backup block jobs. >>> >>> Signed-off-by: Kevin Wolf >>> ---

Re: [Qemu-block] [libvirt-users] VM I/O performance drops dramatically during storage migration with drive-mirror

On Mon, May 28, 2018 at 02:05:05PM +0200, Kashyap Chamarthy wrote: > Cc the QEMU Block Layer mailing list (qemu-block@nongnu.org), [Sigh; now add the QEMU BLock Layer e-mail list to Cc, without typos.] > who might > have more insights here; and wrap long lines. > > On Mon, May 28, 2018 at

Re: [Qemu-block] [Qemu-devel] Some question about savem/qcow2 incremental snapshot

Hi yang, Alibaba made this proposal for NVDimm snapshot optimization, can you give some advice about this discussion? Thanks -Original Message- From: Stefan Hajnoczi [mailto:stefa...@gmail.com] Sent: Monday, May 14, 2018 9:49 PM To: Kevin Wolf Cc: Stefan Hajnoczi

Re: [Qemu-block] [libvirt-users] VM I/O performance drops dramatically during storage migration with drive-mirror

> -Original Messages- > From: "Kashyap Chamarthy" > Sent Time: 2018-05-28 21:19:14 (Monday) > To: "Chunguang Li" > Cc: libvirt-us...@redhat.com, qemu-block@nongnu.org, dgilb...@redhat.com > Subject: Re: [libvirt-users] VM I/O performance

Re: [Qemu-block] [Qemu-devel] [PULL 20/37] qcow2: Give the refcount cache the minimum possible size by default

On 28 May 2018 at 09:58, Alberto Garcia wrote: > On Mon 28 May 2018 10:38:55 AM CEST, Kevin Wolf wrote: >>> > +if (!refcount_cache_size_set) { >>> > +*refcount_cache_size = MIN_REFCOUNT_CACHE_SIZE * >>> > s->cluster_size; >>> >>> ...but in the else clause

Re: [Qemu-block] [ovirt-users] Libvirt ERROR cannot access backing file after importing VM from OpenStack

On Mon, May 28, 2018 at 11:25 AM, Kevin Wolf wrote: > [ Adding qemu-block ] > > Am 27.05.2018 um 10:36 hat Arik Hadas geschrieben: > > On Thu, May 24, 2018 at 6:13 PM, Nir Soffer wrote: > > > > > On Thu, May 24, 2018 at 6:06 PM Vrgotic, Marko < >

Re: [Qemu-block] [Qemu-devel] [PULL 20/37] qcow2: Give the refcount cache the minimum possible size by default

On Mon 28 May 2018 03:49:07 PM CEST, Peter Maydell wrote: > On 28 May 2018 at 09:58, Alberto Garcia wrote: >> On Mon 28 May 2018 10:38:55 AM CEST, Kevin Wolf wrote: > +if (!refcount_cache_size_set) { > +*refcount_cache_size = MIN_REFCOUNT_CACHE_SIZE

Re: [Qemu-block] [ovirt-users] Re: Libvirt ERROR cannot access backing file after importing VM from OpenStack

On Mon, 28 May 2018 13:37:59 +0200 Kevin Wolf wrote: > Am 28.05.2018 um 12:27 hat Arik Hadas geschrieben: > > On Mon, May 28, 2018 at 11:25 AM, Kevin Wolf wrote: > > > > > [ Adding qemu-block ] > > > > > > Am 27.05.2018 um 10:36 hat Arik Hadas

[Qemu-block] [PATCH] qcow2: Fix Coverity warning when calculating the refcount cache size

MIN_REFCOUNT_CACHE_SIZE is 4 and the cluster size is guaranteed to be at most 2MB, so the minimum refcount cache size (in bytes) is always going to fit in a 32-bit integer. Coverity doesn't know that, and since we're storing the result in a uint64_t (*refcount_cache_size) it thinks that we need

Re: [Qemu-block] [ovirt-users] Libvirt ERROR cannot access backing file after importing VM from OpenStack

[ Adding qemu-block ] Am 27.05.2018 um 10:36 hat Arik Hadas geschrieben: > On Thu, May 24, 2018 at 6:13 PM, Nir Soffer wrote: > > > On Thu, May 24, 2018 at 6:06 PM Vrgotic, Marko > > wrote: > > > >> Dear Nir, > >> > >> Thank you for quick reply. >

Re: [Qemu-block] [Qemu-devel] [PULL 20/37] qcow2: Give the refcount cache the minimum possible size by default

Am 25.05.2018 um 19:10 hat Peter Maydell geschrieben: > On 15 May 2018 at 16:40, Kevin Wolf wrote: > > From: Alberto Garcia > > > > The L2 and refcount caches have default sizes that can be overridden > > using the l2-cache-size and refcount-cache-size (an

Re: [Qemu-block] [PATCH 00/14] block: Make blockdev-create a job and stable API

Am 25.05.2018 um 20:13 hat Eric Blake geschrieben: > On 05/25/2018 11:33 AM, Kevin Wolf wrote: > > This changes the x-blockdev-create QMP command so that it doesn't block > > the monitor and the main loop any more, but starts a background job that > > performs the image creation. > > > > The

Re: [Qemu-block] [Qemu-devel] [PULL 20/37] qcow2: Give the refcount cache the minimum possible size by default

On Mon 28 May 2018 10:38:55 AM CEST, Kevin Wolf wrote: >> > +if (!refcount_cache_size_set) { >> > +*refcount_cache_size = MIN_REFCOUNT_CACHE_SIZE * >> > s->cluster_size; >> >> ...but in the else clause down here, we don't have the cast, and >> Coverity complains that we