V2V error with vConverter standalone - Unable to obtain hardware information for the selected machine.

When converting a VMWare workstation format VM (V2V) you might get this error if you're trying to read the image from a network path with a deep folder structure.

The simple resolution is to map a drive letter at the top level so the vmx and vmdk files are visible directly under the drive letter.

The converter wizard will then allow you to progress to specifying the destination system.

Force removal of vmkernel ports

Trying to unbind a vmkernel port from an iSCSI adapter that is currently in use fails with the message
"Unable to unbind iscsi port."

Use the --force true parameter to force removal
esxcli iscsi networkportal remove -A vmhbaxx-n vmkx --force true

VMware vCenter Support Assistant can't resolve vCenter server name

The vCenter Support Assistant is a free Linux (SUSE) based virtual appliance to aid support requests in a vmware environment.

It's quite easy to setup but it has an odd quirk with DNS resolution.

By default, it will try to connect to the vCenter name you use in your vCenter vi-client, and it will ignore the name you use in the setup wizard to register with vCenter.

e.g. if you register with a FQDN for vCenter, but then use the short name in your Windows vi-client, it will report connectivity from virtual appliance to vCenter FAILS during it's diagnostics checks run at first login.

The solution is to manaually go into the linux console and etc the /etc/resolve.conf file and add a search suffic

1. Open Console
2. Login as root
3. edit the resolve.conf file
    vi /etc/resolve.conf
4. append the search suffix to the end of the file
    search yourdomain.com
5. save the file
    esc
    !wq!
6. rerun diagnostics

The last two checks should now pass.

Version of VCSA used was 5.1.1.  YMMV with other versions.

Validation of Dell OMSA Online Repository in VMware Update Manager Download Sources fails

Dell kindly provide an repository containing all the VMware OpenManage versions that you can point Vmware Update Manager to in order to get the right .VIB for your ESXi server

The Update Manager service needs to be able to access the repository url which is https://vmwaredepot.dell.com/index.xml.

If Vmware Update manager lives behind a firewall then the changes are you'll be pointing it a web proxy (In my case this was ISA 2006).  Even though it was allowed unauthenticated access, the validation step kept failing.

A bit of investigation of the firewall logs revealed an odd error:
995 The I/O operation has been aborted because of either a thread exit or an application request

A bit more digging revealed this article, pointing to Java as the culprit.  As Update Manager seems to have some Java components, I updated Java to the latest version (JRE7 Update 40), both x32 and x64 but this didn't resolve the issue.

Another read of the original answer from Jim Harrison led me to wonder if a non-SSL connection would work, so I modified the URL to http://vmwaredepot.dell.com/index.xml and hey presto! the validation succeeded.

The full Dell White Paper is located here:

Vmware Update Manager Error code 15 when updating Dell OpenManage

The vmware update manager logfile (C:\ProgramData\VMware\VMware Update Manager\Logs) may show the error “Could not find a trusted signer”

This can be resolved by removing the Dell VIBs for OpenManage and the Equallogic Multipath Module and reinstalling manually
esxcli software vib remove -n OpenManage -n dell-configuration-vib -n dell-eql-host-connection-mgr -n dell-eql-hostprofile -n dell-eql-routed-psp


Manually re-install the OpenManage VIB
esxcli software vib install -d /tmp/OM-SrvAdmin-Dell-Web-7.2.0-6945.VIB-ESX51i.zip

Reboot the host to remove the loaded VIBs from memory and load the new version of OpenManage

The equallogic module can be reinstalled with Update Manager with no reboot required

Setting up VMware Vmware Update Manager (VUM) & UMDS

Vmware Update Manager (VUM) is the preferred update tool for keeping Vmware ESX servers up to date.

Sadly in version 5 Vmware dropped the ability to patch VMs, but it's an essential part of the Vmware Sysadmin's toolkit none the less.

Installation of VUM is pretty straight forward.  You create an ODBC connection to either a local SQL Express installation or a remote dedicated SQL server (on a 64bit server this needs to be done with the 32bit odbc admin tool C:\Windows\SysWOW64\odbcad32.exe and remember to install the SQL client connectivity!).  You then run the setup wizard off the vCenter media and select your ODBC connection.

The UMDS (Update Manager Download Service) is an additional component of VUM which can be manually installed, again off the vCenter media.  It allows you to download the patches and metadata to an isolated VUM server which has no access to the internet (direct or via a proxy).

There are two stages - the download and getting the files into VUM:

1. Internet -> UMDS download -> staging box
2. Staging box -> IIS / USB drive / Local Drive -> VUM Shared Repository

Stage 1.

