openstack team mailing list archive

[<masumotok@xxxxxxxxxxxxx>]

Thanks for your response, Brian and Jay!

Response inline..

> (There is a summary at the bottom!)
> 
> Jay/Kei/Everyone,
> 
> I thought the exact same thing but I had completely forgotten to respond.
> 
> The term 'snapshot', as it is currently being used IMO is incorrect and/or
> misleading. Perhaps it's a burden of knowledge, but I start equating anything
> generated by 'snapshot' as being analogous to an LVM snapshot. A snapshot is
> taken (either automatically or manually) because you want to preserve the
> contents of that image/system in that exact moment in time.
> 
> For example, snapshot a system before doing an upgrade so that rollback is
> as easy as rebooting using the base image. In this case the snapshot is nothing
> but a temporary disk buffer which is thrown away once you either decide that
> the upgrade worked or once you roll back.
> 
> Snapshots, in LVM are not meant to be kept around forever, and will 'expire'
> once the diff has reached a predetermined size. For example, you might create
> an LVM snapshot that is 1G. In that case, the snapshot would be active and
> receiving all writes destined to  the base volume until 1G has been written.
> At that point the snapshot is deactivated and writes go back to the base volume.
> 
> (Warning, not expert on LVM or QEMU, so please correct me on anything!)
> 
> Snapshots, in OpenStack, start out as traditional snapshots by using libvirt
> to create a true COW snapshot of the domain (as described above when I was
> talking about LVM). However, once the snapshot is taken, the image is then
> converted from qcow2 to a raw image. This means that *technically* you've made
> a copy of the existing image rather than a technically traditional snapshot.
> Part of me wants to call it a snapshot...albeit an expensive one.
> 
> After looking at the code, I don't think that we're destroying the snapshots
> via libvirt, so we might actually be creating true COW snapshots *and* faux
> full-copy snapshots. If that's the case there are going to be big penalties
> down the line as QEMU snapshots don't expire like their LVM counterparts.
> 
> 
> Summary/TLDR/IMOs:
> 
> -We are making snapshots, but not the type of snapshots that I think of right
> away.
> 
> -This method should be called image_save, disk_save, image_copy, disk_copy,
> or something more obvious. Great call their Kei!
> 
> -Snapshot should be kept, but altered to be a true COW snapshot.
> 
> -This is not just a libvirt issue, but XenAPI as well. Both drivers explicitly
> ignore COW functionality and do true disk copies.

I agree it is not only libvirt issue. If I am allowed to make patch, I'll do it(just replace method name, I believe). If someone feels uncomfortable , just adding some comments such as "snapshot here means... " is still good.

Also, as you mentioned, snapshot() in libvirt driver is convert from qcow2 to raw. I think qcow2 should be converted and uploaded as qcow2 or configurable, not "any image format is convert to raw". Otherwise, users realize image format is changed against their will. this is one of essential issue here - I want to make change if I am allowed to.

> -I see more value in true disk copies (the way we're doing it now), but I think
> COW snapshot + rollback functionality in drivers would be wicked awesome.
> 
100% Agreed. both image_save() and "snapshot + rollback functionality" is useful to nova users. (I can raise my hand to be volunteer if there are no one!)

> -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 :).

Thanks!


> 
> 
> -Brian
> 
> 
> -----Original Message-----
> From: "Jay Pipes" <jaypipes@xxxxxxxxx>
> Sent: Sunday, June 26, 2011 1:41pm
> To: masumotok@xxxxxxxxxxxxx, "vishvananda" <vishvananda@xxxxxxxxx>, "Soren
> Hansen" <soren.hansen@xxxxxxxxxxxxx>
> Cc: openstack@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Openstack] snapshot question
> 
> Ping. I think Kei's suggestion below is a good one... can someone knowledgeable
> with qemu respond?
> 
> -jay
> 
> On Tue, Jun 21, 2011 at 9:55 PM,  <masumotok@xxxxxxxxxxxxx> wrote:
> > Hello,
> >
> > I have a question about nova.virt.libvirt.connection.snapshot().
> > In my understandings, this method is currently used for saving(cloning) VM
> images and upload cloned image to Glance.
> >
> > Q1) Is there any reason why method name is snapshot() , not image_create
> or image_save or something?
> > I am just wondering if there will be additional work to add
> > VMWare-like snapshotting(meaning taking snapshot many times, user can
> > select one of them, and VM state can get back...)
> >
> > Q2) In current implementation original disk size is bigger after nova
> image-create. Please see below.
> >
> > [before image-create]
> > root@testhost:/opt/openstack/instances/instance-00000015# ls -l total
> > 151580
> > -rw-r----- 1 libvirt-qemu kvm       2889 2011-06-23 11:53 console.log
> > -rw-r--r-- 1 libvirt-qemu kvm  155189248 2011-06-23 11:56 disk
> > -rw-r--r-- 1 libvirt-qemu kvm    6291968 2011-06-23 11:50 disk.local
> > -rw-r--r-- 1 root         root      1728 2011-06-23 11:49 libvirt.xml
> >
> > [after image-create]
> > root@testhost:/opt/openstack/instances/instance-00000015# ls -l total
> > 3734664
> > -rw-r----- 1 libvirt-qemu kvm        2889 2011-06-23 11:53 console.log
> > -rw-r--r-- 1 libvirt-qemu kvm     2011-06-23 13:02 disk
> > -rw-r--r-- 1 root         root     197120 2011-06-23 12:11 disk.diff
> > -rw-r--r-- 1 libvirt-qemu kvm    10486272 2011-06-23 12:59 disk.local
> > -rw-r--r-- 1 root         root       1728 2011-06-23 11:49 libvirt.xml
> >
> > That means if any sensitive users do "nova-image create", compute node
> original image size is bigger and compute node disk size available is
> decreasing. So I would like to ask, the below operation is inappropriate here?
> > a) taking diff backup: qemu-img create -b disk -f qcow2 disk.diff
> > b) convert : qemu-img convert -f -O qcow2 disk.diff new_img
> >
> > Disk size is not bigger this way. In addition, if --use_cow_image=False,
> this way can be used.
> > Any opinion on this? If I misunderstand somehow, please let me know.
> >
> > Regards,
> > Kei
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack Post to     :
> > openstack@xxxxxxxxxxxxxxxxxxx Unsubscribe :
> > https://launchpad.net/~openstack More help   :
> > https://help.launchpad.net/ListHelp
> >
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
> This email may include confidential information. If you received it in error,
> please delete it.
>