Tag: VMware

Using vim-cmd to remedy a bsod

Here’s a great tutorial for vim-cmd if you haven’t had experience with it before by my friend, Steve Jin: www.doublecloud.org/2013/11/vmware-esxi-vim-cmd-command-a-quick-tutorial/

This is a real-world situation I got myself into when I tried connecting to my client VM and found a BSOD that looked like this:

It’s pretty obvious that the reason for the crash is the USB stick that’s plugged in from the usbuhci.sys line in the blue screen. Since I tunnel into my client VM via SSH and VNC, the easiest way for me to shutdown my VM and remedy this issue is through vim-cmd. This only works if you have SSH allowed onto your ESXi host or if you are connecting to the host with the VMware CLI or vMA or whatever they’re calling it these days. I have the former.

The first thing I do after logging into the ESXi host as root is run:

vim-cmd vmsvc/getallvms

I need to know which one of my VMs is the one to manage. I get this:

Vmid Name File Guest OS Version Annotation
1 windows7 [BIG_DISK] windows7/windows7.vmx windows7_64Guest vmx-07
3 thimble [BIG_DISK] thimble/thimble.vmx ubuntu64Guest vmx-08
4 chunli [Datastore 2] chunli2/chunli2.vmx ubuntu64Guest vmx-08
5 zangief [Datastore 2] zangief2/zangief2.vmx ubuntu64Guest vmx-11

With this information, I know that it’s VM 1, so I power it off by running:

vim-cmd vmsvc/power.off 1

Thinking the USB issue might be a fluke, I try to power the VM back on to see if it will boot.

vim-cmd vmsvc/power.on 1

I see that it starts booting, but as the resolution changes on the VM, my VNC viewer freezes. Since I normally don’t know exactly when it freezes, I didn’t know when I got the BSOD again.

Until I decided to at look at the vmware.log file. This is what I saw there:

2017-10-18T22:27:05.519Z| svga| I125: SVGA disabling SVGA
2017-10-18T22:27:05.545Z| svga| W115: WinBSOD: (20) 'Technical information: '
2017-10-18T22:27:05.545Z| svga| W115:
2017-10-18T22:27:05.546Z| svga| W115: WinBSOD: (22) '*** STOP: 0x000000D1 (0xFFFFF88000BF2000,0x0000000000000002,0x0000000000000001,0'
2017-10-18T22:27:05.546Z| svga| W115:
2017-10-18T22:27:05.546Z| svga| W115: WinBSOD: (23) 'xFFFFF88004206E49) '
2017-10-18T22:27:05.546Z| svga| W115:
2017-10-18T22:27:05.557Z| svga| W115: WinBSOD: (26) '*** usbuhci.sys - Address FFFFF88004206E49 base at FFFFF88004200000, DateStamp'
2017-10-18T22:27:05.557Z| svga| W115:
2017-10-18T22:27:05.557Z| svga| W115: WinBSOD: (27) ' 57b37a29 '
2017-10-18T22:27:05.557Z| svga| W115:
2017-10-18T22:27:05.557Z| svga| W115: WinBSOD: (30) 'Collecting data for crash dump ... '
2017-10-18T22:27:05.557Z| svga| W115:
2017-10-18T22:27:05.573Z| svga| W115: WinBSOD: (31) 'Initializing disk for crash dump ... '
2017-10-18T22:27:05.573Z| svga| W115:
2017-10-18T22:27:07.547Z| mks| W115: Guest operating system crash detected.

Okay, so I see that my hunch is correct. I guess it’s time I remove the USB device from the VM. So I power off the VM again and open up the vmx file and just start removing all instances of USB.

These are the lines I removed. Don’t worry about breaking anything. The hypervisor will put them back if you need them later. Back up your vmx file before doing it though just in case.

usb.pciSlotNumber = "34"
usb.present = "TRUE"
usb:1.speed = "2"
usb:1.present = "TRUE"
usb:1.deviceType = "hub"
usb:1.port = "1"
usb:1.parent = "-1"
usb.autoConnect.device0 = "path:1/1 autoclean:1"
usb:0.present = "TRUE"
usb:0.deviceType = "mouse"
usb:0.port = "0"
usb:0.parent = "-1"

After you’ve saved your changes, you’ll need to reload the changes so that ESXi will reread the .vmx file to remove the USB device. You can do this by running this command:

vim-cmd vmsvc/reload 1

Now you’re ready to power on the VM.

vim-cmd vmsvc/power.on 1

The VM powers up and I’m back in business. I just had to figure out the USB issue later. Turned out that I just needed to reconnect the device and reformat it. I haven’t seen the issue come up again.

 

ESX 6.0 – The operation is not allowed in the current connection state of the host.

UPDATE:

The things in the posting did NOT work. According to IBM’s website, the fix is by removing a package:

esxcli software vib remove -n intel-cdmv2-provider

—

I got this message when trying to power on a vm, trying to deploy a template, and something else.

So I read this
https://communities.vmware.com/thread/331857?start=0&tstart=0
and then I go to the host and try restarting hostd (/etc/init.d/hostd restart) and it will no longer restart.

Looking into /var/log/hostd.log, it appears that /tmp is full:

2016-02-09T06:01:01.648Z info hostd[79EC2B70] [Originator@6876 sub=Vimsvc.ha-eventmgr] Event 620 : The ramdisk ‘tmp’ is full.
As a result, the file /tmp/auto-backup.6942719/local.tgz could not be written.

