Virtual Wood Blog

VMware, vSphere, ESX, ESXi, PowerCLi and everything else

Virtual Wood Blog - VMware, vSphere, ESX, ESXi, PowerCLi and everything else

Opening PowerCLi fails Updated

Updated from the previous post

I run Windows 7 x64 and the issue I had is when installing the latest PowerCLi the command box flashes on the screen and then disappears. It seems the issue is related to the target line in the shortcut that is used to launch PowerCLi.

Below is the original line from the installation shortcut with the bold being what causes the issue:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -psc “C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI\vim.psc1″ -noe -c “. \”C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI\Scripts\Initialize-VIToolkitEnvironment.ps1\”"

Below is what the line should be changed to again with the text in bold that has been change:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noe -c “Add-PSSnapin VMware.VimAutomation.Core; . \”C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI\Scripts\Initialize-PowerCLIEnvironment.ps1\”"

In the above please make sure to replace ” once copied or it will not work

Once the line has been changed PowerCLi will launch and open without issue. All that is needed then is to set the signed scripts to run which is done by running the following command at the prompt:

set-executionpolicy remotesigned

Select ‘yes’ and type exit

Open PowerCLi again and you will be prompted with a fully functioning PowerCLi installation to start working with.

By Paul Wood

Configure an Apache or an IIS Web server as a patch source for vCenter Update Manager

Configure an Apache or an IIS Web server as a patch source for vCenter Update Manager

Details

You can configure either Apache or Internet Information Services (IIS) as a third-party patch source for VMware vCenter Update Manager.

Solution

To create a third-party patch source for use by the Update Manager server, perform the following steps:

  1. Install and set up the Web server software on a machine that the Update Manager server can access.
    For information about setting up an IIS Web server, see the Microsoft IIS Web site. For information about setting up an Apache Web server, see the Apache HTTP Server Project Web site.
  2. Create a folder for the patch data under the document root of the Web server, and copy the patches in the folder.
    For example, C:\inetpub\patch_data, or C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\patch_data.
  3. For IIS only, add .vib, .sig, and .xml as allowed MIME types for the Web server.
    For Apache, you can use the default settings and continue with step 6 from the procedure.

    1. Click Start > Programs > Administrative Tools > Internet Information Services (IIS) Manager.
    2. In the Internet Information Services (IIS) Manager window, select IIS Manager Information > computer_name (local computer) > Web Sites > Default Web Site.
    3. Right-click the the patch data folder and select Properties.
    4. Click HTTP Headers > MIME Types.
    5. Click New to add the MIME Types.
    6. In the Extension text field, enter .vib, .sig, and .xml. Enter one file extension for each MIME type entry.
    7. In the MIME Type field, enter application/octet-stream for .vib and .sig. For .xml, enter text/xml in the MIME Type field.
    8. Save the changes.
  4. For IIS only, set appropriate permission for the patch data folder.
    For Apache, you can use the default settings and continue with step 6 from the procedure.

    1. In the Internet Information Services (IIS) Manager window, right-click the patch data folder and select Permissions.
    2. In the Advanced Security Settings dialog box, select the Allow inheritable permissions from the parent to propagate to this object and all child objects. Include these with entries explicitly defined here and Replace permission entries on all child objects with entries shown here that apply to child objects check boxes.
  5. For IIS only, restart the IIS Admin Service in the Services Control Manager.
  6. Optionally, verify that you can access the patch data directory in a Web browser.
  7. Using the vSphere Client, connect to a vCenter Server system with which Update Manager is registered and select Home > Solutions and Applications > Update Manager in the navigation bar.
  8. Click the Configuration tab in the Update Manager Administration view.
  9. Under Patch Download Settings, click Add Patch Source.
  10. Enter the URL of the patch data folder on the Web server and, optionally, a description for the new patch source.
    For example, http://ip_address_or_hostname/patch_data/index.xml
  11. Click Validate URL to validate that Update Manager can access the patch source.
  12. Click OK.

This useful tip was taken from The VMware Guy

By Paul Wood

