Open Stack

On Wed, Jun 29, 2011 at 02:36:08PM +0900, masumotok at nttdata.co.jp wrote:
> Hello, 
> Thanks for your opinion!
> 
> > > > -Kei, as to Q2 in your original message...I have absolutely no idea
> > > > why the image is bigger, but hopefully one of these days I'll get
> > > > time to get back into the libvirt code and help you out! :)
> > >
> > > This is another essential issue here. I just wrote "when I call snapshot()
> > once, what's happen original image" at the previous e-mail, but when we try
> > to call snapshot() over and over again, original disk image is bigger and bigger.
> > I have no idea how eventually bigger disk image is. I think the reason why
> > image size is bigger is that snapshot is included into original image .......
> > Anyway, I am waiting you get back :).
> > 
> > Although I'm not familiar with libvirt and not an export of qemu block layer.
> > Qemu savevm (I'm assuming libvirt maps it to qemu savevm) takes snapshot of
> > not only disk image, but also guest RAM. Thus guest can re-execute at the point
> > of snapshot.
> > The difference is guest RAM size, I think.
> Savevm() is good idea. It is currently used as suspend() in libvirt driver, since calling savevm() terminates instances. (IMO, this behavior is matched as the concept of suspend). Regarding to snapshotting instances(not image_save), if nobody cares that instance is terminated after snapshotting(caution: I mean snapshotting, not saving image), I feel savevm() might be a solution.

I'm afraid we are not on same page. What API layer are you talking about?
I suppose we're talking about totally different thing.

What I ment by qemu savevm is the command which is typed on qemu command
line. Whose prompt is "(qemu)". qemu savevm doesn't terminates the instance,
and the guest continues executing after savevm.
By looking at libvirt code I confirmed that libvirt API
virDomainSnapshotCreateXML() eventually issues qemu command, savevm,
on the qemu monitor(HMP).


> > Regarding to freeing snapshots of qcow2, major file systems don't provide a
> > way to free once-allocated-blocks except truncate.
> > So qcow2 doesn't have a way to free unnecessary blocks.
> > You may need btrfs or modern advanced file systems that supports punching hole
> > and discard.
> Btrfs sounds good. I'm gonna check it.

Ah, right now qemu only supports discard for XFS. You needs to enable
XFS support at configure time. I don't know about distro-patched qemu/kvm.
-- 
yamahata