NetApp vol copy of snapshot for vSphere

Using Data from a NetApp snapshot via vol copy

make sure the destination volume is not being used,

if mapped to VMware delete VMFS and unmap and rescan from vCenter

offline the volume

verify the snapshot needed with snap list command

vol copy -s start snapshot_wanted source_vol_with_snap dest_vol_alredy_offlined

online the destination volume and you'll see message from NetApp CLI warning that lun has been offlined as it is copy and therefore has duplicate information as the source:

Fri Jan 13 14:51:52 GMT [SnapVaultA: lun.newLocation.offline:warning]: LUN /vol/sv_lun_svcopy/sv1/lun96 has been

taken offline to prevent map conflicts after a copy or move operation.

go to FilerView and change the path and lun number of the lun for the dest. volume.

Now you can online the volume and map it out with the correct, non-duplicate, lun number.

rescan storage on vCenter

add Storage and choose "Assign a new signature" when adding dest. lun into vCenter.

find the VMFS on your dest. lun which will have it's old name but after prefix "snap-xxxxx" and rename it appropriately.

add the VMDK on the VMFS on the lun to your VM and you're laughing!

Snapvault Backups

These instructions are in NetApp's docs, but they're kinda vague, especially when it's time to do the "snapvault snap create" commmand--which volume should be named? SnapVault copy or Source? I've logged this with NetApp and our expert consultants and neither got to the correct answer easily or quickly.

1. Create lun for destination on snapvault

2. set schedules for retention, but disable snapshots as in this case they'll be ran from NetApp client via script which has ssh access.
netapp1> snapvault snap sched src_vol src_vol_weekly
snapvault> snapvault snap sched src_vol src_vol_weekly

3. Ensure remote access between MetroCluster source and Snapvault Destination is good.

4. Establish initial baseline transfer between both volumes on both heads.
SnapVault> snapvault start -S netapp1:/vol/volume sv_volume

5. connect schedules
SnapVault> snapvault snap sched -x blah:/blah blah

SnapVaultA> snapvault snap sched

...

xfer sv_vol sv_vol_snap_sv_weekly 12@- preserve=default,warn=0

netapp1> snapvault snap sched

create vol sv_vol_snap_sv_weekly 4@-

Note: we keep 4 copies of the snapshot on the source/primary/MetroCluster and 12 copies on the destination/secondary/SnapVault

6. create new snapshots and verify date/time stamps

SnapVault> snapvault snap create sv_vol sv_vol_snap_sv_weekly

NOTE: this next command is the bit that goes in your script on the NetApp client right after quiescing/stopping your database and right before starting it up again:

7. remember always pull TO snapvault, don't push:

SnapVault> snapvault update netapp1:/vol/vol/sv1

Transfer started.

Monitor progress with 'snapvault status' or the snapmirror log.

SnapVault> snapvault snap create sv_vol sv_vol_snap_sv_weekly

NetApp> snapvault snap create vol sv_vol_snap_sv_weekly

8. Verify snapshots (look for Status and Contents fields below)

SnapVault> snapvault status -l SnapVault:/vol/sv_vol/sv1

Snapvault is ON.

Source: netapp1:/vol/volume/qtree

Destination: SnapVault:/vol/sv_vol/sv1

Status: Transferring

Progress: 4856300 KB

State: Snapvaulted

Lag: 03:25:19

Mirror Timestamp: Wed Jan 11 09:10:45 GMT 2012

Base Snapshot: SnapVault(1573980687)_sv_vol_snap_sv_weekly

Current Transfer Type: Update

Current Transfer Error: -

Contents: Transitioning

Last Transfer Type: Update

Last Transfer Size: 4735288 KB

Last Transfer Duration: 00:01:02

Last Transfer From: netapp1:/vol/_sv_vol_snap_sv_weekly/qtree

SnapVault> snapvault status -l SnapVault:/vol/sv_vol/sv1

Source: netapp1:/vol/sv_vol_snap_sv_weekly/qtree

Destination: SnapVault:/vol/sv_vol_snap_sv_weekly/sv1

Status: Idle

Progress: -

State: Snapvaulted

Lag: 00:04:00

Mirror Timestamp: Wed Jan 11 12:34:05 GMT 2012

Base Snapshot: SnapVault(1573980687)_sv_vol_snap_sv_weekly-base.0

Current Transfer Type: -

Current Transfer Error: -

Contents: Replica

Last Transfer Type: Update

Last Transfer Size: 5165432 KB

Last Transfer Duration: 00:01:54

Last Transfer From: netapp1:/vol/sv_vol_snap_sv_weekly/qtree

The destination will say, "snapvaulted" under Status when completed.

Resetting Lost ESXi password

There's one blog post I've found about booting your ESXi host to a bootable Linux CD and hacking the root password, but VMware says the only supported solution is to do a recovery install.

The nice folks at VCE have suggested something else:

You need the full Enterprise license in order to use host profiles for this fix. We did this on ESXi 4.1 update 1 with Virtual Distributed switches and SAN.

1. Login to VC as Administrator and create a new host profile using another ESXi host.
2. Edit the Host profile and change the "Administrator password" to a fixed password.
3. Next "Attach" and "Apply" the modified profile to the host that you don’t know the password for.
4. You should now be able to login via the console or SSH however the change is only temporary.
5. From ESXi command line execute the backup script to make changes persistent - ~ # /sbin/auto-backup.sh
7. Finally put ESX into Maintenance mode, Reboot and verify new login credentials.

Thanks again to VCE!