[Libguestfs] Virt-v2v conversion issue

VONDRA Alain AVONDRA at unicef.fr
Thu Oct 16 08:55:10 UTC 2014


I was hoping that it works, but the conversion hanged at the 7th /9 disk 57,03% since 1.30 AM...

[19351,0] Copying disk 7/9 to /tmp/v2v.UgUPSx/0a6404e0-2857-45e4-9322-c1ada5ae13fb/images/0123ddcd-f88d-43d0-b836-2cabe57beac3/d0fe6d79-b846-41ca-ac94-835b97488685 (raw)
target_file = /tmp/v2v.UgUPSx/0a6404e0-2857-45e4-9322-c1ada5ae13fb/images/0123ddcd-f88d-43d0-b836-2cabe57beac3/d0fe6d79-b846-41ca-ac94-835b97488685
target_format = raw
target_estimated_size = 42968862720
target_overlay = /var/tmp/v2vovle2fd4a.qcow2
target_overlay.ov_source = /data/big_export/IMAGES/UNC-SRV-QUAL03-6.img
qemu-img convert -p -n -f qcow2 -O 'raw' '/var/tmp/v2vovle2fd4a.qcow2' '/tmp/v2v.UgUPSx/0a6404e0-2857-45e4-9322-c1ada5ae13fb/images/0123ddcd-f88d-43d0-b836-2cabe57beac3/d0fe6d79-b846-41ca-ac94-835b97488685'
    (57.03/100%)

The qemu-img idles :
23338 root      20   0  227300   7332   3868 S   0,0  0,1   0:48.29 qemu-img
I have no errors in dmesg, but NFSD state is D :

11263 root      20   0       0      0      0 S  0,0  0,0   0:00.00 lockd
11266 root      20   0       0      0      0 D  0,0  0,0   1:52.51 nfsd
11267 root      20   0       0      0      0 D  0,0  0,0   1:52.58 nfsd
11268 root      20   0       0      0      0 D  0,0  0,0   1:53.15 nfsd
11269 root      20   0       0      0      0 D  0,0  0,0   1:52.83 nfsd
11270 root      20   0       0      0      0 D  0,0  0,0   1:52.27 nfsd
11271 root      20   0       0      0      0 D  0,0  0,0   1:52.56 nfsd
11272 root      20   0       0      0      0 D  0,0  0,0   1:51.99 nfsd
11273 root      20   0       0      0      0 D  0,0  0,0   1:53.72 nfsd

I think the problem is there, I have to say you that my NFS EXPORT_DOMAIN for Ovirt is on the same machine (because of need of large volume space "4Tb" to convert big vmdk images) so the NFS volume /data/big_import/IMPORT is used to convert images and to send (in fact on the same HD via NFS) it to oVirt Manager.
I've tried before to convert locally images but they didn't appeared in "Import VM" on the oVirt Manager.

Maybe it was a bug from older version of libguestfs and works today ?

If you have a better proposition to make this conversion not using the -o rhev -os "nfs share", I'll friendly accept !!!!

Alain









-----Message d'origine-----
De : libguestfs-bounces at redhat.com [mailto:libguestfs-bounces at redhat.com] De la part de VONDRA Alain
Envoyé : mercredi 15 octobre 2014 18:33
À : Richard W.M. Jones
Cc : libguestfs at redhat.com
Objet : Re: [Libguestfs] Virt-v2v conversion issue

The script as worked perfectly :

