VMware

Just a quick script to set the Path Selection Policy on any LUNs on a host that do not have your target policy enabled. The script sets the server to Maintenance mode first, evacuating any VMs if you are in a full DRS automated environment. While this is not strictly necessary, it was required for my production environment just to be safe. param( [string] $vCenterServer = $(Read-Host -prompt "Enter vCenter Server Name"

Recently I installed and configured a client’s new ESXi host, they’re a small company and only require a single host. The host in question was an IBM x3650 M3, an excellent workhorse for virtualisation and one of 5 or 6 of the same model that I’ve installed in the last year. In addition to the onboard Broadcom Dual Gigabit NIC, we always install at least a second Intel PCIx Dual Gigabit card for resilience/redundancy/performance.

Recently I had cause to configure iSCSI multipathing on a test ESXi server. The production environment servers use iSCSI HBAs to connect to the back end storage, so multipathing them is a straight-forward setup. It’s good practice to separate VMotion, virtual machine and iSCSI traffic, it also helps you manage those logical and physical connections. Connect to your ESXi server using the vSphere Client and select the host. Go to the configuration tab and click “Add Networking…”.

vMA is available as a Virtual Appliance (OVF) from VMware. To install it on VMware Workstation 7, open Workstation and select Import or Export to import a new OVF, the URL for the latest OVF for vMA is on the vMA download page As per this article on virtualkenneth.com, you need to edit the VMX file to change the SCSI card and OS type, otherwise you’ll have a kernel panic on boot.

I rebuilt an ESX host in my HA/DRS cluster today, following my build procedure to configure as per VMware best practices and internal guidelines. When the host was fully configured and up-to-date, I added it to the cluster and enabled HA and DRS. Then I went to generate some DRS recommendations to balance the load an ease off my overstretched host, but no recommendations were made. I couldn’t manually migrate any VMs either – it was odd, because both hosts were added into the cluster, and could ping and vmkping each other from the console.

So you’ve upgraded your ESX 3.x servers to 4.0 and you’ve upgraded your vCenter server, now you want to access the shiny new hot-add feature to upgrade some running server’s memory. Except you can’t, the feature is no-where to be seen. Something to bear in mind though, your OS needs to support hot-add, so you’ll need a Windows Enterprise or Datacenter edition. Here’s how to enable it: Upgrade the VM’s tools, if you haven’t already.

Configuring the Virtual Environment and Virtual Machines Note – this configuration will work for ESXi 4 upwards due to the server 2008 MSCS requirement for persistent SCSI-3 reservations. The first step is to create a new vSwitch for the host-only cluster heartbeat network, don’t assign any network adaptors to the switch as it’s going to be local only. Create a new virtual machine with a single hard disk. For the purposes of this test, I’ve assigned 2 vProcessors, 1GB RAM, 30GB drive for the OS, 1 vNIC in the default vSwitch0.

I’m currently in the process of migrating a 2-host High Availability cluster of ESX 3.5u4 servers to vSphere 4. This is going to come in 3 distinct stages: Stage 1 is to upgrade VirtualCenter Server 2.5 to vCenter 4, which I am going to cover today. Stage 2 is to upgrade each host, and will be covered as I do it. Stage 3 is the upgrade of the Virtual Machines to the latest VMware Tools and then the new VM hardware.

I’m migrating some hosts off of an older storage LUN, but when I drag the disk to the new Datastore with the SVMotion plug-in the job fails with the following error: The error occurs because the virtual disk cannot be moved without moving the source files, the .vmx, .vswap etc. Simply drag the entire VM, rather than the virtual disk to the new Datastore. If you’re trying to move a 2nd, 3rd or nth disk and you get this error, drag the entire VM as per above over to the new Datastore, once that’s completed, go back in to SVMotion and drag the whole VM across again, only this time before you apply, drag the nth disk back to the new Datastore.

A.K.A Why not to use snapshots I ran into a slightly confusing problem today - our SQL servers are all created with 4 disks on 4 separate LUNs (System, Swap, SQL Data and SQL Logs). When viewing the server through Virtual Center I couldn’t see all of the LUNs, just the System LUN. It’s not a major problem as the VM can see the storage, but a little annoying when you have to remember what LUN the disks are on.