A confirmation before poweroff would be pretty sweet. I do miss click on stuff sometimes and today I killed a VM while messing with Kodiak.
[[email protected] root]# esxcfg-advcfg
-g|–get Get the value of the config option
-d|–default Reset Config option to default
-q|–quiet Suppress output
-k|–set-kernel Set a VMkernel load time option value.
-j|–get-kernel Get a VMkernel load time option value.
-m|–set-message Set DCUI welcome message.
-u|–uuid Ensure the Vmkernel system UUID is set and print it.
-h|–help Show this message.
-r|–restore Restore all advanced options from the configuration
file. (FOR INTERNAL USE ONLY).
A great wealth of info about this command (and all esxcfg- commands) from b2vGuide2vmware3. So not wanting to repeat anything written on the site. I would ask what is the common usage situation for this command?
We can see how to use the command but exactly why would I do those changes?
I guess from the looks of things this command might be the hardest one to explain.
Anyone out there able to fully explain this?
Maybe alphabetical was the wrong way to start.
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:
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.
Several people have posted about SRM in Workstation. I decided to try it out. I do not have access to any NetApp storage device so I am trying to use the EMC Celerra Simulator. Wow, pretty intensive. I am moving it all to my laptop that has more ram. Hopefully I can get all teh VM’s to boot. Then we will see what happens.
Great stuff. I would be willing to put this in place for a test/dev setup. Still feel uneasy that machines might not come out of standby cleanly. I am performing Capacity Planning lately and it is amazing how much money VMware can save you when it comes to power alone.
VMwarewolf just posted Common system management issues in VMware Infrastructure. Take a look. Very usefully grouped troubleshooting steps for common issues. Thanks!
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
[[email protected] log]# esxcfg-vmhbadevs -h
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.
[[email protected] 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
[[email protected] 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
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.
Here is my Bluebear Kodiak 0.02 beta screenshot. I used Ubuntu because of Windows having problems with the certificates. The UI is very slick. I am going to test various applications and tasks and see how it goes. I just thought I would post something now so I can be cool.
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.