vSphere 5 Auto-deploy

Auto-deployt is a new feature in the up and coming release of vSphere. One of the new features of VMware vSphere is booting the ESXi hosts from PXE. This feature is called Auto-Deploy and gives you the ability to use stateless ESXi servers.

The following is taken from vclouds.nl. The actual post as shown below but if you want to comment on the main blog then please follow this link.

Below is a step-by-step guide to get you started. It assumes you use the vCenter Virtual Appliance. of course auto deploy also works with any other DHCP/TFTP server and auto-deploy itself can be installed on a Windows vCenter server as well.

  1. Open the vCenter administration webpage (:5480">https://<vcenter>:5480), Go to the services tab and make sure the ESXi services are started. If not click “Start ESXi Services”.
  2. Configure DHCPd in /etc/dhcpd.conf. Configure at least the following items.
    1. DNS / GW
    2. Subnet
    3. scope or reservations
    4. next-server
    5. filename: undinonly.kpxe.vmw-hardwired
    6. uncomment or add the keyword autoritative;
    7. My dhcpd.conflooks like this:

option domain-name "vmtopia.lab";
default-lease-time 600;
max-lease-time 7200;
autoritative;

log-facility local7; 
allow booting;
subnet 192.168.16.0 netmask 255.255.255.0 {
   range 192.168.16.150 192.168.16.160;
   next-server 192.168.16.100;
   filename "/tftpboot/undionly.kpxe.vmw-hardwired";
}

  1. bind dhcp to network interface by editing the /etc/sysconfig/dhcpd file
    Add or change this line: DHCPD_INTERFACE = “ANY”
  2. Start DHCP: service dhcpd start
  3. Make sure the boot files are in /tftpboot. The VCVA comes with the right files.
  4. Start atftpd: service atftpd start
  5. Open file /tftpboot/tramp to check if hostname is used. If no DNS available replace vcenter hostname for IP address
  6. If you want to make sure your hosts can access tftpd even if DNS fails or when hostname is not in DNS you have to edit /etc/hosts.allow. At the bottom of the file change ALL : KNOWN to ALL : ALL
  7. Poweron an ESX server. Check if it loads gPXE. As the information screen shows, it won’t boot because there is no autodeploy rule associated with that host. The host will keep rebooting so power it off for now
  8. The next step is to create autodeploy rules which associate the hosts to a boot image, host profile and a cluster or folder. The only way to create those rules is by using PowerCLI. So install the vSphere5 PowerCLI on a windows box, start it and login to vCenter using the  connect-viserver commandlet
  9. Now we have to load an ESXi depot. The default ESXi depot can be downloaded from the Vmware site <<LINK>>. Now load the depot using the following powershell command:
    Add-esxsoftwaredepot <path to depot file>
  10. In the default depot there are two image profiles. An image profile is basically a collection of VIB files. A VIB file can contain the base system, Vmware tools, drivers etc. We can show the profiles available in the depot by using:
    get-esximageprofile
  11. To make a new ESX server boot from one of the profiles we have to create a rule. A rule has three properties:
    1. Rule name: Just give a descriptive name here like “imageprofilerule”
    2. Item: this is the object you want to associate with a host or group of hosts. In this case it will be an image profile (ESXi-5.0.0-381646-standard)
    3. Pattern: The pattern defines to which hosts this rule will apply. There are a lot of different variables you can put into the pattern like: Vendor, Model, MAC, Asset Tag and IP range. For now we will just use the IP range.
  12. Create a new rule:
    new-deployrule -name imageprofilerule -item ESXi-5.0.0-381646-standard -pattern “ipv4=192.16.0.100-192.168.0.200”
  13. After creating the rule, the rule has to be added to the active rule set:
    add-deployrule imageprofilerule
    To show the current rule set use: get-deployrule
  14. Now autodeploy knows which image to boot. The host will be added to vCenter automatically but we have to tell autodeploy where to put the host (which datacenter or cluster). So let’s add another rule:
    new-deployrule -name clusterrule -item cluster1 -pattern “Model=”BL 460c G6”
    Note that i used the server model in the matching pattern here so there will be only one type of machines in the cluster.
  15. And add it to the ruleset: add-deployrule clusterrule
  16. Now poweron your ESX server and watch the magic happen :)
  17. Ater your first ESX server is started you can configure it, create a hostprofile from it and create a rule to make sure all your servers will use that hostprofile. I will discuss host profiles in another post.
    new-deployrule -name profilerule -item <hostprofilename> -ALLservers
    add-deployrule profilerule
    If you don’t want all your servers to use the same profile you can also use a pattern here instead  of “allservers”
  18. Now power on all 10000 ESX servers, don’t tell your boss you’re ready installing all servers, leave the office pretending you need to be in the datacenter and enjoy you afternoon in the pub :)

