troubles copying qcow2 VM images
jurgen.depicker at let.be
jurgen.depicker at let.be
Mon Mar 14 20:43:45 UTC 2011
> I'm facing a weird situation, trying to migrate from one storage
> pool (on VLET1, SWRAID1,SATA) to another (on VLET3, HWRAID1,SAS)
> (all servers VLET1,2,3 on ubuntu 10.10)
->each server has /srv/VMs exported as nfs-pool, nfs-pool2 and nfs-pool3
respectively
>
I run the VM ISPConfigLET2 on VLET1, and live migrate it to VLET3 (like
this, I get the host properly defined on VLET3). The disk image, shared
with NFS, resides physically on VLET1.
> 1. I stop all running VM instances
> 2. On VLET3, I have an NFS share of VLET1 mounted
> 3. On VLET3, I issue: cp /mnt/nfs/ISPConfigLET2.qcow2 /srv/VMs/
> 4. On VLET3 and VLET1, I virsh edit ISPConfigLET2 to use the newly
created copied /srv/VMs/ISPConfigLET2.qcow2 residing on pool nfs-pool3
->see XML further down
>
The VM refuses to run with the different storage pool selected: the VM
starts on VLET1 (using the image served over nfs from VLET3), but a boot
error comes up
> -> it gets mounted read-only apparently; it doesn't work.
dmesg:
... (many times same error message)
[ 20.967377] ata1.00: status: { DRDY ERR }
[ 20.967379] ata1.00: error: { ABRT }
[ 20.971640] ata1.00: configured for PIO0
[ 20.971648] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE
[ 20.971651] sd 0:0:0:0: [sda] Sense Key : Aborted Command [current]
[descriptor]
[ 20.971654] Descriptor sense data with sense descriptors (in hex):
[ 20.971656] 72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00
[ 20.971661] 02 77 97 3f
[ 20.971663] sd 0:0:0:0: [sda] Add. Sense: No additional sense
information
[ 20.971666] sd 0:0:0:0: [sda] CDB: Write(10): 2a 00 02 77 97 3f 00 00
08 00
[ 20.971672] end_request: I/O error, dev sda, sector 41391935
[ 20.971684] ata1: EH complete
[ 20.971744] JBD: Detected IO errors while flushing file data on sda1
[ 20.971761] __journal_remove_journal_head: freeing b_committed_data
[ 20.971769] __journal_remove_journal_head: freeing b_committed_data
[ 20.971777] __journal_remove_journal_head: freeing b_committed_data
[ 20.971798] __journal_remove_journal_head: freeing b_committed_data
[ 20.971801] __journal_remove_journal_head: freeing b_committed_data
[ 20.971845] journal commit I/O error
> When
> using rsync or scp instead of cp, there's no difference... I really
don't
> understand what's going on... Who has a clue please??
When trying to start the VM on VLET3, the VM hangs immediately at boot,
with following messags in /var/log/messages:
Mar 14 21:21:30 VLET3 kernel: [255777.604342] type=1400
audit(1300134090.205:39): apparmor="STATUS" operation="profile_load"
name="libvirt-02f97acb-d586-4eb9-9f59-e1df7a3cd647" pid=29124
comm="apparmor_parser"
Mar 14 21:21:30 VLET3 libvirtd: 21:21:30.803: warning :
qemudParsePCIDeviceStrs:1422 : Unexpected exit status '1', qemu probably
failed
Mar 14 21:21:30 VLET3 kernel: [255778.193514] device vnet0 entered
promiscuous mode
Mar 14 21:21:30 VLET3 kernel: [255778.193540] br0: new device vnet0 does
not support netpoll (disabling)
Mar 14 21:21:30 VLET3 kernel: [255778.195370] br0: port 2(vnet0) entering
learning state
Mar 14 21:21:30 VLET3 kernel: [255778.195374] br0: port 2(vnet0) entering
learning state
Mar 14 21:21:45 VLET3 kernel: [255793.206140] br0: port 2(vnet0) entering
forwarding state
> Did the host version change, I had a problem on an older system
> where the disk was type raw even though it was qcow2, on a newer
> lucid host system I had to change it to explicitly state qcow2 then
> it was fine?
>
> --
> Dave
->It is mentioned correctly in the host's XML:
<domain type='kvm'>
<name>ISPConfigLET2</name>
<uuid>101682a8-5969-4ac0-b7dd-53fddd207365</uuid>
<memory>524288</memory>
<currentMemory>524288</currentMemory>
<vcpu>1</vcpu>
<os>
<type arch='i686' machine='pc-0.12'>hvm</type>
<boot dev='hd'/>
</os>
<features>
<acpi/>
</features>
<clock offset='utc'/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>destroy</on_crash>
<devices>
<emulator>/usr/bin/kvm</emulator>
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2'/>
<source file='/var/lib/libvirt/images/nfs-pool3/ispconfig2.qcow2'/>
<target dev='hda' bus='ide'/>
<address type='drive' controller='0' bus='0' unit='0'/>
</disk>
<controller type='ide' index='0'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01'
function='0x1'/>
</controller>
<interface type='bridge'>
<mac address='00:0c:29:9a:6b:a4'/>
<source bridge='br0'/>
<target dev='vnet0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03'
function='0x0'/>
</interface>
<input type='mouse' bus='ps2'/>
<graphics type='vnc' port='-1' autoport='yes' listen='127.0.0.1'/>
<video>
<model type='cirrus' vram='9216' heads='1'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02'
function='0x0'/>
</video>
<memballoon model='virtio'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04'
function='0x0'/>
</memballoon>
</devices>
</domain>
"Serge E. Hallyn" <serge.hallyn at ubuntu.com> wrote on 14/03/2011 14:27:04:
> From: "Serge E. Hallyn" <serge.hallyn at ubuntu.com>
> To: jurgen.depicker at let.be
> Cc: ubuntu-server at lists.ubuntu.com
> Date: 14/03/2011 14:27
> Subject: Re: troubles copying qcow2 VM images
>
> Quoting jurgen.depicker at let.be (jurgen.depicker at let.be):
> > Dear all,
> >
> > I'm facing a weird situation, trying to migrate from one storage pool
(on
> > VLET1, SWRAID1,SATA) to another (on VLET3, HWRAID1,SAS)
> > (all servers VLET1,2,3 on ubuntu 10.10)
> >
> > 1. I stop all running VM instances
> > 2. On VLET3, I have an NFS share of VLET1 mounted
> > 3. On VLET3, I issue: cp /mnt/nfs/VM1.qcow2 /srv/VMs/
> > 4. I reconfigure VM1 to use the newly created copied
/srv/VMs/VM1.qcow2
> >
> > -> it gets mounted read-only apparently; it doesn't work. When using
> > rsync instead of cp, there's no difference... I really don't
understand
> > what's going on... Who has a clue please??
>
> Can you sha1sum {/mnt/nfs,/srv/VMs/}/VM1.qcow2? My guess is this is an
> NFS bug with large file xfer corruption.
>
> -serge
Great, I didn't think of that one before! I thought that was it, but,
unfortunately, I ran sha1sum on VLET1 and VLET3's copies, and both give
the same checksum.
I really really don't understand this... Is there some 'magic' associated
with qcow2 images, so you need to copy them in a special way? But since
the sha1sums are identical...
The funny thing is, most of these images were VMWare images which I
converted. They were first stored on other systems, and I could copy the
qcow2 images to VLET1 and they all worked fine. But now it seems
impossible to move them...
Kind regards,
Jürgen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-server/attachments/20110314/0eec2e4f/attachment.html>
More information about the ubuntu-server
mailing list