Project

General

Profile

Bug #7879

Vmware Snapshot Failure leaves Orphan

Added by Steve Bennett over 5 years ago. Updated about 4 years ago.

Status:
Resolved
Priority:
No priority
Assignee:
Josh Paetzel
Category:
Middleware
Target version:
Seen in:
Severity:
New
Reason for Closing:
Reason for Blocked:
Needs QA:
Yes
Needs Doc:
Yes
Needs Merging:
Yes
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:
ChangeLog Required:
No

Description

Not sure if this should count as two issues but..

If you create two manual snapshots (vmware synced), in my case two different datastores, and leave to the default name which is manual-yyymmdd the seconds will fail due to the fact the name already exists. This is a pretty rare occurrence and relies on laziness from the operator but perhaps the the manual snapshot creation should have the time HH:MM in the snapshot to further guarantee uniqueness.

The fallout of this is that if the 2nd snapshot is VM synced and failes it leaves an orphaned snapshot on the VM's for that Datastore.

Associated revisions

Revision 27f4e9d8 (diff)
Added by Josh Paetzel over 5 years ago

Make manual snapshots more robust WRT vmware snapshots. Ticket: #7879 If the manual ZFS snapshot fails, do not leave dangling VMWare snapshots. Add a description to VMWare snapshots created as a result of taking a manual ZFS snapshot.

Revision cdad2216 (diff)
Added by Josh Paetzel over 5 years ago

Make manual snapshots more robust WRT vmware snapshots. Ticket: #7879 If the manual ZFS snapshot fails, do not leave dangling VMWare snapshots. Add a description to VMWare snapshots created as a result of taking a manual ZFS snapshot. (cherry picked from commit 27f4e9d84c1c4ae5269d390267d2dd02f2aead02)

History

#1 Updated by Josh Paetzel over 5 years ago

  • Category set to 59
  • Status changed from Unscreened to Screened
  • Assignee set to Josh Paetzel
  • Target version set to Unspecified

This seems easy enough to fix.

#2 Updated by Steve Bennett over 5 years ago

By orphaned I mean that it leaves a snapshot, as Freenas does not clean up, the snap shot is still visible in the vmware snapshot manager view of the vsphere client and not actually an invisible snapshot shot on the Datastore needing a Consolidation.

#3 Updated by Josh Paetzel over 5 years ago

  • Status changed from Screened to 15

I'm missing something fundamental here.

Are the snapshots of the same ZFS dataset or zvol? If they aren't, they won't collide simply because the dataset name is in the snapshot name.

#4 Updated by Steve Bennett over 5 years ago

Grovelling apologies I was attempting to snapshot two different zvols from the same Dataset, however I must have attempted to snapshot the same ZVOL and hadn't realised as the 2nd snapshot failed.

However the error still exists if the user (me) is too lazy to change the manual snapshot name 'manua-yyyymmdd' when creating the second manual snapshot there is a middleware error in the gui.

The error occurs after the vmware snapshot is taken, but the middleware failure means this snapshot is not cleared up.

There is an argument that the name clash is user stupidity and will never really happen but if you are working on a bunch of machines on a Vmware Datastore and you want to create a couple of ZFS snapshots you could still create this if you are less than awake.

Anyway still doesn't cleanup the vmware snapshot :-)

#5 Updated by Steve Bennett over 5 years ago

Seems to be saying Waiting for feedback, is this something I should alter?

Sorry about the 8098 issue, had been thinking of the desc field when I raised 7881 should have been more clear.

#6 Updated by Jordan Hubbard over 5 years ago

  • Status changed from 15 to Screened

Josh, what specific feedback were you waiting for? Thanks.

#7 Updated by Steve Bennett over 5 years ago

I thought the status changed automatically, thought it had failed to update status and didn't want anyone thinking I couldn't be bothered to respond after raising the ticket.

#8 Updated by Josh Paetzel over 5 years ago

  • Priority changed from Nice to have to No priority

#9 Updated by Josh Paetzel over 5 years ago

  • Status changed from Screened to Ready For Release

#10 Updated by Jordan Hubbard over 5 years ago

  • Status changed from Ready For Release to Resolved

#11 Avatar?id=14398&size=24x24 Updated by Kris Moore about 4 years ago

  • Target version changed from Unspecified to N/A

Also available in: Atom PDF