In-place sparsify support in VDSM

From my point of view, it is better to remove the old code and start with
Hi! There is an RFE being implemented currently ( https://bugzilla.redhat.com/show_bug.cgi?id=734120) to use --inplace option in virt-sparsify to sparsify a disk image in-place, without copying it. The problem is that in-place sparsify works on NFS only starting from NFS 4.2, while the copying implementation supposedly works with any storage. the new code that uses --inplace and just add to document that one will need NFS >= 4.2 for sparsify feature to work. Although the old implementation exists, it is not used currently so there are no actual users that may be affected by the change. If it will be a crying need to use sparsify on older NFS or some other incompatible storage, we can add it later on the base of the new code. The old code is far from ideal and we will need to rewrite it in any case, and there is not sense to do this without real need. What do you think? Shmuel

On Tue, May 17, 2016 at 7:14 PM, Shmuel Melamud <smelamud@redhat.com> wrote:
Hi!
There is an RFE being implemented currently ( https://bugzilla.redhat.com/show_bug.cgi?id=734120) to use --inplace option in virt-sparsify to sparsify a disk image in-place, without copying it.
The problem is that in-place sparsify works on NFS only starting from NFS 4.2, while the copying implementation supposedly works with any storage.
From my point of view, it is better to remove the old code and start with the new code that uses --inplace and just add to document that one will need NFS >= 4.2 for sparsify feature to work. Although the old implementation exists, it is not used currently so there are no actual users that may be affected by the change. If it will be a crying need to use sparsify on older NFS or some other incompatible storage, we can add it later on the base of the new code. The old code is far from ideal and we will need to rewrite it in any case, and there is not sense to do this without real need.
Richard, Currently vdsm is using: virt-sparsify --tmp prebuilt:tmp_vol --format src_format --convert dst_format src_vol dst_vol (--format and --dst_format are optional) tmp_vol, src_vol, and dst_vol can be either file on nfs/glusterfs/other posix shared filesystem, or an lv created on top of lun (iscsi/fc). can you confirm this method works on all the storage types I mentioned? or this depends on the underlying storage server? The new inplace method is much nicer, but something that works only on latest NFS version is not useful for our most important users, using block storage. Nir

On Tue, May 17, 2016 at 09:50:07PM +0300, Nir Soffer wrote:
On Tue, May 17, 2016 at 7:14 PM, Shmuel Melamud <smelamud@redhat.com> wrote:
Hi!
There is an RFE being implemented currently ( https://bugzilla.redhat.com/show_bug.cgi?id=734120) to use --inplace option in virt-sparsify to sparsify a disk image in-place, without copying it.
The problem is that in-place sparsify works on NFS only starting from NFS 4.2, while the copying implementation supposedly works with any storage.
From my point of view, it is better to remove the old code and start with the new code that uses --inplace and just add to document that one will need NFS >= 4.2 for sparsify feature to work. Although the old implementation exists, it is not used currently so there are no actual users that may be affected by the change. If it will be a crying need to use sparsify on older NFS or some other incompatible storage, we can add it later on the base of the new code. The old code is far from ideal and we will need to rewrite it in any case, and there is not sense to do this without real need.
Richard,
Currently vdsm is using:
virt-sparsify --tmp prebuilt:tmp_vol --format src_format --convert dst_format src_vol dst_vol
(--format and --dst_format are optional)
tmp_vol, src_vol, and dst_vol can be either file on nfs/glusterfs/other posix shared filesystem, or an lv created on top of lun (iscsi/fc).
can you confirm this method works on all the storage types I mentioned? or this depends on the underlying storage server?
Copying mode requires that the dst_vol supports sparseness. The most common case where this would *not* be true is partitions on local hard disks. You can't make a partition and/or local hard disk sparse. However all of the ones you've mentioned above support sparseness, so you should be good. *If* you were using --inplace only, you could nuke the --tmp option, and indeed all the code associated with "prebuilt" qcow2 files for scratch space. That's because --inplace mode uses hardly any temporary storage, so you can just have it use regular /var/tmp or $TMPDIR. However ...
The new inplace method is much nicer, but something that works only on latest NFS version is not useful for our most important users, using block storage.
... it's a shame, but yes. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v

On Tue, May 17, 2016 at 10:00 PM, Richard W.M. Jones <rjones@redhat.com> wrote:
On Tue, May 17, 2016 at 09:50:07PM +0300, Nir Soffer wrote:
On Tue, May 17, 2016 at 7:14 PM, Shmuel Melamud <smelamud@redhat.com> wrote:
Hi!
There is an RFE being implemented currently ( https://bugzilla.redhat.com/show_bug.cgi?id=734120) to use --inplace option in virt-sparsify to sparsify a disk image in-place, without copying it.
The problem is that in-place sparsify works on NFS only starting from NFS 4.2, while the copying implementation supposedly works with any storage.
From my point of view, it is better to remove the old code and start with the new code that uses --inplace and just add to document that one will need NFS >= 4.2 for sparsify feature to work. Although the old implementation exists, it is not used currently so there are no actual users that may be affected by the change. If it will be a crying need to use sparsify on older NFS or some other incompatible storage, we can add it later on the base of the new code. The old code is far from ideal and we will need to rewrite it in any case, and there is not sense to do this without real need.
Richard,
Currently vdsm is using:
virt-sparsify --tmp prebuilt:tmp_vol --format src_format --convert dst_format src_vol dst_vol
(--format and --dst_format are optional)
tmp_vol, src_vol, and dst_vol can be either file on nfs/glusterfs/other posix shared filesystem, or an lv created on top of lun (iscsi/fc).
can you confirm this method works on all the storage types I mentioned? or this depends on the underlying storage server?
Copying mode requires that the dst_vol supports sparseness. The most common case where this would *not* be true is partitions on local hard disks. You can't make a partition and/or local hard disk sparse.
However all of the ones you've mentioned above support sparseness, so you should be good.
*If* you were using --inplace only, you could nuke the --tmp option, and indeed all the code associated with "prebuilt" qcow2 files for scratch space.
That's because --inplace mode uses hardly any temporary storage, so you can just have it use regular /var/tmp or $TMPDIR.
However ...
The new inplace method is much nicer, but something that works only on latest NFS version is not useful for our most important users, using block storage.
... it's a shame, but yes.
Rich.
Thanks Richard! So we have existing code supporting al storage types, and can benefit our most important users. We can use the new much simpler method if a user is using NFS 4.2 but it is not a replacement. So I would keep the current implementation in vdsm, and add a new much simpler implementation for inplace sparsify. We should implement the missing part on the engine side, managing the entire flow. Thoughts? Nir

I was working on this piece of code today: https://github.com/libguestfs/libguestfs/blob/3fb35e66272ab675bb335a7ae1b6c0... which reminded me of this email thread. The above function in libguestfs encodes which versions of qemu and which block drivers in qemu have discard support. Unfortunately it doesn't encode the NFS knowledge nor the local drive/partition business, because it's rather hard to detect those. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org
participants (3)
-
Nir Soffer
-
Richard W.M. Jones
-
Shmuel Melamud