At Sun, 3 Oct 2010 23:09:34 +0200, Floris Bos wrote: > > Hi, > > On Sunday, October 03, 2010 05:55:02 pm you wrote: > > Yes. Sheepdog makes the current vdi read-only (snapshot vdi), and > > creates a new vdi as a writable one (main 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? > > That might work. > > > Basically what I need is a new read-only snapshot for use by my client, and no > changes to the current VDI. > After all, the current vdi may be in use by qemu, and qemu is totally unaware > of the snapshot I'm taking with my external program. > > So the original VDI ID must stay writable, as there is no way to signal qemu > that it should start using another id. > On second thought, we cannot avoid updating a vdi id when its snapshot is created. It is because a sheepdog client does copy-on-write based on its vdi id. So we need to use a savevm command from the qemu monitor to take a snapshot of the running VM. Currently, if you want to create a snapshot from the external program, you need to get a lock of the vdi to avoid corrupting running VMs, and if running VMs exist, you need to give up taking a snapshot... In future, I think we should implement a mechanism to notify the running client that an external program creates a snapshot. For example, if write accesses to snapshot objects return something like SD_RES_READONLY_OBJ, we can tell the client that it should update the vdi id. Thanks, Kazutaka |