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.tutkow...@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.tur...@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.tutkow...@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.tutkow...@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.tutkow...@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.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud <http://solidfire.com/solution/overview/?video=play>*™*