By Paul Wood

Running nested virtual machines

In this blog I will explain what changes are need to allow a nested virtual machine to be powered on inside a virtual ESX host. This is something that I have been using to allow for study of the VCAP in a limited LAB situation.

The setup I have is physical ESXi 4.1 hosts on which I made a datacenter and cluster for LAB use. Inside this cluster I built 3 ESXi 4.1 hosts which have to be configured with the following disk configuration and OS selection:

  • LSI Logic SAS
  • Red Hat Enterprise Linux 6 (64bit)

Once the ESXi 4.1 hosts are built and everything else is configured the vmx file of each host needs to be edited. This will enable the virtual hosts to run virtual machines in the future. The lines that need to be added are as follows (I just added these lines to the end of the vmx file):

  • monitor_control.restrict_backdoor = "true"
  • monitor_control.vt32 = "true"

To add the above lines to the vmx file will require the file to be downloaded from the datastore and edited (for this I use Notepad++). The edited files are then uploaded back to the datastore (for good measure I remove the virtual machine and add it again to the inventory).

These additions will mean that nested virtual machines are now able to power on and the environment function like a physical one.

By Paul Wood

Changing the ip address of the vMA

During the initial setup on first boot of the vMA the configuration screen will ask questions regarding to ip address and hostname. If during this process an error has been made it is possible run the initial setup again.

I had this very issue as by mistake I selected "yes" to using DHCP. I spent some time looking at conf files but then found a reply on the VMWare forums that had the answer.

Go to the console screen of the vMA which will if it has just restarted prompting for a password to be set. Once this is complete follow the steps listed below:

  1. Press Alt F2 to get to the login screen
  2. Login using vi-admin
  3. Type cd /opt/vmware/vma/bin
  4. Type sudo ./vmware-vma-netconf.pl

This will come up with some rather comical text and the vi-admin password will need to be entered again. Once this has been entered the initial setup will run again allowing for any errors to be corrected.

By Paul Wood

Configure a LAB with simple PowerCLi commands Part 3

This blog will carry on from part 2 adding more simple functionality to the LAB being created.

In this blog we will look at adding iSCSI storage to the LAB through PowerCLi. To do this the LAB will need storage of which many are available on the internet (this can be real or virtual). The script is designed to allow the addition of a datastore with a specific ip address and name. This has not been tested in a situation where multiple iSCSI targets could reply.

This is not as hard as it may seem and with the aid of using a script every host can be configured with the same datastore in one simple script. Scripts take away human error and misconfiguration making the life of an administrator that much easier. The vSphere PowerCLI Administration Guide is a great place to start for simple scripts to help in the day to day operation of a virtual infrastructure. The following has its base taken from this guide but converted to allow the configuration of all the hosts through one script.

Below is the complete script which I will break down underneath.

<br />
  $hosts = Get-VMHost<br />
  $name = $hosts</p>
<p>Foreach ($name in $hosts) {<br />
  Get-VMHostStorage $name | Set-VMHostStorage -SoftwareIScsiEnabled $true<br />
  $iscsiHba = Get-VMHostHba -Type iScsi<br />
  $iscsiHba | New-IScsiHbaTarget -Address 10.10.1.10 -Type Send<br />
  Get-VMHostStorage $name -RescanAllHba<br />
  $lunPath = Get-ScsiLun -VMHost $name -CanonicalName ($iscsiHba.Device + &quot;*&quot;) | Get-ScsiLunPath<br />
  New-Datastore -Vmfs -VMHost $name -Path $lunpath.LunPath -Name iSCSI<br />
  }<br />
  

