You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by John Skinner <jo...@appcore.com> on 2014/05/20 16:43:13 UTC
XenServer Snapshots
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.skinner@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.