WilliamLam.com

VMware Tools 10.2.0 enables Virtual Machine vNIC exclusion and priority re-ordering

by // 8 Comments

VMware Tools 10.2.0 just GA'ed (release notes / download and open-vm-tools release notes / open-vm-tools download) and this release includes a number of new features like an offline bundle for VMware Tools VIB for ESXi and support for deploying VMware Tools using Microsoft System Center Configuration Manager (SCCM) to just name a few. There are also two additional new capabilities that I wanted to share as I think customers can benefit from and take advantage of immediately around how Virtual Machine vNICs are displayed. One of the challenges with having the broadest Guest Operating System (GOS) support in vSphere is dealing with some of the different behaviors of each GOS. One such example are the various ways in how both physical and logical networks interfaces are enumerated by an OS.

Take the example below, I have a PhotonOS VM which has eth0 as the primary interface and it is configured with an IP Address of 192.168.30.101. However, as you can see from the screenshot below I am actually getting back a different address and interface. In addition to this, we also see other logical interfaces showing up in the IP Address list such as Docker interfaces as well as virtual and other pseudo interfaces that may or may not be useful to VI Admins.


Historically, there was not a way to control what would show up in the network interface list which is then propagated from VMware Tools up to both the vSphere API as well as vSphere UI. With this new release of VMware Tools, which can be applied asynchronously to a given vSphere release, customers now have the ability to filter on a per-VM basis on what interfaces actually show up as well as a relative priority for interfaces that customers care more about.

[Read more...]

Getting started with Hybrid Cloud Extension (HCX) on VMware Cloud on AWS

by // 18 Comments

I had been hearing a lot of cool things about VMware's Hybrid Cloud Extension (HCX) but never tried the solution myself nor had a good understanding of what it actually provided. With the recently announced Hybrid Cloud Extension (HCX) on VMware Cloud on AWS (VMWonAWS) offering being available, I thought this was a great way to get hands on with HCX and take advantage of my VMWonAWS infrastructure. Having only spent a couple of days with the solution, I can see why customers are excited for HCX and the new offering on VMWonAWS makes it super easy to consume. I also recently learned that HCX is now free for all VMWonAWS customers and you can easily live migrated your VMs to/from your onPrem environment!

There are a number of impressive capabilities that HCX offers, but two that really stood out to me which I thought was quite unique and interesting compared to other VM-based "migration" options. The first is that HCX can perform live VM migrations (vMotion) or replicated migrations (vSphere Replication) which includes scheduled switch over across different versions of vSphere (vSphere 5.x to/from vSphere 6.x). This is great for customers who may not be able to upgrade their underlying vSphere environment to 6.0 or later and take advantage of things like Cross vCenter vMotion feature which only supports VM migration between vSphere 6.0u3 to/from 6.x.

The second capability is that HCX can abstract and protect the underlying ESXi hosts by not requiring direct connectivity between the source and destination ESXi hosts. Traditionally, for vMotion and vSphere Replication traffic, you either had to stretch the VLAN or ensure the VMkernel interface was routable so that it can communicate with the destination ESXi hosts for data transfers. This was not always possible and adds additional networking requirements which can be challenging to implement depending on how your network infrastructure is configured. The way HCX solves this problem is by using a special HCX Cloud Gateway which securely proxy vMotion and vSphere Replication traffic from the on-premises environment out to the respective HCX Cloud Gateway Peer which then gets transfered to destination vSphere environment. Below is a diagram to help illustrate this:


Note: HCX also supports WAN optimization (compression and de-duplication) out of the box, which the diagram includes as that is what I had deployed in my env. This is an optional virtual appliance that can be deployed at each location ensuring efficient data transfer between the source and destination vSphere environments.

While going through and getting HCX configured on both my VMWonAWS and onPrem environment, I had ran into a few minor gotchas and to help others avoid some of the issues I had ran into, I figure I would outline the process and include some additional tips that can be help.

[Read more...]

Can the VCSA 6.5 forward to multiple syslog targets?

by // 2 Comments

I had a couple folks ping me recently asking whether the latest vCenter Server Appliance (VCSA) 6.5 release supports forwarding to multiple syslog targets? Currently today, only a single syslog target is officially supported which can be configured using the VAMI UI. I know this is something our customers have been asking about and I know this is something the VC Engineering team is considering.

Having said that, it is possible to configure additional syslog targets on the VCSA, but please be aware this is not officially supported. A couple of these customers understood the support impact and were still interested in a solution as some of their environments mandated multiple redundant syslog targets and using a syslog forwarder/relay was not an option for them.

Disclaimer: This is not officially supported by VMware, please use at your own risk.

When configuring syslog forwarding from the VAMI UI, the configurations are all written to /etc/vmware-syslog/syslog.conf on the VCSA.

With this information, if we want to add additional targets (which can be of the same configuration or different), you simply append additional targets to the syslog configuration file. For example, if I have two syslog targets 192.168.30.110 and 192.168.30.111 and I wish to use the default log level, TCP and 514, I would use the following:

*.* @@192.168.30.110:514;RSYSLOG_SyslogProtocol23Format
*.* @@192.168.30.111:514;RSYSLOG_SyslogProtocol23Format

Once you have saved your changes, you will need to restart the rsyslog service for the change to go into effect. To do so, run the following two commands on the VCSA:

systemctl stop rsyslog
systemctl start rsyslog

One additional thing to note is that the VAMI UI will only show the very last syslog target within the configuration file but if you monitor syslog servers, you will see that logs are indeed being forward to all servers that have been configured in the syslog configuration file.