All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wido den Hollander <wido@42on.com>
To: Andrey Korolyov <andrey@xdel.ru>
Cc: ceph-devel <ceph-devel@vger.kernel.org>
Subject: Re: libvirt: Removing RBD volumes with snapshots, auto purge or not?
Date: Tue, 20 Aug 2013 21:01:01 +0200	[thread overview]
Message-ID: <5213BCED.7010400@42on.com> (raw)
In-Reply-To: <CABYiri-Z_9sW155BpOzHsSOAfaBmdzW=1DetXVD3-Mz5ESbPdw@mail.gmail.com>

On 08/20/2013 05:43 PM, Andrey Korolyov wrote:
> On Tue, Aug 20, 2013 at 7:36 PM, Wido den Hollander <wido@42on.com> wrote:
>> Hi,
>>
>> The current [0] libvirt storage pool code simply calls "rbd_remove" without
>> anything else.
>>
>> As far as I know rbd_remove will fail if the image still has snapshots, you
>> have to remove those snapshots first before you can remove the image.
>>
>> The problem is that libvirt's storage pools do not support listing
>> snapshots, so we can't integrate that.
>>
>> Libvirt however has a flag you can pass down to tell you want the device to
>> be zeroed.
>>
>> The normal procedure is that the device is filled with zeros before actually
>> removing it.
>>
>> I was thinking about "abusing" this flag to use it as a snap purge for RBD.
>>
>> So a regular volume removal will call only rbd_remove, but when the flag
>> VIR_STORAGE_VOL_DELETE_ZEROED is passed it will purge all snapshots prior to
>> calling rbd_remove.
>>
>> Another way would be to always purge snapshots, but I'm afraid that could
>> make somebody very unhappy at some point.
>>
>> Currently "virsh" doesn't support flags, but that could be fixed in a
>> different patch.
>>
>> Does my idea sound sane?
>>
>> [0]:
>> http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/storage/storage_backend_rbd.c;h=e3340f63f412c22d025f615beb7cfed25f00107b;hb=master#l407
>>
>> --
>> Wido den Hollander
>> 42on B.V.
>
> Hi Wido,
>
>
> You had mentioned not so long ago the same idea as I had about a year
> and half ago about placing memory dumps along with the regular
> snapshot in Ceph using libvirt mechanisms. That sounds pretty nice
> since we`ll have something other than qcow2 with same snapshot
> functionality but your current proposal does not extend to this.

Correct, since this is about the storage pool support, that is something 
completely different.

> Placing custom side hook seems much more expandable than putting snap
> purge into specific flag.
>

My proposal is a bit selfish, since I'm running into this with 
CloudStack. CloudStack now has a work-around for RBD since images could 
still have snapshots where other storage types are handled by libvirt.

I want to have it all handled by libvirt.

Wido

>>
>> Phone: +31 (0)20 700 9902
>> Skype: contact42on
>> --
>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
Wido den Hollander
42on B.V.

Phone: +31 (0)20 700 9902
Skype: contact42on

  reply	other threads:[~2013-08-20 19:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-20 15:36 libvirt: Removing RBD volumes with snapshots, auto purge or not? Wido den Hollander
2013-08-20 15:43 ` Andrey Korolyov
2013-08-20 19:01   ` Wido den Hollander [this message]
2013-08-20 21:12 ` Josh Durgin
2013-08-31 12:23   ` Wido den Hollander

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5213BCED.7010400@42on.com \
    --to=wido@42on.com \
    --cc=andrey@xdel.ru \
    --cc=ceph-devel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.