This week VMware released a major update to Horizon (View).

• Horizon 7.1 Release Notes
• VMware Horizon 7.1 Is GA! What’s New – Part 1
• VMware Horizon 7.1 Is GA! What’s New – Part 2
• Horizon 7.1 Download Page

I’ve been using Horizon 7.1 for a few weeks and I wanted to share my Top 3 features with you. They are in no particular order.

1. VMware Horizon Virtualization Pack for Skype for Business (Beta)

This is something I’ve been waiting for, for a long time. With the Horizon Desktop I use internally in VMware, this is the only thing that has been stopping me from going ‘all in’ 100% VDI. Until now, I’ve been making my Skype for Business calls via the client which is installed on my laptop. Now I can finally move everything inside the virtual desktop, including my voice and video calls.

Making Audio/Video calls in a virtual desktop has a long history of pain which goes back to my early days here at VMware. If you were to install the Skype For Business client into a virtual desktop environment and use it as if it was installed on your local PC/Laptop, you encounter an issue which we term ‘Media hairpinning’. What happens here is, all of your Audio/Video traffic gets streamed via the virtual desktop infrastructure, rather than going point-to-point or ‘end user’ to ‘end user’. For example, we might have two users on the West coast of the US. Their Horizon environment is located on the East coast. When they Skype called each other, User A’s  Audio/Video would travel from their end point on the West coast, to their virtual desktop on the East coast, to User B’s virtual desktop on the East coast and then to User B’s end point on the West coast. (See below)

The distance that the traffic has to travel can cause Audio/Video performance to be really poor. What we ideally want is for the Audio/Voice traffic to got direct, from User A to User B, point-to-point.

And this is essentially what the VMware Horizon Virtualization Pack for Skype for Business does for us.

As mentioned above, this feature is currently in Beta. Do not let that deter you, I’ve been using it for a little while and it seems to be functioning really well. When testing it with my colleagues, they are unable to tell if I am calling from my laptop or within my Horizon desktop. From the end user perspective, there are a few things that I’ve noticed which have slightly different behavior from the native client. For example, my mute button on my headphone lead no longer mutes me in the client and when someone is talking in a group chat the little window which usually shows the profile photo of who is talking doesn’t seem to update. Honestly, this isn’t a problem for me.

If you use Skype For Business within your company, I highly recommend that you test it out even whilst it is in Beta. The requirements are very basic and configuration is very straight forward unlike the old LyncVDI Plugin.

You can read more about it here: https://blogs.vmware.com/euc/2017/03/vmware-horizon-virtualization-pack-skype-for-business-beta.html and download the software and documentation here: https://communities.vmware.com/community/vmtn/beta/horizon-skype4business-beta/overview

Read the rest of this entry »

Over the past few days I've been looking into deployment tools to help me deploy a large amount of ESXi Host's in a short space of time. One of the tools I've been looking at is VMware Auto Deploy

VMware Auto Deploy

The auto deploy application which comes as an OVT template is basically just a jumped-up vMA, with the added extra's of DHCP, TFTP, HTTP servers and a deploy-cmd CLi and Database.

Here is a brief overview of how VMware Auto Deploy works once configured:

• PXE boot the target server
• ESXi is installed onto the target server from the auto deploy app
• The ESXi host will then be added into your vCenter
• The ESXi host will then have a Host Profile applied to it.

This makes life pretty easy.

What I didn't know and it didn't mention on the labs site was that the ESXi install was Stateless. The ESXi install is only held in memory. So if you reboot the server you'd see a "No Operating System Found" message.

Before VMware Auto Deploy, I hadn't ever given Stateless ESXi a second thought. The configuration of a host once ESXi was installed was a lot more detailed than the initial install itself and took time to complete. Now with the use of Host Profiles we are able to Install and Configure an ESXi host within a matter of minutes and 100% automatically. At this rate I'll be doing myself out of a job! However, I also believe it's the way most large deployments will head in the not so distant future. We are beginning to see an increase in the amount of diskless servers/blades coming onto the market, which is ushering us down the route of using Stateless installs. 

