Don’t Delete anything. Ever!

Ok, so after a stressful morning I am writing mainly to tell myself never delete anything, ever again.

Anyone else, if you don’t know vmware very well, don’t try to manipulate your vmdk files. Probably should not perform this combo of commands:

1. snapshot
2. snapshot
3. revert to here.
4. extend disk
5. extend disk
6. extend disk
7. Call consultant and say you don’t know what happened it just isn’t working.

Extending a vmdk is not instant, and requires additional steps in Windows to actually see it work. Please please please start using VCB to backup your vmdk’s. Plus Backup Exec needs to do a SQL backup if you want your databse to work again.

VCDX – Nugget — Identify iSCSI, Fibre Channel

Storage – Create and Administer VMFS Datastores using advanced Techniques

Describe how to identify iSCSI, Fibre Channel, SATA and NFS configurations using CLI commands and log entries.

First, there are several commands relating to storage. Two of which I have discovered give me very useful information.

First is esxcfg-vmhbadevs

[root@esxvdi01 log]# esxcfg-vmhbadevs -h
esxcfg-vmhbadevs
Print the mappings between vmhba names and /dev names
-m–vmfs Print mappings for VMFS volumes to their Service Console partitions and vmhba names.
-f–vfat Print mappings for VFAT volumes to their Service Console partitions and vmhba names.
-q–query Print mapping in 2.5 compatibility mode to mimic vmkpcidivy -q vmhba_devs.
-a–all Print all devices, regardless of whether they have console device or not.
-h–help Show this message.

The useful switch is the –m, this will also print the VMFS id for easy identification of the HBA, Service Console device path and the VMFS volume.

[root@esxvdi01 log]# esxcfg-vmhbadevs -m
vmhba0:0:0:3 /dev/cciss/c0d0p3 48c64d26-b496c344-0a0f-001cc4be79c0
vmhba0:1:0:1 /dev/cciss/c0d1p1 48c64f2c-f4eb2f06-df8b-001cc4be79c0

Next is the command esxcfg-mpath
[root@SCG-PRESX3 root]# esxcfg-mpath -l
Disk vmhba1:0:1 /dev/sdc (1342249MB) has 2 paths and policy of Most Recently Used
FC 13:0.0 2100001b320b1e1f<->5006016030230c0d vmhba1:0:1 On active preferred
FC 15:0.0 2100001b320b6b31<->5006016830230c0d vmhba2:0:1 Standby

Disk vmhba1:0:2 /dev/sdd (2072576MB) has 2 paths and policy of Fixed
FC 13:0.0 2100001b320b1e1f<->5006016030230c0d vmhba1:0:2 Standby
FC 15:0.0 2100001b320b6b31<->5006016830230c0d vmhba2:0:2 On active preferred

Disk vmhba1:0:0 /dev/sdb (2072576MB) has 2 paths and policy of Fixed
FC 13:0.0 2100001b320b1e1f<->5006016030230c0d vmhba1:0:0 Standby
FC 15:0.0 2100001b320b6b31<->5006016830230c0d vmhba2:0:0 On active preferred

Disk vmhba0:0:0 /dev/sda (69376MB) has 1 paths and policy of Fixed
Local 1:0.0 vmhba0:0:0 On active preferred

This command is intended to supply multi-pathing information for the VMFS volumes. It additionally tells you the type of disk the service console device path the HBA identifier. I can see local, iSCSI, NFS, and Fibre Channel disk information from this command.

Any other commands to get this information? Let me know. As I (slowly) make my way into studying for the VCDX I hope to compile a big list

A Mention from VMTN Blog

It is nice to find out someone actually found this website. When I started the site my goal was to share the bits I know about VMware and other technology.

With the flood of Virtualization related blogs out there it is increasingly difficult to share something that I would find valuable and unique. I am not a great writer, so my challenge is to tell what I know and make the content compelling enough to overcome my poor sentence structure.

Thanks again, to John Troyer at VMTN for linking to my little blog I hope I can provide something of value so that people would return to read again.

The Missing VMDK

This week I had a weird thing happen. A already problematic VM in the OS and never really a problem in ESX. The machine shutdown because it is convinced there is another Windows 2003 SBS server on the domain, which there is not. This time it turned off and could not be powered back on. The VMDK file for the C drive was missing! I didn’t panic, much. The -flat.vmdk file was still there. I was able to track down a way to fix it:
1. Create a new vmdk the same size.
2. Copy and rename the .vmdk file to the needed location.
3. Edit the .vmdk to point to the -flat.vmdk.
4. Add the virtual disk to the VM.

Everything was ok. I still don’t know how the file could up and dissapear.
Any thoughts?