So I look into the /tmp directory and find a file that’s 256MB – cimple_log_err_messages

cat cimple_log_err_messages
2016/02/09 23:28:57:LOG FILE ERROR: log.cpp(610) : No CIMPLE_HOME env var defined. Looking for CIMPLE_HOME
2016/02/09 23:28:57:LOG FILE ERROR: log.cpp(610) : No CIMPLE_HOME env var defined. Looking for CIMPLE_HOME
…

The first thing I do is to clear up the file – just run:
> cimple_log_err_messages

Then I’m able to start hostd, but how do I stop the file from filling up again?

I find this kb: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2094441

Not that it helps! It’s for 5.x. I go to the IBM url and it just leaves me more confused.

I look into disabling CIM. I find instructions here: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1025757

ummm it’s for 5.x again. 🙁
Run the instructions and the sfcb watchdog just restarts by itself!

Finally, I poke around in the vSphere client and notice in the profile that there is some CIM stuff there. For the heck of it, I try disallowing communication with IBMIMM.

Screen Shot 2016-02-10 at 11.45.09 AM

I believe the log messages continued after disabling it, so I continued to disable CIM as well. After disabling CIM, the log messages stopped.

Screen Shot 2016-02-29 at 12.14.11 PM

 

Converting a VMware Fusion VM to ESXi

One of the easiest ways to get a VMware Fusion VM up to ESXi is to use the Upload to server option
Screen Shot 2015-12-14 at 12.17.08 PM

If your VM was installed in more seamless mode though, after getting your VM up and running in ESXi, your local folders will be missing.
Screen Shot 2015-12-14 at 12.21.19 PM

I love running my desktop in more seamless mode in Fusion, but obviously, this won’t work in ESXi. To fix this, go into the VM and make the following changes.

Navigate to these two locations:

– HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
– HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders

Make sure that you see these values (among others).  Update these entries, if they have a different data value.


  1. Navigate to these two locations:

    • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
    • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders

  2. Make sure that you see these values (among others). Update these entries, if they have a different data value:

    Windows XP / Server 2003 

    Name Data value
    Desktop %USERPROFILE%\Desktop
    My Music %USERPROFILE%\My Documents\My Music
    My Pictures %USERPROFILE%\My Documents\My Pictures
    Personal %USERPROFILE%\My Documents



    Windows Vista / 7 / Server 2008 / 8 / 10

    Name Data value
    Desktop %USERPROFILE%\Desktop
    My Music %USERPROFILE%\Music
    My Pictures %USERPROFILE%\Pictures
    Personal %USERPROFILE%\Documents

Why are my VM’s custom attributes not backed up? Work around with PowerCLI

This posting is for those that might want to backup a VM on one vCenter and restore it in another vCenter, but seeing that the custom attributes are not copied over. For now, this is a workaround. Moving forward, VMware is deprecating custom attributes in favor of tags. For tagging, it makes sense because if you’re searching for a particular VM, that’s how you do it, but custom attributes are key-valued pairs. I’m not sure how that makes sense with tags.

First off, you will need PowerShell and PowerCLI both installed on your machine. You can do this from any Windows host that can talk to vCenter. If you’re using Windows 7 or above, you should not need to download PowerShell, but you can download it here if necessary: http://www.microsoft.com/en-us/download/details.aspx?id=34595. You can get the VMware PowerCLI here: https://my.vmware.com/group/vmware/get-download?downloadGroup=PCLI501. There’s an access restriction in PowerShell by default that will not allow PowerCLI commands to run if it’s turned on. The installer will ask if you want to turn it off – you can have the installer do it for you. After it’s all installed, you can move onto the next step.

The first thing we need to do is to authenticate against vCenter. You can do this with:
We’ll need to find out what the custom attributes are. You can get them by running:
Connect-VIServer -user -pass for example:
Connect-VIServer 10.5.10.204 -user domain\administrator -pass P@SSw0RD!

Before we do any backup, we need to find out what the custom attributes are. You can do this by running
$vm=get-vm

If you want to read the custom fields, you can type:
$vm.Customfields

You can output those custom fields into a file or whatever you want. When you want to write those field back into a VM, you would do it this way:

After registering the VM, you can run this to assign the new vm:
$newvm = get-vm

Then loop through the custom fields and set them
foreach ($field in $vm.Customfields) {set-annotation -Entity $newvm -customattribute $field.Key -Value $field.Value }

This should set the custom fields that you will need.

How to fix networking after cloning an Ubuntu 8 VM

Stolen from: http://weblog.jamisbuck.org/2008/8/15/cloning-ubuntu-hardy-image-in-vmware-fusion

* “sudo hostname blah”, to set the hostname. This doesn’t change it permanently, so you’ll also want to:
* “sudo vim /etc/hostname”. Change the contents of the file to the hostname you want. Then:
* “sudo vim /etc/hosts”. Replace all mentions of the old hostname with the new hostname.
* “sudo vim /etc/udev/rules.d/70-persistent-net.rules”. There will be two entries in this file. The first points eth0 at the old MAC address, and the second points eth1 at the new. Go ahead and delete the first entry, and change “eth1” to “eth0” in the second (and now only) entry.
* “sudo shutdown -r now” to restart your virtual machine.