How to copy ISO files between datastores via PowerCLI


We decided to replace our current central ISO datastore to a new one on different storage. You can use the CP commend on the Service Console, if you’re still running ESX classic. But I wanted to investigate if there was a way to do this with PowerCLI. Well there is cmdlet for that called Copy-DatastoreItem. In the PowerCLI help you will find something like this:

Copy-DatastoreItem

Synopsis Copies items between datastores and between a datastore and a local file system provider.

Syntax Copy-DatastoreItem [-Item] [[-Destination]] [-Force] [-PassThru] [-Recurse] [-WhatIf] [-Confirm]

But how do you find the datastore where you want to copy files from?  Well you need to keep in mind the following two objects. The Folder, if you created one (1) and the Datacenter where the Datastore belongs to (2):

image

Now that you know the path to the datastore containing the files you want to copy. You can start PowerCLI and connect to your vCenter server. Before you continue, you need to create a temp directory to temporarily save the ISO files in. In my case this is E:\iso. The one-liner will look like this:

Copy-DatastoreItem vmstore:\Alkmaar\DataCenter\template-01\iso\* E:\iso

And now we wait until the files are copied to the temp directory:

image

The next step is to copy the files from the temp directory to the new datastore.

Copy-DatastoreItem E:\iso\* vmstore:\DataCenter\template-01\iso\

And we wait again:

image

How to return HP Serial Number via iLO and Powershell


Robert van den Nieuwendijk created the basis of this script and shared it on the VMware Communities. The problem I had with the original script was the default SSL certificate which HP uses on the iLO adapters. This resulted in an error and the script failed to return the XML file. So I started a search query on Google and found a post by Paul Brice who had the same problem while getting information via XML on an Iron Port setup. I tried his code to open the iLO XML information and it worked like a charm.

So I updated the script from Robert and added the information from Paul to it. The last thing I changed was the $url and added a RegEx to return the digits from the ESX hostname. For example esx72, the RegEx will return the 72.

Get-VMHost | Where-Object {$_.Manufacturer -eq "HP"} | `
Sort-Object -Property Name | ForEach-Object {
    $VMHost = $_
    $netAssembly = [Reflection.Assembly]::GetAssembly([System.Net.Configuration.SettingsSection])
    IF($netAssembly) {
        $bindingFlags = [Reflection.BindingFlags] "Static,GetProperty,NonPublic"
        $settingsType = $netAssembly.GetType("System.Net.Configuration.SettingsSectionInternal")
        $instance = $settingsType.InvokeMember("Section", $bindingFlags, $null, $null, @())
        
        if($instance) {
            $bindingFlags = "NonPublic","Instance"
            $useUnsafeHeaderParsingField = $settingsType.GetField("useUnsafeHeaderParsing", $bindingFlags)

            if($useUnsafeHeaderParsingField) {
                $useUnsafeHeaderParsingField.SetValue($instance, $true)
            }
        }
    }

    [int]$ip = (([regex]'\d+').matches($vmhost.Name) | select Value).Value

    [System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}
    $url = "https://192.168.1.$ip/xmldata?item=All"
    $xml = New-Object System.Xml.XmlDocument
    $xml.Load("$url")
        New-Object PSObject -Property  @{
            "Name" = $VMHost.Name
            "Serial Number" = $xml.RIMP.HSI.SBSN
            "ILO Serial Number" = $xml.RIMP.MP.SN
            "ILO Type" = $xml.RIMP.MP.PN
            "ILO Firmware" = $xml.RIMP.MP.FWRI    
          }
} | Export-Csv -NoTypeInformation -UseCulture -Path C:\EsxSerialNumbers.csv 

The output of the script will be exported to a CSV file.

Disk Hard disk # has incorrect changed block tracking configuration


Today another Veeam troubleshooting trick. It’s possible that you’ll receive the following error in one of your Veeam Backup Jobs:

Verifying change block tracking:
Disk “Hard disk 1” has incorrect changed block tracking configuration

This is how it looks like in the Veeam Backup console:

image

The procedure which Veeam describes in the solution for this problem works like this:

  1. Shutdown the VM
  2. VM – Edit Settings – Options – General – Configuration Parameters…
  3. Change every item with ctkEnabled to false
  4. Start the VM
  5. Start the Backup Job to see if this is the solution for this problem.
  6. This is how you change the parameter to false:

image

In my case, the above solution did not solve the problem. So I had to troubleshoot the VM. While checking the configuration a noticed that the Disk was configured with the Independent mode enabled. You can change this setting when the VM is powered off. Go to Hardware, select the Hard disk and disable the checkbox by Independent:

image

The setting above can only be changed when the VM is powered off, if you’re using the vSphere client. It’s also possible to change this setting, on-the-fly with PowerCLI. That rimes Winking smile.

You can run the following one-liner to disable the Independent mode:

Get-VM <vmName> | % { Get-HardDisk -VM $_ | Where {$_.Persistence -eq "IndependentPersistent"} | `
% {Set-HardDisk -HardDisk $_ -Persistence "Persistent" -Confirm:$false} }

