Created attachment 938789 [details] Attched the detailed log file to convert to rhev Description Warning shows when converting guests to rhev:chown: changing ownership of ‘/tmp/v2v.u48xag/*.ovf’: Invalid argument Version: libguestfs-1.27.48-1.1.el7.x86_64 virt-v2v-1.27.48-1.1.el7.x86_64 How reproducible: 100% Steps to Reproduce: #virt-v2v -o rhev -os 10.66.90.115:/vol/v2v_auto/auto_export --network rhevm rhel6.6-tzheng -v -x |& tee /tmp/v2v-rhevm.log [ 161.0] Creating output metadata chown -R 36.36 '/tmp/v2v.u48xag/46adae8a-63c1-40f8-b25a-f02deb1a5160/master/vms/434419ca-ccc0-4ab1-9b5f-e212fe3bbb4d' '/tmp/v2v.u48xag/46adae8a-63c1-40f8-b25a-f02deb1a5160/images/2553e426-cf79-492f-bda3-62e0c68ec3ca' chown: changing ownership of ‘/tmp/v2v.u48xag/46adae8a-63c1-40f8-b25a-f02deb1a5160/master/vms/434419ca-ccc0-4ab1-9b5f-e212fe3bbb4d/434419ca-ccc0-4ab1-9b5f-e212fe3bbb4d.ovf’: Invalid argument chown: changing ownership of ‘/tmp/v2v.u48xag/46adae8a-63c1-40f8-b25a-f02deb1a5160/master/vms/434419ca-ccc0-4ab1-9b5f-e212fe3bbb4d’: Invalid argument chown: changing ownership of ‘/tmp/v2v.u48xag/46adae8a-63c1-40f8-b25a-f02deb1a5160/images/2553e426-cf79-492f-bda3-62e0c68ec3ca/f9cd21a3-b01d-4ded-9051-e19c69cb0c9f.meta’: Invalid argument chown: changing ownership of ‘/tmp/v2v.u48xag/46adae8a-63c1-40f8-b25a-f02deb1a5160/images/2553e426-cf79-492f-bda3-62e0c68ec3ca/f9cd21a3-b01d-4ded-9051-e19c69cb0c9f’: Invalid argument chown: changing ownership of ‘/tmp/v2v.u48xag/46adae8a-63c1-40f8-b25a-f02deb1a5160/images/2553e426-cf79-492f-bda3-62e0c68ec3ca’: Invalid argument virt-v2v: warning: could not chown newly created RHEV files and directories to 36.36. You may need to do this by hand, otherwise RHEV-M may give errors when trying to import this domain. The directories (and all files inside) that have to be owned by 36.36 are: 46adae8a-63c1-40f8-b25a-f02deb1a5160/master/vms/434419ca-ccc0-4ab1-9b5f-e212fe3bbb4d 46adae8a-63c1-40f8-b25a-f02deb1a5160/images/2553e426-cf79-492f-bda3-62e0c68ec3ca [ 161.0] Finishing off Domain rhel7 defined from /tmp/v2vlibvirtd8e625.xml [ 207.0] Finishing off Actual results： Warning shows as description. Expected results: No such warning shows. Additional info: Attached the detailed log file.
After the chown failure, the files are still owned by root.root: [https://bugzilla.redhat.com/show_bug.cgi?id=1142008#c18] # cd images ----> the files under this directory is root.root. [root@dell-op780-04 images]# ls 2553e426-cf79-492f-bda3-62e0c68ec3ca _remoV2IgiD [root@dell-op780-04 images]# ll -lsh total 8.0K 4.0K drwxr-xr-x. 2 root root 4.0K 2014-09-18 01:01 2553e426-cf79-492f-bda3-62e0c68ec3ca 4.0K drwxr-xr-x. 2 root root 4.0K 2014-09-17 22:56 _remoV2IgiD [root@dell-op780-04 images]# cd 2553e426-cf79-492f-bda3-62e0c68ec3ca/ [root@dell-op780-04 2553e426-cf79-492f-bda3-62e0c68ec3ca]# ll -lsh total 3.1G 3.1G -rw-r--r--. 1 root root 10G 2014-09-18 00:00 f9cd21a3-b01d-4ded-9051-e19c69cb0c9f 4.0K -rw-r--r--. 1 root root 296 2014-09-17 23:57 f9cd21a3-b01d-4ded-9051-e19c69cb0c9f.meta
I cannot reproduce this on my RHEV-M installation. However I have added the following commit which *may* solve it. https://github.com/libguestfs/libguestfs/commit/70444670acc60c5700bcd07ea7440d186eb4b60c If it does *not* solve it, then please let me know how the NFS server is configured. In particular, I'd like to know: - Is it NFSv3 or NFSv4? - Is root-squash enabled? (the answer to this must be no) - What is the output of this command on the client? $ grep -v '^#' /etc/idmapd.conf | grep -v '^$'
(In reply to Richard W.M. Jones from comment #3) > I cannot reproduce this on my RHEV-M installation. However > I have added the following commit which *may* solve it. > > https://github.com/libguestfs/libguestfs/commit/ > 70444670acc60c5700bcd07ea7440d186eb4b60c > I tried with: libguestfs-1.27.49-1.1.el7.x86_64 virt-v2v-1.27.49-1.1.el7.x86_64 > If it does *not* solve it, then please let me know how the > NFS server is configured. In particular, I'd like to know: The warning info is still there. > > - Is it NFSv3 or NFSv4? NFSv3 > > - Is root-squash enabled? (the answer to this must be no) It should be root-squash enabled,because when I use root to mount the directory,it changes the uid.git to nobody. > > - What is the output of this command on the client? > > $ grep -v '^#' /etc/idmapd.conf | grep -v '^$' On client,it shows: # grep -v '^#' /etc/idmapd.conf | grep -v '^$' [General] [Mapping] Nobody-User = nobody Nobody-Group = nobody [Translation] Method = nsswitch In additional,I tried to use virt-v2v on rhel6 to convert guests to the same export domain,the guest can be imported to data domain successfully.
(In reply to tingting zheng from comment #4) > (In reply to Richard W.M. Jones from comment #3) > > I cannot reproduce this on my RHEV-M installation. However > > I have added the following commit which *may* solve it. > > > > https://github.com/libguestfs/libguestfs/commit/ > > 70444670acc60c5700bcd07ea7440d186eb4b60c > > > > I tried with: > libguestfs-1.27.49-1.1.el7.x86_64 > virt-v2v-1.27.49-1.1.el7.x86_64 > > > If it does *not* solve it, then please let me know how the > > NFS server is configured. In particular, I'd like to know: > > The warning info is still there. > > > > > - Is it NFSv3 or NFSv4? > > NFSv3 Are you totally sure about this? The EINVAL error from chown seems to indicate a problem with idmap which is only used by NFSv4. On the client side, do: mount | grep nfs and look for vers=... field (3 or 4). > > > > - Is root-squash enabled? (the answer to this must be no) > > It should be root-squash enabled,because when I use root to mount the > directory,it changes the uid.git to nobody. But according to https://bugzilla.redhat.com/show_bug.cgi?id=1142008#c18 the files that virt-v2v (running as root) created were owned by root. I don't think root squashing can be happening. Can you check the /etc/exports file on the server.
(In reply to Richard W.M. Jones from comment #5) > (In reply to tingting zheng from comment #4) > > (In reply to Richard W.M. Jones from comment #3) > > > I cannot reproduce this on my RHEV-M installation. However > > > I have added the following commit which *may* solve it. > > > > > > https://github.com/libguestfs/libguestfs/commit/ > > > 70444670acc60c5700bcd07ea7440d186eb4b60c > > > > > > > I tried with: > > libguestfs-1.27.49-1.1.el7.x86_64 > > virt-v2v-1.27.49-1.1.el7.x86_64 > > > > > If it does *not* solve it, then please let me know how the > > > NFS server is configured. In particular, I'd like to know: > > > > The warning info is still there. > > > > > > > > - Is it NFSv3 or NFSv4? > > > > NFSv3 > > Are you totally sure about this? The EINVAL error from chown > seems to indicate a problem with idmap which is only used by > NFSv4. On the client side, do: > > mount | grep nfs > > and look for vers=... field (3 or 4). It is indeed nfsv3,because I create export domain on rhevm,it uses nfsv3 as default. On rhevh host,the command result shows as below: # mount | grep nfs sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) 10.66.90.115:/vol/v2v_auto/nfs_data on /rhev/data-center/mnt/10.66.90.115:_vol_v2v__auto_nfs__data type nfs (rw,soft,nosharecache,timeo=600,retrans=6,nfsvers=3,addr=10.66.90.115) 10.66.90.115:/vol/v2v_auto/auto_export on /rhev/data-center/mnt/10.66.90.115:_vol_v2v__auto_auto__export type nfs (rw,soft,nosharecache,timeo=600,retrans=6,nfsvers=3,addr=10.66.90.115) > > > > > > > - Is root-squash enabled? (the answer to this must be no) > > > > It should be root-squash enabled,because when I use root to mount the > > directory,it changes the uid.git to nobody. > > But according to > https://bugzilla.redhat.com/show_bug.cgi?id=1142008#c18 > the files that virt-v2v (running as root) created were owned by > root. I don't think root squashing can be happening. That's the result in rhevh host which is registered on rhev. If I mount the nfs on my local host using root,then uid.git will be changed to nobody. > Can you check the /etc/exports file on the server. Actually I tried last week,the mount point vol/v2v_auto/auto_export is created by system administrator,I contacted with him,he said it is a storage and there is no exports file in that server.I can only get the below result from him: # vol status v2v_auto -v Volume State Status Options v2v_auto online raid_dp, flex nosnap=off, nosnapdir=off, minra=off, no_atime_update=off, nvfail=off, ignore_inconsistent=off, snapmirrored=off, create_ucode=off, convert_ucode=off, maxdirsize=18350, schedsnapname=ordinal, fs_size_fixed=off, compression=off, guarantee=volume, svo_enable=off, svo_checksum=off, svo_allow_rman=off, svo_reject_errors=off, no_i2p=off, fractional_reserve=100, extent=off, try_first=volume_grow, read_realloc=off, snapshot_clone_dependency=off Containing aggregate: 'aggr0' Plex /aggr0/plex0: online, normal, active RAID group /aggr0/plex0/rg0: normal Snapshot autodelete settings for v2v_auto: state=off commitment=try trigger=volume target_free_space=20% delete_order=oldest_first defer_delete=user_created prefix=(not specified) destroy_list=none Volume autosize settings: state=off
Here's hoping this is fixed by: https://github.com/libguestfs/libguestfs/commit/0dfa96c043cee4ce82c0a45c3ad09b0a61798b79 in virt-v2v >= 1.27.52.
Tested with: libguestfs-1.27.52-1.1.el7.x86_64 virt-v2v-1.27.52-1.1.el7.x86_64 # virt-v2v -o rhev -os 10.66.90.115:/vol/v2v_auto/auto_export --network rhevm rhel6.6-tzheng -on tzheng-bug1143887 [ 0.0] Opening the source -i libvirt rhel6.6-tzheng [ 0.0] Creating an overlay to protect the source from being modified [ 0.0] Opening the overlay [ 61.0] Initializing the target -o rhev -os 10.66.90.115:/vol/v2v_auto/auto_export virt-v2v: warning: cannot write files to the NFS server as 36:36, even though we appear to be running as root. This probably means the NFS client or idmapd is not configured properly. You will have to chown the files that virt-v2v creates after the run, otherwise RHEV-M will not be able to import the VM. [ 61.0] Inspecting the overlay [ 76.0] Checking for sufficient free disk space in the guest [ 76.0] Estimating space required on target for each disk [ 76.0] Converting Red Hat Enterprise Linux Server release 6.6 Beta (Santiago) to run on KVM This guest has virtio drivers installed. [ 153.0] Mapping filesystem data to avoid copying unused and blank areas [ 153.0] Closing the overlay [ 154.0] Copying disk 1/1 to /tmp/v2v.WJ2JTQ/46adae8a-63c1-40f8-b25a-f02deb1a5160/images/2558209a-8799-4cb9-b04a-6c31dfb384a0/5edd2ae6-8152-4667-8e94-f7169519ac87 (raw) (100.00/100%) [ 229.0] Creating output metadata [ 229.0] Finishing off It seems the bug has been fixed,however,there is new warning info: virt-v2v: warning: cannot write files to the NFS server as 36:36, even though we appear to be running as root. This probably means the NFS client or idmapd is not configured properly. Is it acceptable?I checked on rhevh host,the owner of the file has been changed to 36:36. [root@dell-op780-04 2558209a-8799-4cb9-b04a-6c31dfb384a0]# ll -lsh total 3.1G 3.1G -rw-rw-r--. 1 vdsm kvm 10G 2014-09-22 19:48 5edd2ae6-8152-4667-8e94-f7169519ac87 4.0K -rw-r--r--. 1 vdsm kvm 296 2014-09-22 19:45 5edd2ae6-8152-4667-8e94-f7169519ac87.meta
(In reply to tingting zheng from comment #8) > Tested with: > libguestfs-1.27.52-1.1.el7.x86_64 > virt-v2v-1.27.52-1.1.el7.x86_64 > > # virt-v2v -o rhev -os 10.66.90.115:/vol/v2v_auto/auto_export --network > rhevm rhel6.6-tzheng -on tzheng-bug1143887 > [ 0.0] Opening the source -i libvirt rhel6.6-tzheng > [ 0.0] Creating an overlay to protect the source from being modified > [ 0.0] Opening the overlay > [ 61.0] Initializing the target -o rhev -os > 10.66.90.115:/vol/v2v_auto/auto_export > virt-v2v: warning: cannot write files to the NFS server as 36:36, even > though we appear to be running as root. This probably means the NFS client > or idmapd is not configured properly. > > You will have to chown the files that virt-v2v creates after the run, > otherwise RHEV-M will not be able to import the VM. > [ 61.0] Inspecting the overlay > [ 76.0] Checking for sufficient free disk space in the guest > [ 76.0] Estimating space required on target for each disk > [ 76.0] Converting Red Hat Enterprise Linux Server release 6.6 Beta > (Santiago) to run on KVM > This guest has virtio drivers installed. > [ 153.0] Mapping filesystem data to avoid copying unused and blank areas > [ 153.0] Closing the overlay > [ 154.0] Copying disk 1/1 to > /tmp/v2v.WJ2JTQ/46adae8a-63c1-40f8-b25a-f02deb1a5160/images/2558209a-8799- > 4cb9-b04a-6c31dfb384a0/5edd2ae6-8152-4667-8e94-f7169519ac87 (raw) > (100.00/100%) > [ 229.0] Creating output metadata > [ 229.0] Finishing off > > It seems the bug has been fixed,however,there is new warning info: > virt-v2v: warning: cannot write files to the NFS server as 36:36, even > though we appear to be running as root. This probably means the NFS client > or idmapd is not configured properly. > > Is it acceptable?I checked on rhevh host,the owner of the file has been > changed to 36:36. > [root@dell-op780-04 2558209a-8799-4cb9-b04a-6c31dfb384a0]# ll -lsh > total 3.1G > 3.1G -rw-rw-r--. 1 vdsm kvm 10G 2014-09-22 19:48 > 5edd2ae6-8152-4667-8e94-f7169519ac87 > 4.0K -rw-r--r--. 1 vdsm kvm 296 2014-09-22 19:45 > 5edd2ae6-8152-4667-8e94-f7169519ac87.meta No that's not correct. The warning should not have been printed. Can you run it again with -v -x and attach the full logs. The verbose output includes the actual UID:GID that virt-v2v thinks were written.
Created attachment 940304 [details] Log file
Thanks ... For some reason the UID:GID was reported as: RHEV: actual UID:GID of new files is 99:99
The new files created through the forking method have the right numeric UID/GID: 11:18 < tzheng> total 3.1G 11:18 < tzheng> 3.1G -rw-r--r--. 1 36 36 3.1G 2014-09-23 02:50 3297ff0e-3066-4527-b774-c4e21c815230 11:18 < tzheng> 4.0K -rw-r--r--. 1 36 36 296 2014-09-23 02:48 3297ff0e-3066-4527-b774-c4e21c815230.meta
(In reply to tingting zheng from comment #6) > > Can you check the /etc/exports file on the server. > > Actually I tried last week,the mount point vol/v2v_auto/auto_export is > created by system administrator,I contacted with him,he said it is a storage > and there is no exports file in that server.I can only get the below result > from him: > # vol status v2v_auto -v > Volume State Status Options > v2v_auto online raid_dp, flex nosnap=off, nosnapdir=off, > minra=off, no_atime_update=off, > nvfail=off, [...] Apparently this means it is a NetApp. Apparently there is a command you can run on NetApp to find out what the "security" options are: netapp-storage> exportfs /v2v_auto [something useful may be printed here] It would be really useful to find out how this is configured. I've made some further adjustments to permissions etc in virt-v2v 1.27.53. I don't think it will fix the warning.
Tested with: virt-v2v-1.27.53-1.1.el7.x86_64 libguestfs-1.27.53-1.1.el7.x86_64 The warning info is still there. As I have no privilege to access the nfs server,I configure a normal nfs server on my machine. on nfs server: # cat /etc/exports /var/v2v_export *(rw) # chown -R 36:36 /var/v2v_export/ Use virt-v2v to convert to the new nfs export,the warning is still there. # virt-v2v -o rhev -os 10.66.6.8:/var/v2v_export --network rhevm rhel6.6-tzheng -on tzheng-bug1143887-new [ 0.0] Opening the source -i libvirt rhel6.6-tzheng [ 0.0] Creating an overlay to protect the source from being modified [ 0.0] Opening the overlay [ 6.0] Initializing the target -o rhev -os 10.66.6.8:/var/v2v_export virt-v2v: warning: cannot write files to the NFS server as 36:36, even though we appear to be running as root. This probably means the NFS client or idmapd is not configured properly. You will have to chown the files that virt-v2v creates after the run, otherwise RHEV-M will not be able to import the VM. [ 6.0] Inspecting the overlay [ 20.0] Checking for sufficient free disk space in the guest [ 20.0] Estimating space required on target for each disk [ 20.0] Converting Red Hat Enterprise Linux Server release 6.6 Beta (Santiago) to run on KVM This guest has virtio drivers installed. [ 92.0] Mapping filesystem data to avoid copying unused and blank areas [ 93.0] Closing the overlay [ 93.0] Copying disk 1/1 to /tmp/v2v.n39QiB/e4883354-fa70-4314-bcc0-6ee12c39e3a2/images/2fa21597-c8fb-4278-b020-339d1ed98e06/28a96d8b-fecc-48e0-8c24-fc864175ea59 (raw) (100.00/100%) [ 334.0] Creating output metadata [ 335.0] Finishing off
I need virt-v2v -v -x output from that command. Also: On the NFS server, can you check that the files are being created with UID:GID 36:36 by doing: ls -l -R -n /var/v2v_export
(In reply to Richard W.M. Jones from comment #16) > I need virt-v2v -v -x output from that command. I will attach in next comment. > > Also: On the NFS server, can you check that the files are > being created with UID:GID 36:36 by doing: > > ls -l -R -n /var/v2v_export Output from my nfs server,all files all created with UID:GID 36:36. # ls -l -R -n /var/v2v_export /var/v2v_export: total 4 -rwxr-xr-x. 1 36 36 0 Sep 24 10:56 __DIRECT_IO_TEST__ drwxr-xr-x. 5 36 36 4096 Sep 25 11:12 e4883354-fa70-4314-bcc0-6ee12c39e3a2 /var/v2v_export/e4883354-fa70-4314-bcc0-6ee12c39e3a2: total 12 drwxr-xr-x. 2 36 36 4096 Sep 24 10:56 dom_md drwxr-xr-x. 5 36 36 4096 Sep 25 11:12 images drwxr-xr-x. 4 36 36 4096 Sep 24 10:56 master /var/v2v_export/e4883354-fa70-4314-bcc0-6ee12c39e3a2/dom_md: total 8 -rw-rw----. 1 36 36 0 Sep 24 10:56 ids -rw-rw----. 1 36 36 16777216 Sep 24 10:56 inbox -rw-rw----. 1 36 36 512 Sep 24 10:56 leases -rw-r--r--. 1 36 36 355 Sep 24 10:56 metadata -rw-rw----. 1 36 36 16777216 Sep 24 10:56 outbox /var/v2v_export/e4883354-fa70-4314-bcc0-6ee12c39e3a2/images: total 12 drwxr-xr-x. 2 36 36 4096 Sep 25 10:56 0e778ca7-255f-45a1-9eef-555f0f5bf56b drwxr-xr-x. 2 36 36 4096 Sep 25 10:59 b904fd46-5314-4de4-b0ca-4e7b93d40c7e drwxr-xr-x. 2 36 36 4096 Sep 25 11:13 c11f3641-5e44-42e6-b0d0-dcbe7ea75517 /var/v2v_export/e4883354-fa70-4314-bcc0-6ee12c39e3a2/images/0e778ca7-255f-45a1-9eef-555f0f5bf56b: total 1562180 -rw-rw-rw-. 1 36 36 8388608000 Sep 25 10:58 0de362b0-e434-4e86-898b-57c91f9d3a10 -rw-r--r--. 1 36 36 296 Sep 25 10:55 0de362b0-e434-4e86-898b-57c91f9d3a10.meta /var/v2v_export/e4883354-fa70-4314-bcc0-6ee12c39e3a2/images/b904fd46-5314-4de4-b0ca-4e7b93d40c7e: total 3254980 -rw-rw-rw-. 1 36 36 10737418240 Sep 25 11:04 b8eb3a5d-29aa-434a-be9f-1ae1780eba8c -rw-r--r--. 1 36 36 296 Sep 25 10:58 b8eb3a5d-29aa-434a-be9f-1ae1780eba8c.meta /var/v2v_export/e4883354-fa70-4314-bcc0-6ee12c39e3a2/images/c11f3641-5e44-42e6-b0d0-dcbe7ea75517: total 3254968 -rw-rw-rw-. 1 36 36 10737418240 Sep 25 11:18 c46847ad-0c62-444f-9464-7db8a8760cc0 -rw-r--r--. 1 36 36 296 Sep 25 11:12 c46847ad-0c62-444f-9464-7db8a8760cc0.meta /var/v2v_export/e4883354-fa70-4314-bcc0-6ee12c39e3a2/master: total 8 drwxr-xr-x. 2 36 36 4096 Sep 24 10:56 tasks drwxr-xr-x. 5 36 36 4096 Sep 25 11:18 vms /var/v2v_export/e4883354-fa70-4314-bcc0-6ee12c39e3a2/master/tasks: total 0 /var/v2v_export/e4883354-fa70-4314-bcc0-6ee12c39e3a2/master/vms: total 12 drwxr-xr-x. 2 36 36 4096 Sep 25 10:58 0dbcb549-bc9e-4f02-92e8-00be4e7fd4f4 drwxr-xr-x. 2 36 36 4096 Sep 25 11:04 919c7259-5852-46d1-b283-3b27e678eb2f drwxr-xr-x. 2 36 36 4096 Sep 25 11:18 dd683c52-c656-4de4-8001-58fb4ab8706e /var/v2v_export/e4883354-fa70-4314-bcc0-6ee12c39e3a2/master/vms/0dbcb549-bc9e-4f02-92e8-00be4e7fd4f4: total 8 -rw-r--r--. 1 36 36 5027 Sep 25 10:58 0dbcb549-bc9e-4f02-92e8-00be4e7fd4f4.ovf /var/v2v_export/e4883354-fa70-4314-bcc0-6ee12c39e3a2/master/vms/919c7259-5852-46d1-b283-3b27e678eb2f: total 8 -rw-r--r--. 1 36 36 4637 Sep 25 11:04 919c7259-5852-46d1-b283-3b27e678eb2f.ovf /var/v2v_export/e4883354-fa70-4314-bcc0-6ee12c39e3a2/master/vms/dd683c52-c656-4de4-8001-58fb4ab8706e: total 8 -rw-r--r--. 1 36 36 4637 Sep 25 11:18 dd683c52-c656-4de4-8001-58fb4ab8706e.ovf
Created attachment 940967 [details] New log file to converting to rhev
Refer to comment 10,there is still warning info,so move the bug back to ASSIGNED.
Convert guest from kvm to rhev with builds virt-v2v-1.32.2-3.el7.x86_64 libguestfs-1.32.2-3.el7.x86_64 1.Convert guest from kvm to rhevm3.5（version:3.5.7-0.1.el6）, still popup " virt-v2v: warning: cannot write files to the NFS server as 36:36 " # virt-v2v -o rhev -os 10.66.72.27:/home/nfs_export -n rhevm -b rhevm esx5.1-win8.1-x86_64 -of raw [ 0.0] Opening the source -i libvirt esx5.1-win8.1-x86_64 [ 0.0] Creating an overlay to protect the source from being modified [ 0.4] Initializing the target -o rhev -os 10.66.72.27:/home/nfs_export virt-v2v: warning: cannot write files to the NFS server as 36:36, even though we appear to be running as root. This probably means the NFS client or idmapd is not configured properly. You will have to chown the files that virt-v2v creates after the run, otherwise RHEV-M will not be able to import the VM. [ 0.5] Opening the overlay [ 4.9] Inspecting the overlay [ 6.7] Checking for sufficient free disk space in the guest [ 6.7] Estimating space required on target for each disk [ 6.7] Converting Windows 8.1 Enterprise to run on KVM virt-v2v: warning: there is no QXL driver for this version of Windows (6.3 x86_64). virt-v2v looks for this driver in /usr/share/virtio-win The guest will be configured to use standard VGA. virt-v2v: This guest has virtio drivers installed. [ 8.7] Mapping filesystem data to avoid copying unused and blank areas [ 9.4] Closing the overlay [ 9.5] Checking if the guest needs BIOS or UEFI to boot [ 9.5] Assigning disks to buses [ 9.5] Copying disk 1/1 to /tmp/v2v.VbKgTU/47d5b145-b6ac-4420-aca2-9e6d91d430af/images/65f91e14-e32e-444a-a171-c2e9209db35f/3f3cabd5-57f5-4046-a428-ede3ae1d7635 (raw) (100.00/100%) [ 158.9] Creating output metadata [ 159.0] Finishing off 2.Convert guest from kvm to rhevm3.6(verson：3.6.2.6-0.1.el6), there is no "virt-v2v: warning: cannot write files to the NFS server as 36:36 " # virt-v2v -o rhev -os 10.73.69.63:/home/nfs_export -n ovirtmgmt -b ovirtmgmt esx5.1-win8.1-x86_64 -of raw [ 0.0] Opening the source -i libvirt esx5.1-win8.1-x86_64 [ 0.0] Creating an overlay to protect the source from being modified [ 0.4] Initializing the target -o rhev -os 10.73.69.63:/home/nfs_export [ 0.6] Opening the overlay [ 5.1] Inspecting the overlay [ 6.6] Checking for sufficient free disk space in the guest [ 6.6] Estimating space required on target for each disk [ 6.6] Converting Windows 8.1 Enterprise to run on KVM virt-v2v: warning: there is no QXL driver for this version of Windows (6.3 x86_64). virt-v2v looks for this driver in /usr/share/virtio-win The guest will be configured to use standard VGA. virt-v2v: This guest has virtio drivers installed. [ 8.2] Mapping filesystem data to avoid copying unused and blank areas [ 8.9] Closing the overlay [ 9.1] Checking if the guest needs BIOS or UEFI to boot [ 9.1] Assigning disks to buses [ 9.1] Copying disk 1/1 to /tmp/v2v.Rd1qbP/d5b21b75-57d6-4b1a-bd40-e949232067df/images/cc2b7d44-9839-40b9-9fcb-36f4101a866b/a2443c9a-e43f-4034-865d-f1d662d415ac (raw) (100.00/100%) [ 221.5] Creating output metadata [ 221.6] Finishing off
Research the bug and found the bug will not occur when converting guest to rhevm whose storage is rhel7 nfs export domain Relevant packages version: virt-v2v-1.32.2-6.el7.x86_64 libguestfs-1.32.2-6.el7.x86_64 Scenario1: 1.1 Add rhel7 nfs export domain on rhevm3.5 rhevm3.5: 3.5.7-0.1.el6 rhel7.2 (3.10.0-327.10.2.el7.x86_64)nfs export domain:10.73.69.75:/mxie/export 1.2 Usig virt-v2v to convert guest to rhevm3.5 whose storage is rhel7 nfs export domain, we can see there is no virt-v2v: warning: cannot write files to the NFS server as 36:36 # virt-v2v -o rhev -os 10.73.69.75:/mxie/export -n rhevm -b rhevm win10-x64 [ 0.0] Opening the source -i libvirt win10-x64 [ 0.0] Creating an overlay to protect the source from being modified [ 0.5] Initializing the target -o rhev -os 10.73.69.75:/mxie/export [ 0.6] Opening the overlay [ 5.1] Inspecting the overlay [ 6.1] Checking for sufficient free disk space in the guest [ 6.1] Estimating space required on target for each disk [ 6.1] Converting Windows 10 Enterprise to run on KVM virt-v2v: warning: there are no virtio drivers available for this version of Windows (10.0 x86_64 Client). virt-v2v looks for drivers in /usr/share/virtio-win The guest will be configured to use slower emulated devices. virt-v2v: This guest does not have virtio drivers installed. [ 7.7] Mapping filesystem data to avoid copying unused and blank areas [ 8.2] Closing the overlay [ 8.4] Checking if the guest needs BIOS or UEFI to boot [ 8.4] Assigning disks to buses [ 8.4] Copying disk 1/1 to /tmp/v2v.uenK2U/5bee2716-dba2-48a1-b2be-99fb7c12475e/images/126ee06d-c775-402a-8463-fad47d901a9b/6f1f3b9e-835a-48d1-8802-2db8e6cce431 (qcow2) (100.00/100%) [ 204.7] Creating output metadata [ 204.8] Finishing off Scenario2: 2.1 Add rhel6 nfs export domain on rhevm3.6 rhevm3.6: 3.6.3.2-0.1.el6 rhel6 (2.6.32-573.el6.x86_64 )nfs export domain:10.73.2.1:/home/nfs_export 2.2 Usig virt-v2v to convert guest to rhevm3.6 whose storage is rhel6 nfs export domain, we can see there is virt-v2v: warning: cannot write files to the NFS server as 36:36 # virt-v2v -o rhev -os 10.73.2.1:/home/nfs_export -n ovirtmgmt -b ovirtmgmt win10-x64 [ 0.0] Opening the source -i libvirt win10-x64 [ 0.0] Creating an overlay to protect the source from being modified [ 0.4] Initializing the target -o rhev -os 10.73.2.1:/home/nfs_export virt-v2v: warning: cannot write files to the NFS server as 36:36, even though we appear to be running as root. This probably means the NFS client or idmapd is not configured properly. You will have to chown the files that virt-v2v creates after the run, otherwise RHEV-M will not be able to import the VM. [ 0.5] Opening the overlay [ 4.9] Inspecting the overlay [ 5.9] Checking for sufficient free disk space in the guest [ 5.9] Estimating space required on target for each disk [ 5.9] Converting Windows 10 Enterprise to run on KVM virt-v2v: warning: there are no virtio drivers available for this version of Windows (10.0 x86_64 Client). virt-v2v looks for drivers in /usr/share/virtio-win The guest will be configured to use slower emulated devices. virt-v2v: This guest does not have virtio drivers installed. [ 8.0] Mapping filesystem data to avoid copying unused and blank areas [ 9.3] Closing the overlay [ 9.6] Checking if the guest needs BIOS or UEFI to boot [ 9.6] Assigning disks to buses [ 9.6] Copying disk 1/1 to /tmp/v2v.S5Naez/7251b570-41cb-4318-a791-7f5bc4708183/images/c9b33ac3-9cd3-4d39-b26b-295482cdb94b/f88c1a3c-f3d3-417a-881e-069376677865 (qcow2) (100.00/100%) [ 192.4] Creating output metadata [ 192.5] Finishing off So I think this bug is related to rhel6 nfs domain which not related to rhevm
Based on comment 24, this might be something to do with RHEL 6 vs RHEL 7 NFS servers. However I don't have a clear reproducer, and I don't understand why the bug happens, so I have to move it to RHEL 7.4.
I've still not been able to reproduce this. However it would be good to retest it with RHEL 7.4 to see if it has been fixed. In the meantime I have to move this to 7.5.
We are closing this now. Please reopen this if customer reports this issue.