cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <mike.tutkow...@solidfire.com>
Subject Re: Creating a backup of a hypervisor snapshot
Date Mon, 10 Nov 2014 20:39:48 GMT
I should test this out, but I'm thinking the current logic of "blindly"
deleting all previous hypervisor snapshots for a given volume will be
incompatible with the "Take VM Snapshot" feature (where a hypervisor
snapshot is created for the VM and every disk the VM is using).

If you've taken a VM Snapshot and then you do a Volume Snapshot, it would
seem the Volume Snapshot process will delete the hypervisor snapshot that
was taken as part of the "Take VM Snapshot" process. You would then only
find out about this when you tried to revert the VM back to that previous
state.

On Mon, Nov 10, 2014 at 1:33 PM, Mike Tutkowski <
mike.tutkowski@solidfire.com> wrote:

> So, interesting, I'm now using XenServer 6.2 (with the patches that
> CloudStack ends up calling XenServer 6.2.5).
>
> When I created a second snapshot/backup of my volume, another hypervisor
> snapshot was created and the data contained in the second hypervisor
> snapshot was copied to secondary storage (all as expected).
>
> At this point, CloudStack was, in fact, successful at deleting the
> original hypervisor snapshot (this was not the case when I was testing this
> on XenServer 6.1, if I recall).
>
> However, when I later deleted the volume, I noticed that the one
> hypervisor snapshot on primary storage remained there. I was expecting it
> to either be deleted immediately or be deleted in the background (it's been
> a day or so and that old hypervisor snapshot for the deleted volume remains
> on primary storage).
>
> Does anyone know off hand if the deletion of this hypervisor snapshot is
> supposed to happen right away or in the background?
>
> Thanks!
>
> On Fri, Nov 7, 2014 at 10:47 AM, Mike Tutkowski <
> mike.tutkowski@solidfire.com> wrote:
>
>> Let me look into this again. At the time, I was busy implementing some
>> other functionality when I came across what seemed like an existing issue
>> in our code.
>>
>> It is odd to me that old (hypervisor) snapshots never get deleted and the
>> code I copy/pasted in has the purpose of deleting those old snapshots, but
>> it never seems to work that way.
>>
>> On Fri, Nov 7, 2014 at 10:20 AM, Stephen Turner <
>> Stephen.Turner@citrix.com> wrote:
>>
>>> Mike, are you saying that XenCenter disagrees with xe? That doesn't seem
>>> right as they both get their info from the same API. Maybe XenCenter is
>>> looking at something subtly different.
>>>
>>> XenCenter is open source (https://github.com/xenserver/xenadmin), so
>>> you can consult the source to see what it's reporting. Or send a screenshot
>>> of what you're looking at and I can find the correct bit of source.
>>>
>>> --
>>> Stephen Turner
>>>
>>>
>>> -----Original Message-----
>>> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
>>> Sent: 04 November 2014 17:28
>>> To: dev@cloudstack.apache.org; Edison Su
>>> Subject: Creating a backup of a hypervisor snapshot
>>>
>>> Hi,
>>>
>>> The standard behavior when we take a snapshot of a volume on XenServer
>>> is to take a hypervisor snapshot of the volume and then copy this snapshot
>>> to secondary storage.
>>>
>>> We then try to delete all other hypervisor snapshots for this volume.
>>>
>>> I notice the process of deleting all other hypervisor snapshots for this
>>> volume never finds any snapshots to delete and our list of hypervisor
>>> snapshots continues to grow over time for the volume in question.
>>>
>>> (Below) Set<VDI> snapshots = volume.getSnapshots(conn); returns the
>>> empty set, so there's nothing to delete.
>>>
>>> However, if I look in XenCenter, I can see hypervisor snapshots for the
>>> volume in question.
>>>
>>> It appears we are passing in the correct info to this method, too.
>>>
>>> When I use xe, it confirms that the VDI that represents our volume does
>>> not have any snapshots, which seems odds.
>>>
>>>     protected boolean
>>> destroySnapshotOnPrimaryStorageExceptThis(Connection
>>> conn, String volumeUuid, String avoidSnapshotUuid) {
>>>
>>>         try {
>>>
>>>             VDI volume = getVDIbyUuid(conn, volumeUuid);
>>>
>>>             if (volume == null) {
>>>
>>>                 throw new InternalErrorException("Could not destroy
>>> snapshot on volume " + volumeUuid + " due to can not find it");
>>>
>>>             }
>>>
>>>             Set<VDI> snapshots = volume.getSnapshots(conn);
>>>
>>>             for (VDI snapshot : snapshots) {
>>>
>>>                 try {
>>>
>>>                     if
>>> (!snapshot.getUuid(conn).equals(avoidSnapshotUuid)) {
>>>
>>>                         snapshot.destroy(conn);
>>>
>>>                     }
>>>
>>>                 } catch (Exception e) {
>>>
>>>                     String msg = "Destroying snapshot: " + snapshot + "
>>> on primary storage failed due to " + e.toString();
>>>
>>>                     s_logger.warn(msg, e);
>>>
>>>                 }
>>>
>>>             }
>>>
>>>             s_logger.debug("Successfully destroyed snapshot on volume: "
>>> + volumeUuid + " execept this current snapshot " + avoidSnapshotUuid);
>>>
>>>             return true;
>>>
>>>         } catch (XenAPIException e) {
>>>
>>>             String msg = "Destroying snapshot on volume: " + volumeUuid
>>> + "
>>> execept this current snapshot " + avoidSnapshotUuid + " failed due to "
>>> + e.toString();
>>>
>>>             s_logger.error(msg, e);
>>>
>>>         } catch (Exception e) {
>>>
>>>             String msg = "Destroying snapshot on volume: " + volumeUuid
>>> + "
>>> execept this current snapshot " + avoidSnapshotUuid + " failed due to "
>>> + e.toString();
>>>
>>>             s_logger.warn(msg, e);
>>>
>>>         }
>>>
>>>
>>>         return false;
>>>
>>>     }
>>>
>>> --
>>> *Mike Tutkowski*
>>> *Senior CloudStack Developer, SolidFire Inc.*
>>> e: mike.tutkowski@solidfire.com
>>> o: 303.746.7302
>>> Advancing the way the world uses the cloud
>>> <http://solidfire.com/solution/overview/?video=play>*™*
>>>
>>
>>
>>
>> --
>> *Mike Tutkowski*
>> *Senior CloudStack Developer, SolidFire Inc.*
>> e: mike.tutkowski@solidfire.com
>> o: 303.746.7302
>> Advancing the way the world uses the cloud
>> <http://solidfire.com/solution/overview/?video=play>*™*
>>
>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkowski@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud
> <http://solidfire.com/solution/overview/?video=play>*™*
>



-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
<http://solidfire.com/solution/overview/?video=play>*™*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message