Author Archives: Irina Nikolova

Support for Virtual Machine SCSI Controllers in PowerCLI 4.1.1

If you’ve ever missed the ability to manage virtual SCSI controllers with PowerCLI, your problem is now solved. The latest PowerCLI release introduces a new group of cmdlets for getting, creating and updating SCSI controllers of virtual machines. You can choose between different SCSI controller types and between different SCSI bus sharing modes. You can also filter the SCSI controllers by several filters: virtual machines, virtual hard disks, templates and snapshots. Here are few examples of usage of the new cmdlets:

Get-VM “VM” | Get-ScsiController
Retrieves the SCSI controllers of the specified virtual machine.

New-ScsiController -HardDisk $hardDisk-Type VirtualBusLogic -BusSharingMode NoSharing
Creates VirtualBusLogic SCSI controller with no sharing support and attaches the specified virtual hard disk to it.

Set-ScsiController -ScsiController $scsicontroller –Type VirtualLsiLogic -BusSharingMode Virtual
Updates an existing SCSI controller’s type and sharing mode.

Besides, you can create a new hard disk by specifying an existing SCSI controller and change the SCSI controller of an existing hard disk. New-HardDisk and Set-HardDisk cmdlets are enhanced with a new “Controller” parameter that accepts objects returned by New\Set\Get-ScsiController cmdlets.

Note that you won’t find a Remove- ScsiController cmdlet. The reason is that you cannot remove a SCSI controller used by at least one virtual hard disk. If a SCSI controller becomes unused by any hard disk, it is automatically removed.

For more details about the support for virtual machine SCSI controllers, check out the PowerCLI cmdlet reference and the online documentation.

 

Enhanced VMkernel Networking Configuration in vSphere PowerCLI 4.1

You can now use PowerCLI to manipulate VMKernel networking and routing. There is a new functionality that supports setting a default gateway for VMKernel networks as well as creating, removing and updating of host routes.


Here is an example illustrating how to set a default gateway for VMKernel. All you need is to have a configured VMKernel adapter in the same subnet as the gateway you want to set to default. Let’s say you want to set a default gateway 10.21.84.1. First you should check which VMKernel adapter to use:


Get-VMHostNetworkAdapter  -VMKernel | select ‘Ip’, ‘SubnetMask’, ‘DeviceName’


IP     SubnetMask    DeviceName


——————-    ———- ———-


10.21.84.39   255.255.255.0     vmk1


10.21.113.249    255.255.252.0     vmk0



 



You should select the vmk1 network adapter which is in the same subnet as the default gateway:


# Example 1: Setting the default VMKernel gateway


$net = Get-VMHostNetwork


$net | Set-VMHostNetwork -VMKernelGateway ‘10.21.84.1’ -VMKernelGatewayDevice ‘vmk1’



 


The next example illustrates creating a VMKernel route that splits the VMKernel traffic. Looking at the previous example you can see that the vmk0 device is in a subnet with a host IP range (10.21.112.1 – 10.21.115.254). Below there is a sample code that splits the VMKernel traffic for the (10.21.113.0 – 10.21.113.255) and (10.21.114.0 – 10.21.114.255) subnets to different gateways:


# Example 2: Creating host routes


New-VMHostRoute -Destination ‘10.21.113.0’ -PrefixLength 24 -Gateway ‘10.21.113.1’


New-VMHostRoute -Destination ‘10.21.114.0’ -PrefixLength 24 -Gateway ‘10.21.114.1’



 



You can remove these routes using the Get-VMHostRoute and Remove-VMHostRoute cmdlets:


#Example 3: Removing host routes


Get-VMHostRoute  | where { $_.Destination -eq “10.21.113.0”} | Remove-VMHostRoute


Get-VMHostRoute  | where { $_.Destination -eq “10.21.114.0”} | Remove-VMHostRoute



 


For more details about host routing with PowerCLI 4.1, see the cmdlets help and the online documentation.



Regards,


Gospodin Gochkov

New Nested Properties for Navigating to Parent Objects in PowerCLI 4.1

While automating with PowerCLI scripts, you have most probably stumbled upon a situation when you need to access the parent of an object – the virtual machine of a CD drive, the host of virtual machine, the cluster of a host etc. In PowerCLI 4.0 U1 all object types which have “parents” are enhanced with the “Parent ID” property. Using this property you can easily get the parent object by invoking the corresponding Get-* cmdlet and filtering by ID. In the latest PowerCLI 4.1 release these “child” object types are enhanced with an even more useful nested property which holds the parent object itself. Using the nested parent object you can access the parent right away without the need to invoke an additional Get-* cmdlet.

Here is a simple example that illustrates the reference to the parent objects in PowerCLI. Let’s assume you have retrieved a virtual machine from your environment and for some troubleshooting reason, you need to check the time zone of the host where the virtual machine is running on. To do it, you have to access the host (parent object) of the virtual machine and get the value of its Timezone property.

Here is how this simple scenario can be achieved with PowerCLI 4.0 U1 by using the “VMHostID” property of the virtual machine object:

> $vm = Get-VM -Name "myVM" -Location "MyCluster"

> (Get-VMHost -ID $vm.VMHostId).Timezone

In PowerCLI 4.1 a new “VMHost” property is introduced to the “VirtualMachine” type to hold the reference to the object’s parent. So, now you can simply navigate from the virtual machine object to the time zone property of its host and no explicit retrieval with Get-VMHost is necessary:

> $vm = Get-VM -Name "myVM" -Location "MyCluster"

> $vm.VMHost.Timezone

    In addition to the child-to-parent relationship, nested properties are also used to represent another type of relationship: objects which are uniquely identified with another object. For example, besides the new “Parent” property, the “VMHost” type now has “StorageInfo”, “NetworkInfo”, “VMSwapfileDatastore”, “DiagnosticPartition”, and “FirewallDefaultPolicy” properties which let you know a whole lot more about a virtual machine host by just navigating through these properties. The new nested properties are initialized on demand, i.e. they will not be populated until the first time you access them, so no performance loss is expected when retrieving an object which has a parent property. Note that in future releases we’ll deprecate the old “Parent ID” properties so stick to nested properties when you need to access an object’s parent.

    I hope you’ll find the new nested properties useful and will start using them in your scripting activities J

 

Regards,

Irina Nikolova