vCenter

...now browsing by category

 

Backup your distributed virtual switch

wtorek, Listopad 6th, 2012

I was going to wrote a tutorial how to backup a distribution switch configuration in vSphere 5.1 but I found out a terrific article wrote by Chris Wahl so I decided to simply put the link to his site as he’s done a really good job explaining step by step why and how to backup the dvs configuration. The post is here.

Definite guide to iSCSI with FreeNAS on ESX(i) – Part 4 – Configuring iSCSI on ESXi 5.1 (standard vswitch)

środa, Październik 31st, 2012

In this part of the guide we will have a look on iSCSI configuration under ESXi, in my example ESXi 5.1. The initial configuration of the host is very similar in what we saw in the previous part. There is one vSwitch and the host is equipped with 3 network interfaces.

Initial network configuration

Initial network configuration

Network interfaces (uplinks)

Network interfaces (uplinks)

Just like before we will first configure the networking part. Go to your host configuration and click on Configuration tab. Go to Networking. Click on Add Networking…

Selecting connection type for the new portgroup

Selecting connection type for the new portgroup

Select VMkernel as your connection type. You can notice that where in ESX we had 3 options to choose from (management, VMkernel, virtual machine networking), here in ESXi management networking has been merged into VMkernel stack which now is responsible for management, iSCSI connectivity, VMotion and FT logging. Select one of your NIC specifying to create a new vSwitch. Click Next.

Available uplinks

Available uplinks

Here you can see what I was talking about. Select what this VMkernel portgroup will be used for. We will use it for iSCSI traffic only (remember: traffic separation) so we don’t have to select anything. Give your portgroup a meaningful label and click Next.

Configuration for the new VMkernel port<br>

Configuration for the new VMkernel port

Insert a correct network configuration and click Next and then Finish.

IP network settings

IP network settings

The networking configuration is ready.

vSwitch for iSCSI configured

vSwitch for iSCSI configured

Click on Storage Adapters. if iSCSI Software Adapter is not installed, click on Add.. and install it.

Software iSCSI Adapter

Software iSCSI Adapter

Right click on the iSCSI Software Adapter and select Properties.

Software iSCSI Adapter properties

Software iSCSI Adapter properties

As you can see it is already enabled so no need to do it. Click on Dynamic Discovery tab and click on Add. Insert IP and port of your FreeNAS portal (check part 2 for FreeNAS installation and configuration guidance).

Dynamic Discovery

Dynamic Discovery

Click OK and Close. when asked to rescan the hba, select Yes. when everything went fine, you should see a device – a LUN presented on your FreeNAS server.

Presented LUN

Presented LUN

If you looked carefully during iSCSI Software Adapter configuration you might have noticed that there is an additional tab called Network Configuration.

Network configuration and port binding? Hm...

Network configuration and port binding? Hm...

However, we haven’t even touched it and the iSCSI storage seems to be working fine, so what’s the big deal? Well, imagine that you want (and usually you do) to use more than one NIC for iSCSI storage for multipathing and failover, you will need to bind vmknics (virtual adapters) to vmknics (physical) in 1:1 manner. Go back to Networking and click on vSwitch1 Properties. Click on Network Adapters tab and then on Add…

Adding some redundancy

Adding some redundancy

Select the unused vmnic, click Next twice and then Finish. Close vSwitch proprieties. Now our network configuration looks like this:

Second uplink added

Second uplink added

Now we will create another vmkernel portgroup on vSwitch1. The procedure is very similar to the first one except this time we add a new portgroup to the existing vSwitch. Click on vSwitch1 Properties and on Ports tab click on Add… Here’s the result:

2 uplinks, two vmkernel portgroups

2 uplinks, two vmkernel portgroups

Let’s go back to Storage Adapters and to Software iSCSI Adapter properties. Click on Network Configuration tab and click on Add…

VMkernel ports are not compliant

VMkernel ports are not compliant

Ops, there is no VMkernel adapter available except Management Network and if you select anything else you see the following message:
The selected physical network adapter is not associated with VMkernel with compliant teaming and failover policy.  VMkernel network adapter must have exactly one active uplink and no standby uplinks to be eligible for binding to the iSCSI HBA.

Why is that? That’s why. Basically, like I have mentioned before, you need to bind VMkernel port with physical uplinks (vmknics) 1:1 and if you go back to Configuration, Networking, click on vSwitch1 properties and then edit one of two VMkernel ports you will see (on NIC teaming tab) that each of them has got two NICs selected as active.

Two active uplinks for iSCSI vmkernel port? A no-no.

Two active uplinks for iSCSI vmkernel port? A no-no.

This is not a supported solution. what we need to do is to select Override switch failover order and mark one of the uplinks as unused. Then on the second VMkernel port we need to do the same, with another uplink of course.

That's better...

That's better...

Then go back to iSCSI Software Adapter’s properties, to Network configuration tab. Click on Add… and you will see both iSCSI VMkernel ports.

vmkernel ports are now compliant

