Unsolved
This post is more than 5 years old
1 Rookie
•
61 Posts
0
13873
February 23rd, 2012 13:00
Scheduled Smart Copy causing snapshot on additional volume
PS6100XS, firmware 5.20 (will update to 5.21 this weekend)
We used the VMware HIT appliance to create a daily (at 5am) scheduled Smart Copy snapshot on Volume A, which is 6TB.
We also have a scheduled Smart Copy snapshot running on Volume B, which runs every 2 hours from 8am-8pm. This one is behaving as expected.
The problem is that the 5am Smart Copy, in addition to doing what it's supposed to, which is a Smart Copy of Volume A, is also making a snapshot of some kind on Volume B. We have a Volume C, by the way, which is not affected by this strange behavior. We don't have any Smart Copy schedules on Volume C. The weird unscheduled snapshot on Volume B doesn't show up in the list of Smart Copies, but does show up under the web UI. It's definitely a real snapshot, because when I delete it I see that it frees up some space in the snapshot reserve.
I'm certain it's not some other scheduled job that's causing this, because when I change the time that the daily 5am job is scheduled to run, the time of the unexpected snapshot on Volume B changes, too. It also has a timestamp that is identical to the snapshot on Volume A.
Any ideas?
jakesterpdx
1 Rookie
•
61 Posts
0
February 23rd, 2012 20:00
It's a reasonable theory, but Volume B is extremely clean - 4 simple folders, one for each of my 4 VMs. Any other ideas?
sketchy00
203 Posts
0
February 24th, 2012 17:00
Are you doing an ASM/VE smartcopy from a folder level of a collection of VMs? And does that folder contain VMs that live in different datastores? That will do what you describe every single time. That is why I like to mimic my folder arangement equivalent to what each datastore holds. It makes snapshots easy.
sketchy00
203 Posts
0
February 24th, 2012 17:00
Just to make sure we are speaking the same terms here, so in vCenter you went to the "DataStore and DataStore Clusters" entity, and selected the VMFS datastore, and then set a schedule for a smartcopy of all systems in that datastore? If that is the case, I'd jump in and browse the datastore, and verify for sure that each VM sitting in there doesn't reference a vmdk that lives somewhere else. Otherwise, it will make a snap of both courtesy of what vCenter is telling it. If you don't see anything, then yes, open a support case. Personally, I'd do a storage vmotion of individual VMs out of that vMFS datastore, then keep running a smartcopy until the condition no longer exists. You should be able to find the culprit that way.
jakesterpdx
1 Rookie
•
61 Posts
0
February 24th, 2012 17:00
No, I'm telling it to hit the whole volume. Sounds like I need to make a support case.