I'm not going to go into the in's and out's of the application configuration as it's all available in the VMware Auto Deploy Administrator's Guide. It's very simple

Like most VI Admins, I've been using VMware ESXi quite a lot more lately and I'm slowly coming across things that are different to how they are in ESX. Log files being one of these differences.

With the absence of the Service Console, ESXi presents a slightly different architecture. If you haven't yet read The Architecture of VMware ESXi, I would recommend having a good read through.

Differences between ESX and ESXi logs

Here is the common log file structure in ESX (Source)

• /var/log/vmware/hostd.log – ESX Service Log
• var/log/vmware/vpx/vpxa.log – vSphere Client Agent Logs
• /var/log/vmware/aam – VMware HA Logs
• /var/logvmkernel – VMKernel Messages
• /var/log/vmkwarning – VMKernel Warnings
• /var/log/messages – Service Console Log

Here is the common log file structure in ESXi

• /var/log/vmware/hostd.log – ESXi Service Log
• var/log/vmware/vpx/vpxa.log – vCenter Agent Logs
• /var/log/messages – Syslog Log (Combines vmkernel & hostd)

Read the rest of this entry »

This is something I did a while ago, but it came to my attention that people didn't; a) Know that it's recommended to use a syslog server with ESXi b) You could use an application built in to vMA called vilogger.

Although it is stated in The Architecture of VMware ESXi…..

Because the in-memory file system does not persist when the power is shut down, log files do not survive a reboot. ESXi has the ability to configure a remote syslog server, enabling you to save all log information on an external system. 

…..it is not a well known fact. So that is partly the reason for writing the post. The other reason is to introduce you to vilogger, which is part of the vMA. Of course you can use which ever syslog server you wish,  if you plan to use your own, be sure to checkout Managing VMware ESXi page #68 to view the configuration steps.

I'm not going to take you through the steps of installing vMA, nor am I going to tell you all about what the vMA (vSphere Manage Assistant) does. If you want to read more about that please find the relevant links in the Sources section at the bottom of the page. But I am going to take you through the steps I took to use vMA as my ESXi syslog server.

Read the rest of this entry »

Just a quick post about using ESXTOP with VMware ESXi. Obviously in ESXi there is no Service Console so we have to use the vMA (vSphere Management Assistant) to help us. If you haven't installed the vMA on your infrastructure yet, you can download it here: http://www.vmware.com/support/developer/vima/

Once install and configured, login and run the following command: resxtop –server <server name>

You will be prompted to login, use the root user/pass of the Host you want to run ESXTOP on (Note: Logging in as root will not work if the Host is in "Lockdown Mode".). You should then be presented with ESXTOP, I believe it has all of the same function as it did in the Service Console

Here you can see all avaliable options when connecting to a Host using RESXTOP

usage: resxtop [-h] [-v] [-b] [-s] [-a] [-c config file] [-d delay] [-n iterations]
               [--server server-name [--vihost host-name]] [--portnumber socket-port] [--username user-name]
              -h prints this help menu.
              -v prints version.
              -b enables batch mode.
              -s enables secure mode.
              -a show all statistics.
              -c sets the esxtop configuration file, which by default is .esxtop4rc
              -d sets the delay between updates in seconds.
              -n runs resxtop for only n iterations.
              --server      remote server name.
              --vihost      esx host name, if --server specifies vc server.
              --portnumber  socket port, default is 443.
              --username    user name on the remote server.
       for more information on interactive and batch modes
       please see man page for resxtop.

	

Just lately I’ve been creating a lot of PowerCLI scripts to help configure various aspects of out ESX environment. We’ve just implemented a new NTP Server to our network. So I was given the job to update all of our ESX Hosts. I didn’t fancy spending all morning manually changing them, so I set to work in creating a PowerCLI script to do the business. Here is the result.