vmkernel ports are now compliant

Add them both, you see they are compliant. If they are not, these are the possible reasons:

  • The VMkernel network adapter is not connected to an active physical network adapter or it is connected to
    more than one physical network adapter.
  • The VMkernel network adapter is connected to standby physical network adapters.
  • The active physical network adapter got changed.

If you’d like to know how to configure it from CLI, here’s your documentation.

Now if you right-click on the LUN presented by your FreeNAS and select Manage Paths… you will see that you can choose different path management policies for iSCSI storage.

Changing PSP for iSCSI storage is simple as that

Changing PSP for iSCSI storage is simple as that

vCenter Server 5.1.0a update – some bugs fixed

niedziela, Październik 28th, 2012

Ok, vSphere 5.1 is kinda buggy and I am not talking about functional bugs that can break your environment but rather about annoying bugs that impact administration. VMware has just release an update for vCenter – 5.1.0a that fixes some bugs like:

  • vCenter Server takes an unusually long time to start and the vSphere Client might time out

and

  • Upgrading to vCenter Server 5.1 might fail with error 29107 even though the service or solution user is already registered

and certificate issue. Have you encountered any vCenter 5.1 bug that made impossible or difficult for you to work with this release? This update can help. Release notes are here.

Upgrade to vSphere 5.1 – Part 5 – Upgrading virtual machines

poniedziałek, Październik 15th, 2012

This is part 5 of the series Upgrading to vSphere 5.1. Make sure to check out the other parts as well.

Part 1 – Upgrading a stand-alone host
Part 2 – Prerequisites for upgrading with Update Manager 1/2
Part 3 – Prerequisites for upgrading with Update Manager 2/2
Part 4 – Upgrading the hosts with Update Manager
Part 5 – Upgrading virtual machines
Part 6 – Upgrading datastores

VMware documentation on the upgrade can be found here.

In this part I will describe how to update virtual machine hardware and VMware Tools on your virtual machines individually and automatically with Update Manager.

VM hardware version 8 was introduced in vSphere 5.0 and provides a lot of benefits like 32 vCPUs per VM, 1TB of vRAM per VM, better performance and more. Version 9 came with vSphere 5.1 and offers 64 vCPUs, support for 3D acceletation in View, etc.

You should upgrade VMware Tools on your VMs as a part of regular maintenance in order to provide your VMs with best performance and out of bugs and security holes.

1. Manual upgrade

After your all hosts are upgraded to 5.x you can upgrade you virtual machines hardware version to 8 or 9. You can upgrade several machines at time by selecting them all with presses Ctrl key. Just right-click on a machine and select Upgrade Virtual Hardware…

Upgrading VM(s) manually from vsphere client

Upgrading VM(s) manually from vsphere client

You should not do it however if you’re planning to run these machines on 4.x hosts. Click Yes to continue

Check if the VMs that are to be updated will not have to run on 4.x in the future

Check if the VMs that are to be updated will not have to run on 4.x in the future

and wait for the upgrade to finish.

Upgrade completed

Upgrade completed

VM reporting hardware version 9

Manual upgrade of VMware Tools is also very simple. Select one ore more VM as before, right-click and select Guest > Install / Upgrade VMware Tools.

Upgrading VMware Tools manually

Upgrading VMware Tools manually

Mind that in order to complete the upgrade your VM will need to be rebooted. However, if you are upgrading VMware Tools on ESXi 5.1 this will be the last reboot necessary when upgrading VMware Tools – all other upgrades in the future will not require VM reboot.

2. Upgrade with Update Manager

To use Update Manager on virtual machinnes change the view to Inventory > VMs and Templates. Click on Update Manager tab.

Update Manager tab

Update Manager tab

If you have not created any baseline for VMs before, the window will be empty.

No baselines

No baselines

In the upper-right corner click on Admin View… Click on View Baselines for VMs/VAs button.

Showing existing baselines for VMs / VAs

Showing existing baselines for VMs / VAs

As you can see there are three predefined baselines and at this moment we are interested in two of them:

VMware Tools Upgrade to Match Host (will upgrade VMware Tools the the highest level available on the host your VM is located on)
VM Hardware Upgrade to Match Host (the same but for virtual machine hardware, if the hosts are 5.1 that will be version 9)

Go back to Inventory > VMs and Templates to Update Manager tab. In the left listig select a VM / folder / datacenter with VMs you’d like to upgrade. Right click and attach one or both baselines mentioned above.

Attaching the baselines

Attaching the baselines

In the example below I use a VM with Windows 7 created on ESXi 5.0 using version 7 of virtual machine hardware and VMware tools from ESXi 5.0.

When the baselines are attached, click on Scan… and confirm what you’d like to scan for.

Scanning for VMware Tools and VM hardware version

Scanning for VMware Tools and VM hardware version

As one can see, the VM’s VMware tools and virtual machine hardware version are up-to-date.

The VM is compliant with both baselines

The VM is compliant with both baselines