+ size=100G
+ virt-builder fedora-20 --size 100G -o /tmp/in.img
gpg: Signature faite le mar. 08 juil. 2014 11:11:00 CEST avec la clef RSA d'identifiant E1B768A0
gpg: Bonne signature de « Richard W.M. Jones <rjones at redhat.com> »
gpg:                 alias « Richard W.M. Jones <rich at annexia.org> »
gpg: Attention : cette clef n'est pas certifiée avec une signature de confiance.
gpg:             Rien n'indique que la signature appartient à son propriétaire.
Empreinte de clef principale : F777 4FB1 AD07 4A7E 8C87  67EA 9173 8F73 E1B7 68A0
[   1,0] Downloading: http://libguestfs.org/download/builder/fedora-20.xz
######################################################################## 100,0% [ 718,0] Planning how to build this image [ 718,0] Uncompressing [ 737,0] Resizing (using virt-resize) to expand the disk to 100,0G [ 786,0] Opening the new disk [ 792,0] Setting a random seed [ 792,0] Setting passwords [ 794,0] Finishing off
                   Output file: /tmp/in.img
                   Output size: 100,0G
                 Output format: raw
            Total usable space: 97,7G
                    Free space: 97,0G (99%)
+ guestfish -a /tmp/in.img -i
+ qemu-img create -q -f qcow2 -b /tmp/in.img -o 
+ compat=1.1,backing_fmt=raw /tmp/overlay.qcow2 truncate -s 100G 
+ /tmp/out.img qemu-img convert -p -n -f qcow2 /tmp/overlay.qcow2 -O raw 
+ /tmp/out.img
    (100.00/100%)

real    2m50.364s
user    0m36.146s
sys     2m3.548s

I run again a conversion to try to catch a core dump...
Alain




-----Message d'origine-----
De : Richard W.M. Jones [mailto:rjones at redhat.com] Envoyé : mercredi 15 octobre 2014 17:52 À : VONDRA Alain Cc : libguestfs at redhat.com Objet : Re: [Libguestfs] Virt-v2v conversion issue

On Wed, Oct 15, 2014 at 03:23:39PM +0000, VONDRA Alain wrote:
> I see only qemu-img consumming some CPU and MEM :
> 
> 25897 qemu      20   0 5825976 2,429g   4368 S   5,6 32,2 603:09.34 qemu-kvm

That's qemu, not qemu-img.

> I have indeed, some nfs errors :
> 
> [475747.296041] nfs: server 192.203.100.247 not responding, still 
> trying [475747.772022] nfs: server 192.203.100.247 not responding, 
> still trying [475747.848023] nfs: server 192.203.100.247 not 
> responding, still trying [475747.849014] nfs: server 192.203.100.247 
> not responding, still trying [475748.270030] nfs: server
> 192.203.100.247 not responding, still trying [475748.270038] nfs: 
> server 192.203.100.247 not responding, still trying [475748.273016]
> nfs: server 192.203.100.247 not responding, still trying 
> [475748.274016] nfs: server 192.203.100.247 not responding, still 
> trying [475748.461023] nfs: server 192.203.100.247 not responding, 
> still trying [475748.461028] nfs: server 192.203.100.247 not 
> responding, still trying [475748.461031] nfs: server 192.203.100.247 
> not responding, still trying [475748.461034] nfs: server
> 192.203.100.247 not responding, still trying

These are a problem, if they are coincident with qemu-img hanging.
Use 'dmesg -w' to check.

> And a lot of :
> [785084.263606] kvm [12719]: vcpu0 unhandled rdmsr: 0x345 
> [785084.269594] kvm [12719]: vcpu0 unhandled wrmsr: 0x40 data 0 
> [785084.269999] kvm [12719]: vcpu0 unhandled wrmsr: 0x60 data 0 
> [785084.270406] kvm [12719]: vcpu0 unhandled wrmsr: 0x41 data 0 
> [785084.270826] kvm [12719]: vcpu0 unhandled wrmsr: 0x61 data 0 
> [785084.271231] kvm [12719]: vcpu0 unhandled wrmsr: 0x42 data 0 
> [785084.271633] kvm [12719]: vcpu0 unhandled wrmsr: 0x62 data 0 
> [785084.272023] kvm [12719]: vcpu0 unhandled wrmsr: 0x43 data 0 
> [785084.272410] kvm [12719]: vcpu0 unhandled wrmsr: 0x63 data 0

You can ignore this warning.  It is meaningless for the end user and doesn't matter.

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

_______________________________________________
Libguestfs mailing list
Libguestfs at redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs




More information about the Libguestfs mailing list