• Install UMDS on any box with internet access (direct or via proxy).  This will require the SQL client connectivity and setting up a 32bit ODBC connection.
• Configure internet access with the config utility in C:\Program Files (x86)\VMware\Infrastructure\Update Manager\VMwareUpdateManagerUtility.exe (on 64bit windows)
• Once UMDS is running, you just run the command vmware-umds -D. This will download the patches and metadata to the data directory specified during setup.

Stage 2.

There are several methods for getting the data into VUM.  All require the data to be "exported" from the download folder. (this is per the vmware documentation but I can't see any different between the download folder and the exported folder)

• vmware-umds -S --default-export-store C:\UMDS_Export - this sets the export location.  The vmware docs say this needs to be only one folder deep to work
• vmware-umds -E this does the export.

If you're not planning to use IIS to serve up the files to VUM, you need to get this export folder onto your VUM server local disks (either with a USB drive or manually copying over CIFS to the VUM server disks) and use the "shared repository" feature to tell VUM where they are.  Click the "download now" button to get the metadata into VUM.

Using IIS is a nice way to automate the process (connectivity permitting).  

• First off, create a virtual directory in IIS pointing to the export folder.
• Grant permission to the export folder, subfolders and all files to at least the IIS_IUSRS user (the builtin users group includes this user)
• Then add the mime types from the VMware article here and enable directory browsing. 
• Restart IIS
• Add the URL to the shared repository section of VUM's configuration page and validate the URL - remember to include http or https as appropriate for your IIS setup
• Click download now

Finally, you need to either wait for a scheduled patch download, or modify your schedule to "once" and select "run now" to make VUM process the metadata otherwise you won't see any patches.

Here's a quick summary of the different roles

UMDS server

• Needs internet access (direct or via proxy)
• Requires a UMDS SQL database, either local or remote, connected via 32bit ODBC 
• Downloads patches to local disk
• Exports patches to either local disk or usb disk for transfer to VUM
• Optional: IIS can be installed to serve patches to VUM server

VUM Server

• Needs to be able to connect to vCenter
• Needs a VUM SQL database, either local or remote, connected via 32bit ODBC
• Downloads patches to local disk during remediation from either USB, another local folder or IIS.
• Optional: Needs to be able to access IIS port on the UMDS server

Additional reading:

http://pubs.vmware.com/vsphere-50/topic/com.vmware.vsphere.update_manager.doc_50/GUID-013BCF81-7F46-4EFF-BA67-40FA08C91037.html

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1004455

http://communities.vmware.com/message/2091767?tstart=0

http://virtuallymikebrown.com/2011/10/23/vcenter-update-manager-patching-guide/

Posted via email from Pio's work related musings

Error: "The resource vswif0 is in use" when changing service console IP

When you try to change a service console IP from DHCP to Fixed, you'll get this error.

A simple workaround is to add a second service console with a new IP and delete the original.

Posted via email from Pio's work related musings

Wake on LAN problems - Dell 2950 servers and Broadcom NICS

Although I've been using vmware for over 3 years through various incarnations, I've only just been in a position to exploit the power-saving features in v3.5. 

At first glance it looks pretty straight forward - click the "enter standby" option and sit back and watch. No.

First off, you need to have Wake on LAN (WOL) supported on your vmotion NIC.   This isn't necessarily something you think of when setting up the patching of the virtual server - Intel PT1000 Quad Port NICs only support WOL on the first port (Dual ports also).  Others in the range might be different, but the VT1000 NICs have their own issues in vmware depending on the version of vmware installed.

Most of the servers I work on are Dell x9xx series which have Broadcom 5708 onboard NICs.  Looking in Virtual Center at the NIC configuration shows whether VMware thinks WOL is available.  I was a bit confused when I found for some servers it was available and for others it wasn't.  Dell support went through the usual steps - update the firmware, update the NIC firmware, etc. - to no avail.

I tested the WOL feature anyway with the AMD Magic Packet utility and the MAC address of the NIC and lo! it woke up.  Curiouser and curiouser.

After more research by Dell, one of their engineers discovered source of the issue (hurrah!) in the version of the Ethernet Controller Hardware.  an lspci command (run as root) reveals the version number:

05:00.0 Ethernet controller: Broadcom Corporation Broadcom NetXtreme II BCM5708 1000Base-T (rev 11)

Rev 11 is the culprit and Rev 12 servers correctly show WOL available in vmware.  Dell have escalated the issue to vmware so hopefully there will be some kind of resolution soon.

So in summary:

1. Make sure vmotion is enabled on a NIC that supports WOL
2. Check your broadcom NICs are Rev12 and above.
3. Put your Host in a Cluster
4. At least one other Host in the Cluster must be on (this does the wakeup on the others that are in standby)
5. Enable WOL in the NIC boot bios

Blogged with the Flock Browser