At the start the following two lines are carried out. This gets all the hosts that are managed by the current virtual center and stores them in $host. This information is then stored in $name to be used during the rest of the script

<br />
  $hosts = Get-VMHost<br />
  $name = $hosts<br />
  

As we want this script to run against every host that is stored in $name a Foreach is being used. This allows the script to run through each host until each is completed. The next line is retrieving the host storages on the host and then enabling the iSCSI adapter

<br />
  Get-VMHostStorage $name | Set-VMHostStorage -SoftwareIScsiEnabled $true<br />
  

The next reads in the HBA data but only for iSCSI and stores it in $iscsiHba

<br />
  $iscsiHba = Get-VMHostHba -Type iScsi<br />
  

The $iscsiHba information is then used in the following line to setup a new dynamic target with a specific ip address (using the default 3260 port. If another is needed then add –Port xxxx)

<br />
  $iscsiHba | New-IScsiHbaTarget -Address 10.10.1.10 -Type Send<br />
  

The HBA needs to be rescanned now as it would if this was being done manually so the next line does exactly that

<br />
  Get-VMHostStorage $name -RescanAllHba<br />
  

The next line is getting the canonical name of the iSCSi lun and storing this information in $lunPath

<br />
  $lunPath = Get-ScsiLun -VMHost $name -CanonicalName ($iscsiHba.Device + &quot;*&quot;) | Get-ScsiLunPath<br />
  

The last line adds the datastore that has been found during the above process. It will add a Vmfs file system to a host using the canonical name the previous line obtained and give the datastore a name if iSCSI (If the datastore with the name specified already exists then this datastore is just added to the host and can be used. I have not tested with a datastore that is not formatted to confirm that it would be formatted, named and added)

<br />
  New-Datastore -Vmfs -VMHost $name -Path $lunpath.LunPath -Name iSCSI<br />
  

By Paul Wood

Configure a LAB with simple PowerCLi commands Part 2

This blog will carry on from part 1 adding more simple functionality to the LAB being created.

The LAB has not changed since part 1 so I will not list the contents again. Please refer back to part 1 for this information.

The following will be added to the LAB in this blog:

  • NTP servers
  • Configure the 1st vSwitch by adding another vmnic
  • Create a 2nd vSwitch with vmnic added
  • Move the ‘VM Network’ portgroup from vSwitch0 to 1
  • Setup a vMotion portgroup using a csv file

To start with we will configure a couple of NTP servers (No need to change the firewall on ESXi).

I will assume that a connection to the VC through PowerCLi has been established.

Please follow the simple instructions below:

  1. Adding NTP servers to the LAB and then restarting the service:
#
#adds two ntp servers and then restarts the ntpd service
#
Add-VmHostNtpServer -NtpServer "ntp1.sandvika.net" -VMHost (Get-VMHost) -Confirm:$false
Add-VmHostNtpServer -NtpServer "ntp2d.mcc.ac.uk" -VMHost (Get-VMHost) -Confirm:$false
$ntpd = Get-VMHostService -VMHost (Get-VMHost) | where {$_.Key -eq 'ntpd'}
Restart-VMHostService $ntpd -Confirm:$false
  1. At present the two hosts that are connected in the LAB only have 1 vmnic (0) attached to vSwitch0. This means that the management vSwitch has no resilience which is of course bad. I will now show the code for adding a 2nd vmnic to this vSwitch. The first example will add the 2nd vmnic to one host and the next code will configure all the host’s the same.
#
#configures a single host vSwitch0 to have two vmnic for resilience
#
$vswitch = Get-VirtualSwitch -VMHost labnode1.lab.local -Name vSwitch0
Set-VirtualSwitch -VirtualSwitch $vswitch -Nic vmnic0, vmnic2 -Confirm:$false