Disclaimer: this one-liner worked for me in my environment but test this first because I don’t know exactly what the impact is of this change.

PowerCLI: Easy iSCSI Send Target setup


In January this year I created a post about Easy NFS datastore setup with PowerCLI. In this post I showed how you can use a reference host to copy all the NFS share configurations to the new host. In this post I will show you how to do the exact same thing only for iSCSI Send targets. I finally find some time to write this post which I promised to write in part 2 of my PowerCLI and iSCSI series.

The following script will check the $REFHOST, in my case esx2.ict-freak.local for all the iSCSI Send targets configured on that host. After that the script will check if all the iSCSI Send targets exists on the $NEWHOST. If this is not the case the script will add the missing Send Targets.

$REFHOST = Get-VMHost "esx2.ict-freak.local"
$NEWHOST = Get-VMHost "esx1.ict-freak.local"

$REFHBA = Get-VMHostHba -VMHost $REFHOST -Type iScsi | Where {$_.Model -eq "iSCSI Software Adapter"}
foreach($target in (Get-IScsiHbaTarget -IScsiHba $REFHBA -Type Send)){
    $target = $target.Address
        $NEWHBA = Get-VMHostHba -VMHost $NEWHOST -Type iScsi | Where {$_.Model -eq "iSCSI Software Adapter"}
        If ((Get-IScsiHbaTarget -IScsiHba $NEWHBA -Type Send | Where {$_.Address -eq $target} -ErrorAction SilentlyContinue )-eq $null){
            Write-Host "Target $($target) doesn't exist on $($NEWHOST)" -fore Red
            New-IScsiHbaTarget -IScsiHba $NEWHBA -Address $target | Out-Null
        }        
}

But there is more..

Read more of this post

PowerCLI: Return the iSCSI Software Adapter


In my previous postsabout how to manage iSCSI targets with PowerCLI part 1 and part 2. I used the following line to return the iSCSI adapter:

$hba = $esx | Get-VMHostHba -Type iScsi

But when I used this line against a vSphere 4.1 update 1 host with Broadcom BCM5709 (Dell Poweredge R710). vSphere will use these adapters as Broadcom iSCSI Adapters. And when you run the $hba = $esx | Get-VMHostHba -Type iScsi one-liner, it will return all the vmhba adapters.

[vSphere PowerCLI] C:\> $esx | Get-VMHostHba -Type iScsi

Device     Type         Model                          Status

——     —-         —–                          ——

vmhba32    IScsi        Broadcom iSCSI Adapter         unbound

vmhba33    IScsi        Broadcom iSCSI Adapter         unbound

vmhba34    IScsi        Broadcom iSCSI Adapter         unbound

vmhba35    IScsi        Broadcom iSCSI Adapter         unbound

vmhba37    IScsi        iSCSI Software Adapter            online

This “problem” can easily be resolved with a Where statement. In the following Where statement you look for a Model that equals “iSCSI Software Adapter”. There is only one Software adapter in ESX(i) so it will return the right vmhba. The PowerCLI line will look like this:

$esx | Get-VMHostHba -Type iScsi | Where {$_.Model -eq "iSCSI Software Adapter"} 

[vSphere PowerCLI] C:\> $esx | Get-VMHostHba -Type iScsi | Where {$_.Model -eq "iSCSI Software Adapter"}

Device     Type         Model                          Status

——     —-         —–                          ——

vmhba37    IScsi        iSCSI Software Adapter         online

So the bottom line. Test your code on different setups and update it when necessary ;-)

PowerCLI: Error 1406. Could not write value InstallPath to key….


Today I wanted to install PowerCLI on a new installed Windows 2008 R2 server. But I ended up with the following warning:

image

