troubles copying qcow2 VM images

[jurgen.depicker at let.be]

 > 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>