[sheepdog-users] [sheepdog] Impossible to convert a qcow2 to a vdi

[Liu Yuan]

On Mon, Aug 11, 2014 at 10:54:46AM +0900, Hitoshi Mitake wrote:
> At Fri, 8 Aug 2014 16:28:22 +0200,
> Valerio Pachera wrote:
> > 
> > [1  <multipart/alternative (7bit)>]
> > [1.1  <text/plain; UTF-8 (7bit)>]
> > Sheepdog daemon version 0.8.0_293_g56a9dea
> > 
> > qemu-img convert -f qcow2 squeeze.qcow2 sheepdog:test
> > qemu-img: cannot get vdi info, VDI isn't locked, test 0
> > qemu-img: Could not open 'sheepdog:test': Input/output error
> > 
> > 
> > sheep.log
> > 
> > Aug 08 16:22:28   INFO [main] md_add_disk(343) /mnt/sheep/0, vdisk nr 220,
> > total disk 1
> > Aug 08 16:22:28 NOTICE [main] get_local_addr(522) found IPv4 address
> > Aug 08 16:22:28   INFO [main] send_join_request(982) IPv4 ip:192.168.10.5
> > port:7000
> > Aug 08 16:22:28 NOTICE [main] nfs_init(607) nfs server service is not
> > compiled
> > Aug 08 16:22:28   INFO [main] check_host_env(493) Allowed open files
> > 1024000, suggested 6144000
> > Aug 08 16:22:28   INFO [main] main(944) sheepdog daemon (version
> > 0.8.0_293_g56a9dea) started
> > Aug 08 16:23:44   INFO [main] rx_main(830) req=0x3705d50, fd=23, client=
> > 127.0.0.1:35162, op=NEW_VDI, data=(not string)
> > Aug 08 16:23:44   INFO [main] tx_main(882) req=0x3705d50, fd=23, client=
> > 127.0.0.1:35162, op=NEW_VDI, result=16
> > Aug 08 16:23:56   INFO [main] rx_main(830) req=0x3705d50, fd=23, client=
> > 127.0.0.1:35164, op=MAKE_FS, data=(not string)
> > Aug 08 16:23:56   INFO [main] tx_main(882) req=0x3705d50, fd=23, client=
> > 127.0.0.1:35164, op=MAKE_FS, result=00
> > Aug 08 16:23:58   INFO [main] rx_main(830) req=0x3705d50, fd=23, client=
> > 127.0.0.1:35165, op=NEW_VDI, data=(not string)
> > Aug 08 16:23:58   INFO [main] tx_main(882) req=0x3705d50, fd=23, client=
> > 127.0.0.1:35165, op=NEW_VDI, result=00
> > Aug 08 16:23:58   INFO [main] cluster_lock_vdi_main(1347) node: IPv4
> > ip:192.168.10.5 port:7000 is locking VDI (type: shared): 7c2b25
> > Aug 08 16:23:58   CRIT [main] vdi_lock(440) unknown type of locking: 0
> > Aug 08 16:23:58  ERROR [main] cluster_lock_vdi_main(1350) locking
> > 7c2b25failed
> > Aug 08 16:24:04   INFO [main] rx_main(830) req=0x3705d50, fd=23, client=
> > 127.0.0.1:35170, op=MAKE_FS, data=(not string)
> > Aug 08 16:24:04   INFO [main] tx_main(882) req=0x3705d50, fd=23, client=
> > 127.0.0.1:35170, op=MAKE_FS, result=00
> > Aug 08 16:24:06   INFO [main] rx_main(830) req=0x3705d50, fd=23, client=
> > 127.0.0.1:35171, op=NEW_VDI, data=(not string)
> > Aug 08 16:24:06   INFO [main] tx_main(882) req=0x3705d50, fd=23, client=
> > 127.0.0.1:35171, op=NEW_VDI, result=00
> > Aug 08 16:24:07   INFO [main] cluster_lock_vdi_main(1347) node: IPv4
> > ip:192.168.10.5 port:7000 is locking VDI (type: shared): 7c2b25
> > Aug 08 16:24:07   CRIT [main] vdi_lock(440) unknown type of locking: 0
> > Aug 08 16:24:07  ERROR [main] cluster_lock_vdi_main(1350) locking
> > 7c2b25failed
> > 
> > Do I open a bug in launchpad?
> 
> This problem will be solved in the master branch of QEMU soon. You
> don't have to open a bug in launchpad.
> 

Unfortuntely, we can't fix the already distributed QEMU, this is why we try our
best to keep backward compatibility and at the cost of ugly code sometimes.

Image that users of ubuntu, debian, fedora once update the sheepdog binary, then
it can't work anymore, this would be huge compliaints. You can't expect all the
users to update QEMU binary because

- many distributions maintain a stable branch, which consider the backward
  compatiblity in the first place. So you'll never expect a QEMU master
  break-compatilibty-patch backport to their stable branch.

- update QEMU means to stop running VM. This would be unacceptable for service
  provider.

So let's fix sheep. So make '0' as a lock type and grab the lock for '0' to keep
backward compatibility.

Thanks
Yuan