On 2010/01/08 7:09, Piavlo wrote: > Hi, > > Snapshot works but cloning fails with current master branch: > > fire-srv4 ~ # qemu-img snapshot -c name sheepdog:zopa1 > sd_claim 1492: zopa1 > sd_release 1533: zopa1 > sd_close 1478: zopa1 > fire-srv4 ~ # qemu-img create -b sheepdog:zopa1 -f sheepdog zopa2 > sd_close 1478: zopa2 > Formatting 'zopa2', fmt=sheepdog size=5368709120 backing_file='zopa2' > qemu-img: Error while formatting > fire-srv4 ~ # shepherd info -t vdi > 40000 : zopa1 5120 MB (allocated: 4068 MB, shared: 0 MB), 2010-01-07 > 23:14:25, tag: 0, not current > 80000 : zopa1 5120 MB (allocated: 0 MB, shared: 4068 MB), 2010-01-07 > 23:30:01, tag: 4b465259, current > fire-srv4 ~ # The usage to create a clone image is as follows: qemu-img create -b sheepdog:[base vdiname]:[tag id] -f sheepdog [new vdiname] Please note that you can create a clone image only from a snapshot vdi (read only image). When creating clone from a snapshot image, you need to specify the vdi tag id because base vdi may have more than one snapshots and qemu-image need to know which image you want to create clone from. In your case, $ qemu-img create -b sheepdog:zopa1:0 -f sheepdog zopa2 will work, probably. > Also I am able to boot the snapshot VM and login into it, but i gets > stuck after a short time as well as all shepherd > commands on all nodes. After killing the VM and restarting all the > sheepdogs - they can communicate again with each other > and see all the previously existing images correctly. It seems to be a bug of sheepdog. I'll fix it. > Is it possible to boot concurrently both the image and it's snapshot? > and in which mode ie. read/write? No, it isn't. The image will be locked if you start one of them. Though snapshot images are read-only, you can boot from a snapshot image as writable mode because sheepdog automatically generates a new vdi when VM writes data to the snapshot image. > Same question for an image and it's clone. Yes, you can. Regards, Kazutaka Morita |