$Cluster = "<cluster name>" 
$Hosts = Get-Cluster $Cluster | Get-VMHost 
ForEach ($Host in $Hosts) 
{ 
Remove-VmHostNtpServer -NtpServer "<old ntp server>" -VMHost $Host | Out-Null  
Add-VmHostNtpServer -NtpServer "<new ntp server>" -VMHost $Host | Out-Null 
Get-VmHostService -VMHost $Host | Where-Object {$_.key -eq "ntpd"} | Restart-VMHostService -Confirm:$false | Out-Null 
write "NTP Server was changed on $Host" 
}

Introduction and Requirements– Part 1
Testing and Exporting to vSphere – Part 2

Customising the ESXi Rapid Deployment Server

I couldn't just stop there could I? I decided to make a few alterations to make it a little prettier and hopefully quicker.

Removing some ESXi installation steps which are not required

I'll start off by talking about making some changes to the ESXi installation to help make the deployment a little quicker. I got the idea from Stuart Radnidge's great post; Unattended ESXi Installation. Stu talks about editing one of the Python files that make-up the ESXi installation. Stu has a link to a pre-prepared Install.tgz for you to replace the default Install.tgz that comes in the ESXi ISO. Unfortunately this wouldn't work for me as I was using the ESXi ISO that comes with HP Management Agents so I had to make the changes myself:

Read the rest of this entry »

Introduction and Requirements – Part 1
Customising and Optimising – Part 3

Testing The PXE Boot System

Now that the PXE Server is configured I quickly made a VM in VMware Workstation to deploy ESXi to using the settings in a previous post I wrote.

Here are the steps and settings I used.

• Create a Virtual Machine, Custom
• Workstation 6.5-7.0 Hardware Compatibility
• VMware ESX, ESX Server 4.0
• Number of processors: 1
• Memory: 2048
• Host-Only Networking
• LSI Logic,
• New disc, SCSI
• 30GB, pre-allocated, single file
• Customise hardware, remove: soundcard, USB, floppy –  Set execution mode to:  IntelVT-x  — Customise hardware, add: 5 x Network Adapter’s (Host-Only Networking)
• Edit .vmx and add the following
  • ethernet0.virtualDev = “e1000”
  • ethernet1.virtualDev = “e1000”
  • monitor_control.restrict_backdoor = “true”

PXE Booting the ESXi ready VM displayed the default deployment menu that is shipped with the V-PXEServer application.

Read the rest of this entry »

Testing and Exporting to vSphere – Part 2
Customising and Optimising – Part 3

Introduction

With VMware ESXi looking to be the future of VMware's Hypervisors, we are seeing the end of our beloved Service Console. Like many others I've been beginning to look into how ESXi will be implemented into a Production environment. One of the main area's of interest for me was around setting up a system which would deploy ESXi Hosts.

In the past, when deploying ESX Hosts, I've had the assistance of EDA (ESX Deployment Application), others have also used UDA (Ultimate Deployment Appliance). But due to the absence of the Service Console, scripted installations using Kickstart scripts are now not possible with ESXi.

When looking for a new deployment system to deploy ESXi I was looking for the following requirements;

• Simple Setup – I don't have the time to spend days and days on configuring an application to deploy my Hosts
• Simple Deployment – I want the deployment procedure to be a simple as possible. The deployment of Hosts maybe passed to a team that aren't as accustomed to VMware as I am.
• Quick – I want the deployment of my ESXi Host to be quick, I don't want to have to wait an hour for a Host.
• FREE! – We all love free, espically my CEO.

Read the rest of this entry »

VMware have just released a new KB article 1003490 which focuses on restarting the Management agents on both ESX and ESXi Hosts from Version 3 through to Version 4.

Restarting the management agents on Hosts is often used when you are unable to connect your ESX/ESXi Hosts to vCenter or you can’t connect directly to your Hosts using the VMware Infrastructure Client.

The KB Article explains other symptoms which can be resolved by restarting the agents, it also be contains two video’s, one for ESX and one for ESXi (Shown below)

Read the rest of this entry »