Note: In the above code a single host is being interrogated and only the vSwitch called vSwitch0 is being checked. It is better to specify using –Name

#
#configures all hosts' vSwithc0 to have two vmnic for resilience
#
$hosts = Get-VMHost
$name = $hosts
Foreach ($name in $hosts)
{
$vswitch = Get-VirtualSwitch -VMHost $name -Name vSwitch0
Set-VirtualSwitch -VirtualSwitch $vswitch -Nic vmnic0, vmnic2 -Confirm:$false
}

Note In the above code I have made the code work for us. It is now reading in all the host and then passing this on to an ‘Foreach’ statement so changing all the host’s in a few lines.

  1. We will now configure a 2nd vSwitch with 4 vmnic. This will then be used for the ‘VM Network’. This will of course need to be moved from vSwitch0. The following scripts will add a new vSwitch (1) and then the following script will remove the ‘VM Network’ portgroup from vSwitch0 and create a new one on vSwitch1.
#
#creates a new switch called vSwitch1 and then adds 4 vmnic for all host's
#
$hosts = Get-VMHost
$name = $hosts
Foreach ($name in $hosts)
{
New-VirtualSwitch -VMHost $name -Name vSwitch1
$vswitch = Get-VirtualSwitch -VMHost $name -Name vSwitch1
Set-VirtualSwitch -VirtualSwitch $vswitch -Nic vmnic1, vmnic3, vmnic4, vmnic5 -Confirm:$false
}
  1. We will now remove and then create the ‘VM Network’ portgroup from vSwitch0 to vSwitch1. This will leave the management network free of virtual machine traffic.
#
#removes the 'VM Network' portgroup then creates a new one on a different switch
#
$hosts = Get-VMHost
$name = $hosts
Foreach ($name in $hosts)
{
$vswitch = Get-VirtualSwitch -VMHost $name -Name vSwitch1
$pg = Get-VirtualPortgroup -VMHost $name -Name 'VM Network'
Remove-VirtualPortgroup -VirtualPortgroup $pg -Confirm:$false
$nvmpg =  New-VirtualPortGroup -VirtualSwitch $vswitch -Name 'VM Network'
}
  1. Next we will setup a vMotion portgroup on vSwitch0 for all hosts using a csv file. Thanks has to be given to the following post which helped me get the idea for using the csv file the end product is very different. The csv file needs to be populated with the relevant information for the LAB that is being worked on. This includes the location of the csv file that will be used.
#
#for all hosts this script reads a csv file for vMotion information. This information is then used to add a vMotion portgroup to vSwitch0 adding ip, subnet and then enabling. Once that is complete the gateway is also added
#The location of the .CSV file. This can be local or on a share
#
$getinfo = Import-Csv <a href="file://\\server\share\information.csv">\\server\share\information.csv</a>
$getinfo | % {
$Type = $_.Type #!!!! Case Sensitive  !!!!!!
$gethost = Get-VMHost -Name $_.HostName
$name = $gethosts
$PortGroup = $_.PortGroupName
$IP = $_.IP
$Subnet = $_.Subnet
$kernelGW = $_.KernelGW

#Creates vMotion switch and configures vmkernel gateway (located under DNS and Routing in configuration tab)
Foreach ($name in $gethost) {
IF ($Type -eq "vMotion") {

$vswitch = Get-VirtualSwitch -VMHost $name -Name vSwitch0
$vmotion = New-VirtualPortGroup -VirtualSwitch $vswitch -Name $PortGroup
New-VMHostNetworkAdapter -VMHost $name -PortGroup $PortGroup -VirtualSwitch $vswitch -IP $IP -SubnetMask $subnet -VMotionEnabled: $true

$vmhostnetwork = get-vmhostnetwork $gethost
set-vmhostnetwork -network $vmhostnetwork -vmkernelgateway $kernelGW
}
}
}

This is all for now and I hope it has helped understand in simple examples how powerful PowerCLi is to anyone who needs to manage many hosts. I will cover in the next blog how to add storage amongst other things.

By Paul Wood