Running CloudStack 4.1.1 I am trying to understand the relationship between
CloudStack’s snapshots that it keeps on secondary storage and what XenServer
sees in the VHD chain on the SR.
Here is my VHD chain with 3 VDIs; a base copy, a snapshot, and the active vdi
for the VM.
[root@pd1-xh4 ~]# vhd-util scan -f -p -m "VHD-*" -l
VG_XenStorage-10aa7b60-4709-a3c7-b54e-0ed4782d0e50
vhd=VHD-1c0f2d37-b9f3-4a76-b6a5-d5190ae0c1ec capacity=53687091200
size=37568380928 hidden=1 parent=none
vhd=VHD-15d1750e-df52-49d8-96dc-f2a2ae9a6244 capacity=53687091200
size=8388608 hidden=0 parent=VHD-1c0f2d37-b9f3-4a76-b6a5-d5190ae0c1ec
vhd=VHD-d28c7caa-ca6c-4f55-b344-5d10e370bef4 capacity=53687091200
size=53800337408 hidden=0 parent=VHD-1c0f2d37-b9f3-4a76-b6a5-d5190ae0c1ec
The snapshot policy in CloudStack has a daily, weekly, and monthly policy. The
daily is set to a retention policy of 3, and the weekly and monthly are both 1
I believe. Here is the last couple of days for snapshots from CloudStack on
that volume. It includes 4 daily (1 removed per policy) and a weekly.
mysql> select * from snapshots where id > 5236 and volume_id = 37316;
+------+----------------+------------+-----------+-----------+------------------+----------+--------------------------------------+---------------------------------------+---------------+------------------+-------------+---------------------+---------------------+--------------------------------------+----------+------------+--------------+-----------------+---------+--------------------------------------+-------+
| id | data_center_id | account_id | domain_id | volume_id | disk_offering_id
| status | path | name
| snapshot_type | type_description | size | created
| removed | backup_snap_id | swift_id |
sechost_id | prev_snap_id | hypervisor_type | version | uuid
| s3_id |
+------+----------------+------------+-----------+-----------+------------------+----------+--------------------------------------+---------------------------------------+---------------+------------------+-------------+---------------------+---------------------+--------------------------------------+----------+------------+--------------+-----------------+---------+--------------------------------------+-------+
| 5240 | 1 | 401 | 2 | 37316 | 142
| BackedUp | 27611a1b-88d3-48df-850f-9dab9c1146e9 |
Prod01_ROOT-35601_20140517110141 | 4 | DAILY |
53687091200 | 2014-05-17 11:01:41 | 2014-05-20 11:02:26 |
5489fb4d-96b2-4eb6-820b-cb9aab2bc207 | NULL | 4 | 0 |
XenServer | 2.2 | a93e2d52-ad8a-489d-9774-666deba94166 | NULL |
| 5244 | 1 | 401 | 2 | 37316 | 142
| BackedUp | 154893d8-d295-4c30-8d0d-576fb27c1c67 |
Prod01_ROOT-35601_20140518110141 | 4 | DAILY |
53687091200 | 2014-05-18 11:01:41 | NULL |
adeed41f-340e-4670-b6be-6c90d14f3a6d | NULL | 4 | 5240 |
XenServer | 2.2 | aa0448a1-6595-4e9f-a967-d8959cd6126c | NULL |
| 5252 | 1 | 401 | 2 | 37316 | 142
| BackedUp | 45743e2c-ea5c-4e31-964f-87999c1a05b4 |
Prod01_ROOT-35601_20140519084641 | 5 | WEEKLY |
53687091200 | 2014-05-19 08:46:41 | NULL |
261bb966-cff6-433b-a167-ac42e1b50d1e | NULL | 4 | 5244 |
XenServer | 2.2 | 9cf682fb-9388-4609-a120-1398e8d760b9 | NULL |
| 5254 | 1 | 401 | 2 | 37316 | 142
| BackedUp | 733fa701-61f0-40c5-b3db-4ef326470bd1 |
Prod01_ROOT-35601_20140519110141 | 4 | DAILY |
53687091200 | 2014-05-19 11:01:41 | NULL |
77b00655-8f74-4326-88d1-919c9ebaf587 | NULL | 4 | 5252 |
XenServer | 2.2 | 4ca9c52a-2952-48b1-8132-a15fb007a86b | NULL |
| 5259 | 1 | 401 | 2 | 37316 | 142
| BackedUp | 15d1750e-df52-49d8-96dc-f2a2ae9a6244 |
Prod01_ROOT-35601_20140520110141 | 4 | DAILY |
53687091200 | 2014-05-20 11:01:41 | NULL |
4ddf21eb-a862-4c6e-8971-69d79824d1e3 | NULL | 4 | 5254 |
XenServer | 2.2 | 88dbd606-aa27-4a98-ad18-33ffdd3cb92e | NULL |
+------+----------------+------------+-----------+-----------+------------------+----------+--------------------------------------+---------------------------------------+---------------+------------------+-------------+---------------------+---------------------+--------------------------------------+----------+------------+--------------+-----------------+---------+--------------------------------------+-------+
5 rows in set (0.00 sec)
We can see that the only snapshot of the 4 that are active for that volume that
XenServer sees inside of the VHD chain is the most recent ID 5259. I am
assuming that XenServer is coalescing the other 3 into the active volume during
a coalesce process (correct me if I am wrong here).
So if my theory there is correct, then that looks good. So we actually check
what is on secondary storage:
[root@pd1-xh4 37316]# ls
261bb966-cff6-433b-a167-ac42e1b50d1e.vhd
5489fb4d-96b2-4eb6-820b-cb9aab2bc207.vhd
adeed41f-340e-4670-b6be-6c90d14f3a6d.vhd
4ddf21eb-a862-4c6e-8971-69d79824d1e3.vhd
77b00655-8f74-4326-88d1-919c9ebaf587.vhd
All 5 of the snapshots exist on secondary storage. However, the one that
CloudStack has marked as removed is also still on secondary storage. When does
CloudStack decide it’s time to clean up secondary storage? According to the
database this snapshot is removed but it is clearly still there. Since
CloudStack is actually keeping deltas for XenServer on secondary storage I am
assuming that it needs to keep that snapshot that it claims is removed to be
able to coalesce them into a full snapshot once that threshold is reached. I am
just curious how long the snapshot will exist on secondary storage and when I
should expect it to be removed. Is this based on the number of snapshots to
keep between full snapshots setting in the global settings?
John Skinner
Senior Systems Administrator | Appcore
Office +1.800.735.7104 | Direct +1.515.612.7783
john.skin...@appcore.com | www.appcore.com
----------------------------------------------------------------------
The information in this message is intended for the named recipients only. It
may contain information that is privileged, confidential or otherwise protected
from disclosure. If you are not the intended recipient, you are hereby notified
that any disclosure, copying, distribution, or the taking of any action in
reliance on the contents of this message is strictly prohibited. If you have
received this e-mail in error, do not print it or disseminate it or its
contents. In such event, please notify the sender by return e-mail and delete
the e-mail file immediately thereafter. Thank you.
