Description of problem: Currently when allocating a sparse volume on block based storage, it always allocates 1g on the storage and set the virtual size to the requested volume size. Now consider the following case: we convert a VM from external system with a 10g virtual size and 5g actual size and the user asks that the target disk will reside in block storage and be sparsed. So we have two options: 1. Keeping the initial allocating to be 1g and then to extend the volume as we write to it. Might be possible, much more complex. 2. To make the initial allocation size configurable so instead of allocating 1g, we will initially allocate the actual size of the disk so virt-v2v will be able to write the converted data to the volume. #2 seems to be much simpler, just adding a parameter for the initial allocation size to the Volume.create verb.
Just to get the terminology right - you want to create a QCow with an initial size of 10GB, right?
(In reply to Allon Mureinik from comment #1) > Just to get the terminology right - you want to create a QCow with an > initial size of 10GB, right? No, in the example above I want to create a QCow with an intial size of 5GB and that the disk will be marked somehow as one that can grow up to 10GB when the VM starts (with the watermark mechanism).
Talked to Arik f2f to clarify this. The requirement is to be able to define to properties for a volume - the virtual size and the initial allocation. (Note this will also be needed for the upload image feature) So, I can see two options here: 1. Add a parameter to createVolume (so you have virutalSize and initialSize instead of just size). Offhand, this doesn't seem to fit the SDM design. 2. Call createVolume and then allocate
Adding initial size to createVolumeContainer is nice, and is also useful for cloning disk structure when moving disks. I don't see any conflict with sdm design. This can also simplify internal flows in vdsm - instead of creating a volume and extending it immediately, just create it in the right size. Why perform 2 lvm operations when one does what you need?
This is a must-have capability for 3.6 for the integration with virt-v2v.
Yaniv, this requires changing the API, which I'm not sure we'd want to do at this point of time. Let's discuss?
(In reply to Allon Mureinik from comment #6) > Yaniv, this requires changing the API, which I'm not sure we'd want to do at > this point of time. The implication of not solving this issue is that customers that use block storage will not be able to set converted disks of VMs that are being imported from VMware to thin-provision. Allon, I think that if we go with the second solution (the one that Nir commented on in comment 4) we can add the initial capacity as default-parameter so the API will not break. But anyway, even doing it as we talked several months ago (by doing 2 operations in AddDiskCommand) will be ok. I think that since block storage and thin-provision is probably the most popular settings, not supporting this will prevent many from using this new feature.
(In reply to Arik from comment #7) > (In reply to Allon Mureinik from comment #6) > > Yaniv, this requires changing the API, which I'm not sure we'd want to do at > > this point of time. > > The implication of not solving this issue is that customers that use block > storage will not be able to set converted disks of VMs that are being > imported from VMware to thin-provision. > > Allon, I think that if we go with the second solution (the one that Nir > commented on in comment 4) we can add the initial capacity as > default-parameter so the API will not break. But anyway, even doing it as we > talked several months ago (by doing 2 operations in AddDiskCommand) will be > ok. I think that since block storage and thin-provision is probably the most > popular settings, not supporting this will prevent many from using this new > feature. sounds like this functionality is something we would definitely need for 3.6, Allon what would be the safest way you see to introduce the functionality?
(In reply to Moran Goldboim from comment #8) > (In reply to Arik from comment #7) > > (In reply to Allon Mureinik from comment #6) > > > Yaniv, this requires changing the API, which I'm not sure we'd want to do at > > > this point of time. > > > > The implication of not solving this issue is that customers that use block > > storage will not be able to set converted disks of VMs that are being > > imported from VMware to thin-provision. > > > > Allon, I think that if we go with the second solution (the one that Nir > > commented on in comment 4) we can add the initial capacity as > > default-parameter so the API will not break. But anyway, even doing it as we > > talked several months ago (by doing 2 operations in AddDiskCommand) will be > > ok. I think that since block storage and thin-provision is probably the most > > popular settings, not supporting this will prevent many from using this new > > feature. > > sounds like this functionality is something we would definitely need for > 3.6, Allon what would be the safest way you see to introduce the > functionality? The SAFEST? Not to introduce it. :-) Fred - let's see if we can introduce this (vdsm+engine) in a way that doesn't destabilize the rest of the system.
This is vdsm bug - the vdsm side is merged in ovirt-3.6 branch - this should be MODIFIED now. The engine patch should be tracked elsewhere.
created new bug for engine : https://bugzilla.redhat.com/show_bug.cgi?id=1273284
Hi Fred, It seems that the fix introduced for this bug might touch some major operations like disk creation and copy. Can you please provide us the flows that will have to be tested in order to make sure that we don't have regressions?
Hi, There should not be any changes in these flows, but you should make some sanity in these area. I would test disk creation on block storage with thin provisioning. Of course, also there is a need to test the V2V flow.
Currently there is no running v2v environment here in order to verify this issue. Will be tested as soon as we have one.
Following comments #14 and #15, Storage testing is down, Will be marked as verified once V2V will be tested. Nisim, can you please take care of this one?
I meant done :)
Sure
Verified: rhevm-3.6.1.3-0.1.el6 sanlock-3.2.4-1.el7.x86_64 libvirt-client-1.2.17-13.el7_2.2.x86_64 qemu-kvm-rhev-2.3.0-31.el7_2.4.x86_64 vdsm-4.17.13-1.el7ev.noarch VMware Version 6.0.0 Build 2594327 Verification scenario: 1. Create VMware VM with 16GB iSCSI disk (thin provision type). 2. Install RHEL7 OS on that VM. 3. Create 10G file (copy 10G from /dev/zero to a file). 3. Power off VMware VM and import it using RHEVM, select iSCSI storage domain as a destination disk). 4. After import completed, run both VMs and compare the next things between source VM and imported VM: Total disk size, virtual size, actual size, number of partitions, partitions size, available space on each partition and 10G files created. 5. Repeat test steps 1-4, this time use NFS storage domain as a destination disk.
RHEV 3.6.0 has been released, setting status to CLOSED CURRENTRELEASE