Then I moved the VM to a 5.1 host, attached again the baselines and scanned the machine.

On 5.1 the same VM reports non-compliant / incompatible

The machine is incompatible for the virtual machine hardware part just because VMware Tools are not updated. I will apply VMware Tools baseline to the machine.

VMware Tools are not up-to-date on this host

VMware Tools are not up-to-date on this host

On the schedule page you can see an interesting setting called Upgrade VMware Tools on power cycle that does basically what it says – upgrades the Tools when the machine reboots or powers off.

Delay VMware Tools upgrade till power cycle

Delay VMware Tools upgrade till power cycle

You can also set different schedules for VMs in different states:

Schedule your upgrade or run immediately

Schedule your upgrade or run immediately

It is also possible to take a snapshot of VMs before remediation. When you start the upgrade process and connect to the VM you will see that the upgrade is really in progress. When done, the guest will be shut down and restarted.

Automatic snapshot creation

Automatic snapshot creation

VMware upgrader process running

VMware upgrader process running

VM will be restarted

VM was restarted

When the remediation process is completed you will see that gues is compliant with the VMware Tools baseline.

VMware Tools were updated

VMware Tools were updated

Let’s scan it again for VM hardware. Incompatible changes to non-compliant. The remediation process for VM hardware is almost identical except for the fact that there is nothing to be installed on the guest OS level and the guest will be shut down at once. After a while this is the result:

The VM is fully up-to-date and compliant

The summary tab of the VM reports the same:

Hardware version 9 and current VMware Tools

Hardware version 9 and current VMware Tools

Resources

Overview of VMware Tools

Distributed virtual switch and the .dvsData folder

poniedziałek, Październik 8th, 2012

If you use a distributed virtual switch you can notice that on some of your datastores there is a folder called .dvsData. Why is it created and what it is used for? Here you will find a description of this folder’s role.

As you can see below, a virtual machine called Workstation 1 is connected to the „Virtual machines internal” vdportgroup which in turn is on the vds called simply „ds”.

Workstation 1 connected to the distributed portgroup on the distributed virtual switch

Workstation 1 connected to the distributed portgroup on the distributed virtual switch

Virtual switches view

Virtual switches view

The VM is stored on the VMFS I datastore:

Datastore view

Datastore view

where one can also see a folder called .dvsData. Let’s have a look inside:

A look inside .dvsData folder

A look inside .dvsData folder

In the .dvsData folder there is a sub-folder which name suits the UUID of the distributed switch:

Checking vds's UUID with the esxcli command

Checking vds's UUID with the esxcli command

In this subfolder you will find one more files and their numbers will suit the number of ports the virtual machine(s) is connected to:

File listing

File listing

The file name's matches the port's number

That means that .dvsData will appear on the datastore where your VM’s configuration file (vmx) is stored. If you open the configuration file you will find the same information:

VM's configuration file networking part

VM's configuration file networking part

This information is synchronized (from vmx to .dvsData folder) by the host every 5 minutes. So now you know what this folder is, why subfolder and files’ names are so strange, etc. But what’s the purpose of the .dvsData folder and its content?

It is used by HA. Imagine the situation when your host fails and HA starts a VM on another physical server. It needs to know which port is should connect the machine to. I did a very simple test – I removed the file called 264 from the datastore and I stopped the ESXi server the VM Workstation 1 was running on. A few seconds later HA detected a possible failure of the host. However this was the result on the VM:

Oops, the failover failed...

Oops, the failover failed...

Leson learnt: don’t touch the folder .dvsData unless you really know what you are doing.

PS. As you see all operations in this note were done using the new Web-Client. More on this client soon.

Changing service console IP address in ESX 4

sobota, Kwiecień 14th, 2012

VMware has got a nice step-by-step guide on how to do this here. However, I would like to mention a few important things:

- before you change the IP of the existing service console, just in case add another service console port and test you connection. You can never know :-)

- you cannot do it from vClient. Open a local console or a remote one. Modify the conf files as described in VMware KB. Restart the network service (if you use ssh console, your connection will be dropped).

- if you use VLANs, after you execute esxcfg-vswif -i a.b.c.d -n w.x.y.z vswif0, do execute the following command:

esxcfg-vswitch vSwitch0 -v vlan_number -p ‘Service Console’

where vSwithc0 is your vSwitch with service console portgroup, vlan_number is replaced with your VLAN and ‘Service Console’ is the name of the portgroup.

- if you want to change the hostname as well you will need reboot. You can change the hostname first from vClient, reboot and change IP address from the console or do all the things at the same time and reboot after that. If you do not change the hostname from ‘DNS and routing’ part in vClient, make sure you change the hostname and IP both in /etc/hosts and in /etc/vmware/esx.conf

- I found some info on the internet that to change the service console network configuration you need to delete and recreate the whole vSwitch. That’s not true.

- Last but not least, you’d better have access to the server with local cosnole (or RSA/DRAC/iLO). As I said, you never know… :-)