Bug 696050

Created attachment 491659 [details]
ovf file

Yuping,

I don't think RHEV is looking at actual disk usage vs file size when it fails this. My understanding is that it only looks at file size and the generated metadata. I've cloned this BZ to track the problem of the incorrect file allocation: bug 696089.

To make sure, can you do the above conversion again, and do the following after the conversion:

ls -l <image file>
fallocate -l <size from above> <image file>

This will ensure that the file is fully allocated, but won't make any other changes to it. Can you then try the RHEV import again, and report if it still fails?

1.# ls -l 462c8eba-6b85-44bf-9e32-0e43752c88c7
-rw-r--r-- 1 36 kvm 5369757696 Apr 13 03:44 462c8eba-6b85-44bf-9e32-0e43752c88c7

2.# fallocate -l 5369757696 462c8eba-6b85-44bf-9e32-0e43752c88c7
fallocate: 462c8eba-6b85-44bf-9e32-0e43752c88c7: fallocate failed: Operation not supported
As the operation failed, I did following steps:

3.# cp --sparse=never 462c8eba-6b85-44bf-9e32-0e43752c88c7 foo

4.# mv foo 462c8eba-6b85-44bf-9e32-0e43752c88c7

5.# ll -slh
total 5.1G
5.1G -rw-r--r-- 1 root root 5.1G Apr 13 10:05 462c8eba-6b85-44bf-9e32-0e43752c88c7

6.# du -k 462c8eba-6b85-44bf-9e32-0e43752c88c7
5254212	462c8eba-6b85-44bf-9e32-0e43752c88c7

7.Re-import it to rhevm,still with message:
Connot import VM, The selected disk configuration is not supported

Created attachment 491706 [details]
import

Created attachment 491707 [details]
pop-up message

Based on the above, I'm moving this over to RHEV. There does seem to be a virt-v2v bug here because the qcow2 isn't fully preallocated, but that apparently has no bearing on whether RHEV can import it or not.

This was tested against 2.2.4.52920. The reporter says the problem can also been reproduced on 2.3.

Please attache .meta file

Please attache .meta file

Its virt-v2v bug - the OVF is illegal,
The combination of volume_type=Preallocated and volume_format=COW is not legal
as you can see in RHEV-M checks:

if ((diskInfo.getvolume_type() == VolumeType.Preallocated &&
diskInfo.getvolume_format() == VolumeFormat.COW)
|| ( (storageDomain.getstorage_type() == StorageType.FCP
||    storageDomain.getstorage_type() == StorageType.ISCSI) 
      && (diskInfo .getvolume_type() == VolumeType.Sparse 
      && diskInfo.getvolume_format() == VolumeFormat.RAW))
|| (diskInfo.getvolume_format() == VolumeFormat.Unassigned || 
diskInfo.getvolume_type() == VolumeType.Unassigned)) {
  error...
}

Matthew, let me know if I am wrong.

