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(a)redhat.xn--com> -opa
gpg: alias « Richard W.M. Jones <rich(a)annexia.xn--org> -opa
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@redhat.com]
Envoyé : mercredi 15 octobre 2014 17:52
À : VONDRA Alain
Cc : libguestfs(a)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