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.
...now browsing by category
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.
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…
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.
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.
Insert a correct network configuration and click Next and then Finish.
The networking configuration is ready.
Click on Storage Adapters. if iSCSI Software Adapter is not installed, click on Add.. and install it.
Right click on the iSCSI Software Adapter and select 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).
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.
If you looked carefully during iSCSI Software Adapter configuration you might have noticed that there is an additional tab called Network Configuration.
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…
Select the unused vmnic, click Next twice and then Finish. Close vSwitch proprieties. Now our network configuration looks like this:
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:
Let’s go back to Storage Adapters and to Software iSCSI Adapter properties. Click on Network Configuration tab and click on Add…
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.
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.
Then go back to iSCSI Software Adapter’s properties, to Network configuration tab. Click on Add… and you will see both iSCSI VMkernel ports.
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.
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
- 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.
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…
You should not do it however if you’re planning to run these machines on 4.x hosts. Click Yes to continue
and wait for the upgrade to finish.
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.
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.
If you have not created any baseline for VMs before, the window will be empty.
In the upper-right corner click on Admin View… Click on View Baselines for VMs/VAs button.
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.
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.
As one can see, the VM’s VMware tools and virtual machine hardware version are up-to-date.
Then I moved the VM to a 5.1 host, attached again the baselines and scanned the machine.
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.
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.
You can also set different schedules for VMs in different states:
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.
When the remediation process is completed you will see that gues is compliant with the VMware Tools baseline.
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 summary tab of the VM reports the same:
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”.
The VM is stored on the VMFS I datastore:
where one can also see a folder called .dvsData. Let’s have a look inside:
In the .dvsData folder there is a sub-folder which name suits the UUID of the distributed switch:
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:
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:
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:
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.
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…