You can use 'rbd -p images --image 417ef4b6-b4b2-4e94-9ae6-ef7a4ee3e560 info' 
to see the parentage of your cloned RBD from Ceph's perspective. It seems like 
that could be useful at various times throughout this test to determine what 
glance is doing under the covers.


________________________________

[cid:imagebc1a87.JPG@004db369.419de911]<https://storagecraft.com>       Steve 
Taylor | Senior Software Engineer | StorageCraft Technology 
Corporation<https://storagecraft.com>
380 Data Drive Suite 300 | Draper | Utah | 84020
Office: 801.871.2799 |

________________________________

If you are not the intended recipient of this message or received it 
erroneously, please notify the sender and delete it, together with any 
attachments, and be advised that any dissemination or copying of this message 
is prohibited.

________________________________

-----Original Message-----
From: Eugen Block [mailto:ebl...@nde.ag]
Sent: Friday, September 2, 2016 7:12 AM
To: Steve Taylor <steve.tay...@storagecraft.com>
Cc: ceph-users@lists.ceph.com
Subject: Re: [ceph-users] Turn snapshot of a flattened snapshot into regular 
image

> Something isn't right. Ceph won't delete RBDs that have existing
> snapshots

That's what I thought, and I also noticed that in the first test, but not in 
the second.

> The clone becomes a cinder device that is then attached to the nova instance.

This is one option, but I don't use it. nova would create a cinder volume if I 
executed "nova boot --block-device ...", but I don't, so there's no cinder 
involved.
I'll try to provide some details from openstack and ceph, maybe that helps to 
find the cause.

So I created a glance image
control1:~ #  glance image-list | grep Test
| 87862452-5872-40c9-b657-f5fec0d105c5 | Test2-SLE12SP1

which automatically gets one snapshot in rbd and has no children yet, because 
no VM has been launched yet:

ceph@node1:~/ceph-deploy> rbd -p images --image
87862452-5872-40c9-b657-f5fec0d105c5 snap ls
SNAPID NAME    SIZE
   429 snap 5120 MB

ceph@node1:~/ceph-deploy> rbd -p images --image
87862452-5872-40c9-b657-f5fec0d105c5 children --snap snap 
ceph@node1:~/ceph-deploy>

Now I boot a VM

nova boot --flavor 2 --image 87862452-5872-40c9-b657-f5fec0d105c5
--nic net-id=4eafc4da-a3cd-4def-b863-5fb8e645e984 vm1

with a resulting instance_uuid=0e44badb-8a76-41d8-be43-b4125ffc6806
and see this in ceph:

ceph@node1:~/ceph-deploy> rbd -p images --image
87862452-5872-40c9-b657-f5fec0d105c5 children --snap snap 
images/0e44badb-8a76-41d8-be43-b4125ffc6806_disk

So I have the base image with a snapshot, and based on this snapshot a child 
which is the disk image for my instance. There is no cinder
volume:

control1:~ #  cinder list
+----+--------+------+------+-------------+----------+-------------+
| ID | Status | Name | Size | Volume Type | Bootable | Attached to |
+----+--------+------+------+-------------+----------+-------------+
+----+--------+------+------+-------------+----------+-------------+

Now I create a snapshot of vm1 (I removed some lines to focus on the IDs):

control1:~ #  nova image-show 417ef4b6-b4b2-4e94-9ae6-ef7a4ee3e560
+-------------------------+------------------------------------------------------------------+
| Property                | Value
                      |
+-------------------------+------------------------------------------------------------------+
| id                      | 417ef4b6-b4b2-4e94-9ae6-ef7a4ee3e560
                      |
| metadata base_image_ref | 87862452-5872-40c9-b657-f5fec0d105c5
                      |
| metadata image_type     | snapshot
                      |
| metadata instance_uuid  | 0e44badb-8a76-41d8-be43-b4125ffc6806
                      |
| name                    | snap-vm1
                      |
| server                  | 0e44badb-8a76-41d8-be43-b4125ffc6806
                      |
| status                  | ACTIVE
                      |
| updated                 | 2016-09-02T12:51:28Z
                      |
+-------------------------+------------------------------------------------------------------+

In rbd there is a new object now, without any children:

ceph@node1:~/ceph-deploy> rbd -p images --image
417ef4b6-b4b2-4e94-9ae6-ef7a4ee3e560 snap ls
SNAPID NAME     SIZE
   443 snap 20480 MB
ceph@node1:~/ceph-deploy> rbd -p images --image
417ef4b6-b4b2-4e94-9ae6-ef7a4ee3e560 children --snap snap 
ceph@node1:~/ceph-deploy>

And there's still no cinder volume ;-)
After removing vm1 I can delete the base image and snap-vm1:

control1:~ #  nova delete vm1
Request to delete server vm1 has been accepted.
control1:~ #  glance image-delete 87862452-5872-40c9-b657-f5fec0d105c5
control1:~ #
control1:~ #  glance image-delete 417ef4b6-b4b2-4e94-9ae6-ef7a4ee3e560

I did not flatten any snapshot yet, this is really strange! It seems as if the 
nova snapshot creates a full image (flattened) so it doesn't depend on the base 
image. But I didn't change any configs or anything, I really don't understand 
it. Please let me know if any additional information would help on this.

Regards,
Eugen


Zitat von Steve Taylor <steve.tay...@storagecraft.com>:

> Something isn't right. Ceph won't delete RBDs that have existing
> snapshots, even when those snapshots aren't protected. You can't
> delete a snapshot that's protected, and you can't unprotect a snapshot
> if there is a COW clone that depends on it.
>
> I'm not intimately familiar with OpenStack, but it must be deleting A
> without any snapshots. That would seem to indicate that at the point
> of deletion there are no COW clones of A or that any clone is no
> longer dependent on A. A COW clone requires a protected snapshot, a
> protected snapshot can't be deleted, and existing snapshots prevent
> RBDs from being deleted.
>
> In my experience with OpenStack, booting a nova instance from a glance
> image causes a snapshot to be created, protected, and cloned on the
> RBD for the glance image. The clone becomes a cinder device that is
> then attached to the nova instance. Thus you're able to modify the
> contents of the volume within the instance. You wouldn't be able to
> delete the glance image at that point unless the cinder device were
> deleted first or it was flattened and no longer dependent on the
> glance image. I haven't performed this particular test. It's possible
> that OpenStack does the flattening for you in this scenario.
>
> This issue will likely require some investigation at the RBD level
> throughout your testing process to understand exactly what's
> happening.
>
>
> ________________________________
>
> [cid:image5feece.JPG@7cacebfd.42833f4d]<https://storagecraft.com>
>    Steve Taylor | Senior Software Engineer | StorageCraft Technology
> Corporation<https://storagecraft.com>
> 380 Data Drive Suite 300 | Draper | Utah | 84020
> Office: 801.871.2799
>
> ________________________________
>
> If you are not the intended recipient of this message or received it
> erroneously, please notify the sender and delete it, together with
> any attachments, and be advised that any dissemination or copying of
> this message is prohibited.
>
> ________________________________
>
> -----Original Message-----
> From: Eugen Block [mailto:ebl...@nde.ag]
> Sent: Thursday, September 1, 2016 9:06 AM
> To: Steve Taylor <steve.tay...@storagecraft.com>
> Cc: ceph-users@lists.ceph.com
> Subject: Re: [ceph-users] Turn snapshot of a flattened snapshot into
> regular image
>
> Thanks for the quick response, but I don't believe I'm there yet ;-)
>
>> cloned the glance image to a cinder device
>
> I have configured these three services (nova, glance, cinder) to use
> ceph as storage backend, but cinder is not involved in this process
> I'm referring to.
>
> Now I wanted to reproduce this scenario to show a colleague, and
> couldn't because now I was able to delete image A even with a
> non-flattened snapshot! How is that even possible?
>
> Eugen
>
>
>
> Zitat von Steve Taylor <steve.tay...@storagecraft.com>:
>
>> You're already there. When you booted ONE you cloned the glance image
>> to a cinder device (A', separate RBD) that was a COW clone of A.
>> That's why you can't delete A until you flatten SNAP1. A' isn't a full
>> copy until that flatten is complete, at which point you're able to
>> delete A.
>>
>> SNAP2 is a second snapshot on A', and thus A' already has all of the
>> data it needs from the previous flatten of SNAP1 to allow you to
>> delete SNAP1. So SNAP2 isn't actually a full extra copy of the data.
>>
>>
>> ________________________________
>>
>> [cid:imagef01287.JPG@753835fa.45a0b2c0]<https://storagecraft.com>
>>    Steve Taylor | Senior Software Engineer | StorageCraft Technology
>> Corporation<https://storagecraft.com>
>> 380 Data Drive Suite 300 | Draper | Utah | 84020
>> Office: 801.871.2799
>>
>> ________________________________
>>
>> If you are not the intended recipient of this message or received it
>> erroneously, please notify the sender and delete it, together with
>> any attachments, and be advised that any dissemination or copying of
>> this message is prohibited.
>>
>> ________________________________
>>
>> -----Original Message-----
>> From: ceph-users [mailto:ceph-users-boun...@lists.ceph.com] On
>> Behalf Of Eugen Block
>> Sent: Thursday, September 1, 2016 6:51 AM
>> To: ceph-users@lists.ceph.com
>> Subject: [ceph-users] Turn snapshot of a flattened snapshot into
>> regular image
>>
>> Hi all,
>>
>> I'm trying to understand the idea behind rbd images and their
>> clones/snapshots. I have tried this scenario:
>>
>> 1. upload image A to glance
>> 2. boot instance ONE from image A
>> 3. make changes to instance ONE (install new package) 4. create
>> snapshot SNAP1 from ONE 5. delete instance ONE 6. delete image A
>>    deleting image A fails because of existing snapshot SNAP1 7.
>> flatten snapshot SNAP1 8. delete image A
>>    succeeds
>> 9. launch instance TWO from SNAP1
>> 10. make changes to TWO (install package) 11. create snapshot SNAP2
>> from TWO 12. delete TWO 13. delete SNAP1
>>     succeeds
>>
>> This means that the second snapshot has the same (full) size as the
>> first. Can I manipulate SNAP1 somehow so that snapshots are not
>> flattened anymore and SNAP2 becomes a cow clone of SNAP1?
>>
>> I hope my description is not too confusing. The idea behind this
>> question is, if I have one base image and want to adjust that image
>> from time to time, I don't want to keep several versions of that
>> image, I just want one. But this way i would lose the protection
>> from deleting the base image.
>>
>> Is there any config option in ceph or Openstack or anything else I
>> can do to "un-flatten" an image? I would assume that there is some
>> kind of flag set for that image. Maybe someone can point me to the
>> right direction.
>>
>> Thanks,
>> Eugen
>>
>> --
>> Eugen Block                             voice   : +49-40-559 51 75
>> NDE Netzdesign und -entwicklung AG      fax     : +49-40-559 51 77
>> Postfach 61 03 15
>> D-22423 Hamburg                         e-mail  : ebl...@nde.ag
>>
>>         Vorsitzende des Aufsichtsrates: Angelika Mozdzen
>>           Sitz und Registergericht: Hamburg, HRB 90934
>>                   Vorstand: Jens-U. Mozdzen
>>                    USt-IdNr. DE 814 013 983
>>
>> _______________________________________________
>> ceph-users mailing list
>> ceph-users@lists.ceph.com
>> http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
>
>
>
> --
> Eugen Block                             voice   : +49-40-559 51 75
> NDE Netzdesign und -entwicklung AG      fax     : +49-40-559 51 77
> Postfach 61 03 15
> D-22423 Hamburg                         e-mail  : ebl...@nde.ag
>
>         Vorsitzende des Aufsichtsrates: Angelika Mozdzen
>           Sitz und Registergericht: Hamburg, HRB 90934
>                   Vorstand: Jens-U. Mozdzen
>                    USt-IdNr. DE 814 013 983



--
Eugen Block                             voice   : +49-40-559 51 75
NDE Netzdesign und -entwicklung AG      fax     : +49-40-559 51 77
Postfach 61 03 15
D-22423 Hamburg                         e-mail  : ebl...@nde.ag

        Vorsitzende des Aufsichtsrates: Angelika Mozdzen
          Sitz und Registergericht: Hamburg, HRB 90934
                  Vorstand: Jens-U. Mozdzen
                   USt-IdNr. DE 814 013 983

_______________________________________________
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com

Reply via email to