(In reply to comment #12)
> Its virt-v2v bug - the OVF is illegal,
> The combination of volume_type=Preallocated and volume_format=COW is not legal
> as you can see in RHEV-M checks:
> 
> if ((diskInfo.getvolume_type() == VolumeType.Preallocated &&
> diskInfo.getvolume_format() == VolumeFormat.COW)
> || ( (storageDomain.getstorage_type() == StorageType.FCP
> ||    storageDomain.getstorage_type() == StorageType.ISCSI) 
>       && (diskInfo .getvolume_type() == VolumeType.Sparse 
>       && diskInfo.getvolume_format() == VolumeFormat.RAW))
> || (diskInfo.getvolume_format() == VolumeFormat.Unassigned || 
> diskInfo.getvolume_type() == VolumeType.Unassigned)) {
>   error...
> }
> 
> Matthew, let me know if I am wrong.

I think this is a judgement call rather than a right/wrong situation. A preallocated qcow2 file is obviously perfectly valid, but RHEV doesn't support it. The question is whether it should or not. TBH, I can't think of a good reason that it shouldn't be supported. After all, preallocated is just an edge case of sparse. In fact, I suspect the fix would be as simple as updating the above check.

If it's deliberately not supported, though, I'll move this bug to a bug against the V2V Admin guide. We should simply instruct users that this isn't supported by RHEV, and they shouldn't create these files.

Sorry, didn't realise you'd updated the component. Sending this back to RHEV for the moment.

See comment #14. Is the lack of support for qcow2/preallocated in RHEV intentional? It's certainly intentionally supported by virt-v2v.

(In reply to comment #10)
> Please attache .meta file

Hi Ayal,I have attached .meta file.The first attachment meta file.

(In reply to comment #17)
> Sorry, didn't realise you'd updated the component. Sending this back to RHEV
> for the moment.
> 
> See comment #14. Is the lack of support for qcow2/preallocated in RHEV
> intentional? It's certainly intentionally supported by virt-v2v.

Yes it is intentional.  There is no reason to support it. We should discourage users from doing it as there is no benefit to it, but there is a performance hit.  When running V2V, there is a full copy anyway, so it's better to convert to raw.
The fact that it is technically possible doesn't mean we should support it.

Moving to virt-v2v according to comment#14.

We need to communicate to users that, when converting a guest to RHEV, not all combinations of storage format and allocation policy are supported. The supported combinations differ according to whether the RHEV data center the guest will be imported into uses block (FC or iSCSI) or file (NFS) for its *data* storage domain. Note that virt-v2v writes to an *export* storage domain, and this is always required to be NFS. The only important element here is the type of the *data* storage domain.

FC/iSCSI
--------
raw/preallocated
qcow2/sparse

NFS
---
raw/sparse
raw/preallocated
qcow2/sparse

Note that qcow2/preallocated is never supported, although virt-v2v is able to write it.

If the user selects a combination which is not supported by the target datacenter, the v2v conversion will succeed, but when trying to import into RHEV, they will receive the error message "Cannot import
VM, The selected disk configuration is not supported."

By default, virt-v2v will preserve the existing format/allocation. To ensure a successful conversion the user should explicitly specify the desired output type with -of <qcow2/raw> -oa <sparse/preallocated> on the command line.

Ayal, would you mind quickly reviewing the above?

Thanks,

Matt

Comments inline.

(In reply to comment #21)
> We need to communicate to users that, when converting a guest to RHEV, not all
> combinations of storage format and allocation policy are supported. The
> supported combinations differ according to whether the RHEV data center the
> guest will be imported into uses block (FC or iSCSI) or file (NFS) for its

This doesn't matter much as the user can convert when importing into the target domain.  In addition, I believe RHEVM now blocks the option of making such a mistake.

> *data* storage domain. Note that virt-v2v writes to an *export* storage domain,
> and this is always required to be NFS. The only important element here is the
> type of the *data* storage domain.

V2V only supports NFS Export domains (RHEVM supports block export domains as well).

> 
> FC/iSCSI
> --------
> raw/preallocated
> qcow2/sparse
> 
> NFS
> ---
> raw/sparse
> raw/preallocated
> qcow2/sparse
> 

> Note that qcow2/preallocated is not supported, although virt-v2v is able to
> write it.
I would just say "Note that qcow2/preallocated is not supported."
In addition, I would recommend disabling this in V2V altogether.


> 
> If the user selects a combination which is not supported by the target
> datacenter, the v2v conversion will succeed, but when trying to import into
> RHEV, they will receive the error message "Cannot import
> VM, The selected disk configuration is not supported."
> 
> By default, virt-v2v will preserve the existing format/allocation. To ensure a
> successful conversion the user should explicitly specify the desired output
> type with -of <qcow2/raw> -oa <sparse/preallocated> on the command line.

Again, in case of qcow2/preallocated I would fail the operation if the user did not specify a different configuration for the target.  It would prove pretty frustrating for someone who didn't rtfm to convert a 200GB VM just to discover upon import that it doesn't work...

> 
> Ayal, would you mind quickly reviewing the above?
> 
> Thanks,
> 
> Matt

While this was covered in the doc before, it wasn't that obvious. I promoted it to the beginning of Chapter 3: Converting Virtual Machines to Run on Red Hat Enterprise Virtualization. 

I also made the acceptable combinations as explicit as possible using tables, and noted that Preallocated qcow2 storage is never supported in RHEV, although virt-v2v is able to write it. Import to RHEV will fail.