Monthly Archives: January 2022

Auto Connecting Devices to a VMware Workstation VM

Posted on by

As part of my latest homelab setup, I run my vCenter Server VM and Domain Controller VM on VMware Workstation Pro 16 and not on an ESXi host. This is mainly so I don’t have to fire up a noisy rack mount server when I only need my vCenter Server for something.

This did leave me with the problem of a lack of physical ports in my Windows PC to be able to bridge my VM’s with, so out came the trusty USB Ethernet adapter!

By default, this USB device is connected to the host machine. As I would always forget to connect this to my domain controller VM(which is the VM I bridged with this interface), I would end up having to reboot it once I had connected it as I would get all sorts of problems, including DNS issues.

To address this, there is a line that can be added to the vmx file of the VM to auto connect a specific device to a VM. It took me a while to find the information that was pertinent to specifically version 16 of VMware Workstation so I thought I would write a quick article on it.

Firstly, you need to grab the VID and PID values from the registry by looking through the devices in the following path, or searching if you have an idea on what its friendly name is:

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB

Once you have these values, open up the VMX file of the VM you want to auto connect the device to in a text editor, making sure the VM is in a powered off state first.

Add the following line to the file, replacing the VID and PID values with the ones you located in the registry earlier.

usb_xhci.autoconnect.device0 = "vid:0bda pid:8152"

Now, power on the VM and you will see the device is automatically connected to the VM and not the Host!

I hope this has been useful. I aim to get some more blog posts up on my lab setup this year, so keep an eye out if you are looking for idea’s for your own home lab.

Thanks for reading!

Failed to Deploy OVF Package – vSphere Content Libraries

Posted on by

I recently came across an issue with creating subscribed VMware Content Libraries, and deploying templates from a Content Library.

An error similar to the one below, would be received when attempting to deploy a VM template or OVF from a Content Library, or an error related to connection issues when setting up a subscribed Content Library.

Failed to deploy OVF Package.  ThrowablePrxy.cause A general system error occurred: Transfer failed.

After some investigation, I came to see that vCenter was attempting to communicate with linked vCenter’s and hosts via the web proxy that was configured in the VAMI, when attempting to deploy an OVF from a Content Library or when trying to synchronise a library.

As I didn’t want this traffic going via the proxy as it is internal traffic, a support ticket was logged. It was advised to add proxy exceptions, or bypasses, to the proxy file located here on a vCenter Server Appliance: 

/etc/sysconfig/proxy

As this information isn’t something I managed to find documented publicly and support couldn’t provide me with anything as they were using internal documentation to assist, I thought I would write a quick post on it to help anyone facing the same issue!

Note: Always test in a non production environment and contact official support channels!

To begin reviewing and editing this file, you will need to SSH to the VCSA using the below command using your SSH tooling of choice.

ssh root@vm-vcsa-01.smt-lab.local

Using the following cat command you can then view the file:

cat /etc/sysconfig/proxy

Here is what the default file looks like with the HTTP and HTTPS options set:

# Enable a generation of the proxy settings to the profile.
# This setting allows to turn the proxy on and off while
# preserving the particular proxy setup.
#
PROXY_ENABLED="no"

# Some programs (e.g. wget) support proxies, if set in
# the environment.
# Example: HTTP_PROXY="http://proxy.provider.de:3128/"
HTTP_PROXY="proxy.smt-lab.local"

# Example: HTTPS_PROXY="https://proxy.provider.de:3128/"
HTTPS_PROXY="proxy.smt-lab.local"

# Example: FTP_PROXY="http://proxy.provider.de:3128/"
FTP_PROXY=""

# Example: GOPHER_PROXY="http://proxy.provider.de:3128/"
GOPHER_PROXY=""

# Example: SOCKS_PROXY="socks://proxy.example.com:8080"
SOCKS_PROXY=""

# Example: SOCKS5_SERVER="office-proxy.example.com:8881"
SOCKS5_SERVER=""

# Example: NO_PROXY="www.me.de, do.main, localhost"
NO_PROXY="localhost, 127.0.0.1"

Take note of the section at the bottom, “NO_PROXY”. This is where we need to add the fqdn’s of any hosts and VCSA’s you wish to deploy to, or subscribe with. If however you don’t want to maintain this for each and every host, you can add a wild card:

.*.domain.name

Note the ‘.’ at the beginning!

For instance, in my lab I would add the following entry to the NO_PROXY list:

.*.smt-lab.local

To edit this we can use the VI editor (More info on using VI here.):

vi /etc/sysconfig/proxy

Edit the file to include the FQDN’s or a wildcard, based on your requirements.

# Example: NO_PROXY="www.me.de, do.main, localhost"
NO_PROXY="localhost, 127.0.0.1, .*.smt-lab.local"

I found a short period of time is needed for this to take effect. Or you can reboot the VCSA to speed things along.

Following this, you will then be able to deploy or subscribe without issue!

Hope this has been useful and thanks for reading!