At Sat, 2 Oct 2010 18:07:18 +0200, Floris Bos wrote: > > Hi, > > On Saturday, October 02, 2010 01:42:43 pm MORITA Kazutaka wrote: > > Floris Bos wrote: > > > Hi, > > > > > > I'm writing an alternative sheepdog client, and am looking for a way to > > > delete a (temporary) snapshot. > > > > Great! What kind of client are you writing? > > A simple libfuse-based client, that allows you to access the sheepdog VDIs as > regular files in the file system. > That way you can use legacy tools like rsync to backup your virtual machines, Sounds good! It would also be helpful for debugging a sheepdog server. > e.g.: > > == > root at vpser:~# collie vm list > Name |Vdi size |Allocated| Shared | Status > ----------------+---------+---------+---------+------------ > vm1 | 9.8 GB| 964 MB| 0.0 MB| not running > vm2 | 9.8 GB| 1.9 GB| 0.0 MB| not running > root at vpser:~# fusedog /mnt > root at vpser:~# ls -l /mnt > total 0 > -rw------- 1 root root 10485760000 2010-10-02 17:34 vm1 > -rw------- 1 root root 10485760000 2010-10-02 17:35 vm2 > root at vpser:~# rsync -avzS /mnt max at name-of-my-backup-server:/home/max/vmbackup > Password: > sending incremental file list > created directory /home/max/vmbackup > mnt/ > mnt/vm1 > mnt/vm2 > == > > Would like to add automatic snapshot support so that it can create (temporary > read-only) snapshots to backup VMs that are currently running. > > > > > I noticed that there is a SD_OP_DEL_VDI in include/sheep.h > > > But I cannot find a similar operation in include/sheepdog_proto.h > > > > > > > > > Is it safe for an external program to simply send SD_OP_DEL_VDI for > > > deleting snapshots? > > > > Yes, it should be safe. Indeed, SD_OP_DEL_VDI should be in > > include/sheepdog_proto.h because we need to support deleting snapshots > > from qemu-img commands in future. > > > > See vdi_delete() in collie/collie.c. It would tell you how to use a > > SD_OP_DEL_VDI operation. > > It seems that snapshot creation and deletion works differently than the way I > want to use them. > > After creating a snapshot, it looks like the newest vdi_id becomes the new > main vdi (as it is the only item without a "s" in the "vdi list"). Yes. Sheepdog makes the current vdi read-only (snapshot vdi), and creates a new vdi as a writable one (main vdi). > > == > max at vpser:~$ collie vm list > Name |Vdi size |Allocated| Shared | Status > ----------------+---------+---------+---------+------------ > test05b | 9.8 GB| 0.0 MB| 964 MB| not running > max at vpser:~$ collie vdi list > name id size used shared creation time vdi id > ------------------------------------------------------------------ > s test05b 1 9.8 GB 964 MB 0.0 MB 2010-09-27 18:40 662da4 > s test05b 2 9.8 GB 0.0 MB 964 MB 2010-10-02 16:42 662da5 > test05b 3 9.8 GB 0.0 MB 964 MB 2010-10-02 17:03 662da6 > == > > And if I use SD_OP_DEL_VDI to delete the newest vid in my client, "collie vm > list" returns empty. It seems that deleting the latest (non-snapshot) vdi doesn't work properly. 'collie vm list' should show the test05b vdi in this case. > > == > max at vpser:~$ collie vdi list > name id size used shared creation time vdi id > ------------------------------------------------------------------ > s test05b 1 9.8 GB 964 MB 0.0 MB 2010-09-27 18:40 662da4 > s test05b 2 9.8 GB 0.0 MB 964 MB 2010-10-02 16:42 662da5 > max at vpser:~$ collie vm list > Name |Vdi size |Allocated| Shared | Status > ----------------+---------+---------+---------+------------ > == > > > The command I use to create a snapshot looks like this: > > == > memcpy(buf, parent->name, sizeof(buf)); > struct sd_vdi_req req = { > .proto_ver = SD_PROTO_VER, > .opcode = SD_OP_NEW_VDI, > .base_vdi_id = parent->vdi_id, > .flags = SD_FLAG_CMD_WRITE, > .data_length = sizeof(buf), > .vdi_size = parent->vdi_size, > .snapid = 1 > }; > == > > (where "parent" is the "struct sheepdog_inode" of the original VDI) > > Is there any option I can use to tell sheepdog not to promote the new snapshot > as main VDI? > Currently, no. However, I think it would be better to reserve 0 as a snap_id of the latest vdi (main vdi). In this case, taking snapshots doesn't change a snapshot id of the latest vdi. The id is fixed to zero always. Is this the behavior you want? Thanks, Kazutaka |