Thanks for the links, they actually help a lot to get a better understanding.
So what I'm observing now is how it seems designed to be, but
unfortunately, it does not explain what I described in the first
message. I have tried several different images to reproduce this, but
without success. So I guess I'll have to live with it until this issue
comes up again.
It's also kind of difficult when I'm trying to differentiate between
rbd snapshots, rbd clones and nova snapshots, maybe this is the main
problem here.
Thank you for your help, I appreciate it!
Regards,
Eugen
Zitat von Alexey Sheplyakov <asheplyakov@xxxxxxxxxxxx>:
Eugen,
It seems as if the nova snapshot creates a full image (flattened) so it
doesn't depend on the base image.
As far as I understand a (nova) snapshot is actually a standalone image (so
you can boot it, convert to a volume, etc).
The snapshot method of nova libvirt driver invokes the direct_snapshot:
https://github.com/openstack/nova/blob/8049a993471feb117efde002c55ad45650abb845/nova/virt/libvirt/driver.py#L1476-L1486
which for rbd backend snapshots the VM disk, clones, flattens it, and makes
the 'snap' snapshot in the flattened (rbd) image
so the result looks as if this image has been uploaded to glance:
https://github.com/openstack/nova/blob/a41ee43792a2b37c7e1fd12700a8b2fd3ccba4ec/nova/virt/libvirt/imagebackend.py#L971-L990
Best regards,
Alexey
On Fri, Sep 2, 2016 at 4:11 PM, Eugen Block <eblock@xxxxxx> wrote:
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.taylor@xxxxxxxxxxxxxxxx>:
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:eblock@xxxxxx]
Sent: Thursday, September 1, 2016 9:06 AM
To: Steve Taylor <steve.taylor@xxxxxxxxxxxxxxxx>
Cc: ceph-users@xxxxxxxxxxxxxx
Subject: Re: 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.taylor@xxxxxxxxxxxxxxxx>:
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-bounces@xxxxxxxxxxxxxx] On
Behalf Of Eugen Block
Sent: Thursday, September 1, 2016 6:51 AM
To: ceph-users@xxxxxxxxxxxxxx
Subject: 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 : eblock@xxxxxx
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@xxxxxxxxxxxxxx
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 : eblock@xxxxxx
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 : eblock@xxxxxx
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@xxxxxxxxxxxxxx
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 : eblock@xxxxxx
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@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