To fix this, you have to delete the following Registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\VMware, Inc.

And press retry. The PowerCLI setup will finish without errors.

 

Source: http://www.annoying.dk

Storage vMotion only one hard disk to another datastore in vSphere


Sometimes it’s necessary to only migrate a single hard disk from a VM. This is the case when someone adds two 1 TB VMDK’s and fills them up completely. The maximum size of a VMFS datastore is 2TB minus 512 bytes. So in this case the datastore will be completely filled with no space left to keep the VM running. So if you want  to migrate just one hard disk to make sure the VMFS datastore will not fill up. You can use the vSphere client or PowerCLI to do perform this “advanced” Storage vMotion.

Note: if you want to reclaim your “wasted” storage back from your SAN, you have to recycle the whole datastore. So you have to migrate the other hard disks and configuration files as well.

vSphere Client

Start the Migrate Virtual Machine wizard and select datastore:

image

Read more of this post

PowerCLI: Host Networking Device info


In this post I will share a simple PowerCLI script which generates some Network Device information from your vSphere hosts. The information you’ll get is the vmHost name, device name, linkspeed and MAC address.

$vmHostNicInfo = @()
foreach($vmHost in (Get-VMHost | Sort Name)){
    foreach($nic in $vmhost.NetworkInfo.PhysicalNic){ 
        $Details = "" | Select vmHost, Device,Linkspeed,Mac

        $Details.vmHost = $vmhost.Name
        $Details.Device = $nic.Extensiondata.Device
        $Details.Linkspeed = ($nic.Extensiondata.Linkspeed).SpeedMB
        $Details.Mac = $nic.Extensiondata.Mac
    
        $vmHostNicInfo += $Details
    }
}
$vmHostNicInfo | Format-Table -AutoSize

The output will look like this:image

But what if you only want to see the devices with a link speed lower then 1000? Well that’s possible with the following end line:

$vmHostNicInfo | Where {$_.Linkspeed -lt "1000"} |  Format-Table -AutoSize

image

Or if you want to know which device/host belongs to a particular MAC address. You can use the following end line:

$vmHostNicInfo | Where {$_.Mac -eq "00:07:e9:1f:f9:bf"} |  Format-Table -AutoSize

image

So with a small script, you’re able to export valuable data.

PowerCLI: VMware Tools one-liners


In this post I’ll show you three PowerCLI one-liners to perform some operations with VMware Tools.

The first one-liner will return all Powered on VM’s with Windows selected as guest OS and perform a VMware Tools upgrade without a reboot at the end.

Get-VM | Where {$_.PowerState -eq "PoweredOn" -and $_.Guest.OSFullName -match "Win*"} | % {Update-Tools -VM $_ -NoReboot}

Sometimes if you want to perform a vMotion or when you try set a host in maintenance mode, the VM won’t vMotion away from the host. Most of the time this is caused by a mounted ISO from a locale datastore. In my environment this is not possible because I use a shared storage datastore to storage all the ISO files. But there is one ISO that’s mounted from a locale datastore, this is the VMware Tools ISO.  Sometimes the ISO isn’t automatically dismounted from the VM. This one-liner creates a list of VM’s where the VMware Tools ISO is mounted:

(Get-VM | Get-View | Where {$_.Runtime.ToolsInstallerMounted}) | % {$_.Name}

The last one-liner will dismount the VMware Tools if necessary:

(Get-VM | Get-View | Where {$_.Runtime.ToolsInstallerMounted}) | % {Dismount-Tools -VM $_.Name}

I think there will be a lot more possibilities to script with PowerCLI and VMware Tools. So if you have a question or an idea, please leave a comment below.

vCenter Update Manager PowerCLI: Error 1722 Windows Installer


Today I was building a new Windows 7 View Desktop in my home lab. PowerCLI and vCenter Update Manager cmdlets where of course the first things I wanted to install. But during the setup of vCenter Update Manager PowerCLI I received the following error:

image

I was trying to install VMware-UpdateManager-Pscli-4.0.0-233997.exe after downloading the new version: VMware-UpdateManager-Pscli-4.1.0-266648.exe I was able to install the vCenter Update Manager cmdlets again. So if you’re running Windows 7 and want to use the vCenter Update Manager PowerCLI cmdlets, just install the latest version and you don’t get the this error.

 

Source http://communities.vmware.com/thread/257870
Follow

Get every new post delivered to your Inbox.

Join 1,108 other followers