Finding ESX Hostname from VM configuration file(s) or Directory

[jitendrakmr]

Hello Everyone,

I have a cluster of 10 hosts having approx 80 VMs running. Is there any command through which -

1. I can find out the ESX Hostname on which a particual VM is running (reverse of "vmware-cmd -l" command)

2. The datastore location on which that particular VM is located.

Thanks in advance!

Jitendra

MCSE 2003, VCP, CCNA, ITIL Foundation

[weinstein5]

are you looking to do this from the CLI or VI Client? - from the VI client it is shown in the summary screen I believe -

[Dave_Mishchenko]

If you have VirtualCenter you can get the hostname from the Virtual Machines view (right click on the column header and check the hosts column if you don't see it). The datastore you could pull from the VC database.

[jitendrakmr]

Actually I need to write a script so I am looking to find that information using CLI.

Thanks.

Jitendra

MCSE 2003, VCP, CCNA, ITIL Foundation

[adolopo]

Just to confirm...

You're doing this from the VM, correct?

[JaySMX]

I'm not a programmer, but there is an API in VC which should allow you to programmatically find this data. Otherwise, if you need this scripted I would think you would have to set up a loop to connect to each host and run the vmware-cmd -l command, examing the output and taking action accordingly. The vmware-cmd -l command will also give you the path to the .vmx file, which tells you the datastore the VM is running from.

[weinstein5]

the vmrun command will show the running vm's on an esx host -

[jitendrakmr]

Yes. One way is to connect all the hosts in a loop, run vmware-cmd command on each and then analyze results.

Just curious if one can find any host related information from locks on vmx file of that particuar VM? Just an example, sometimes after a failed migration through DRS I see that particular machine in Powered off state and when I try to power it on it says that "Swap file not found" then I actually need to dig in to find out which host is actually locking that VM and then after killing the process of that VM on that host I could able to power it on. In such case even the information on summary tab is not correct. So if there is any way by which I can find host information from locks on vm configuration files then I can login to any host in cluster to find out the host which actually i locking that VM and that will save some time.

Also for my second question about datastaore information; yes I can get that using vmware-cmd command. Thanks. Is there any command through which I can also find out on which LUN that datastore is created?

Thanks.

Jitendra

MCSE 2003, VCP, CCNA, ITIL Foundation

[JaySMX]

You can view the LUN/device/VMFS label mappings with with 'esxcfg-vmhbadevs -m' command.

I have seen issues like you describe before and a script to tell you which host thinks it is running the VM would be handy. It was a small environment that I had that problem in, so we never really ironed out a way to solve it via a script.

[Texiwill · Accepted solution]

Hello,

From inside a VM, it is not possible to find this information.

From the CLI of a host, it is not possible to find this out for any VM not hosted by the host in question.

The best suggestion is to use the VI Perl Toolkit, and either connect to VC to find this information per VM or connect to each host in turn to find this information.

Another option would be to use the MAP function of the VIC and grab a MAP of each host and print it out. THat will also give you this information.

Best regards,

Edward L. Haletky

VMware Communities User Moderator

====

Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education. CIO Virtualization Blog: http://www.cio.com/blog/index/topic/168354, As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization

[wila]

An answer I've not read here is that you can also query the database at the VC host, see also

There's SQL demo code floating around on the forums for this.. (sorry don't have a copy)

--

Wil