Home > Blogs > VMware PowerCLI Blog


Announcement: Future Cmdlet Deprecation

PCLI

As many of you saw our last post “Changes to Future PowerCLI Prerequisites” which discusses a few changes that will be occurring starting in our our next release, we also wanted to make you aware of a few cmdlets that we will be deprecating as of the next release.

Normally we don’t give too many sneak peeks into future releases of PowerCLI. However, in order to provide our customers the maximum amount of time to update any scripts that may be affected by these changes and to help provide a smooth transition into the next release, we wanted to inform you all of these changes.

What will be Deprecated?

The following is a list of the cmdlets that will be deprecated as of our next release:

  • Get/Set-VMGuestNetworkInterface
  • Get/New/Remove-VMGuestRoute

In the PowerCLI documentation, these cmdlets have been noted as “…experimental and might be changed or removed in a future release. This cmdlet is not compatible with IPv6 environments.”

As per previously in PowerCLI, you will understand that when a cmdlet is ‘Deprecated’, it is not removed immediately from our product. Rather, a yellow ‘WARNING:’ appears upon use of said cmdlet informing you that it has been deprecated and will be removed in a future release. The same will happen here until the cmdlets are finally removed in a future release.

Screenshot 2014-11-25 20.54.33

Why are you doing this?

There are a couple of reasons. Initially these were created as experimental cmdlets. These cmdlets leverage scripts or “helper files” that are stored in the ‘\scripts\’ folder within the PowerCLI install directory. Different “helper files” were needed for the different OS version’s and, in the beginning, we were easily able to cover the main operating systems. Now as more and more operating systems are being run within our virtual environments and our customers require support for more and more operating systems, these helper files are needed to support all the variations of operating systems that are used.

We know how Community-driven PowerCLI is and how the community can often provide examples and solutions faster than our release cycle would let us, in this case we decided that the community was the best place for these scripts to be created and support. Instead, we have decided to leverage other powercmdlets that are already at our disposal.

In addition to the aforementioned, Microsoft has developed numerous cmdlets for modifying TCP/IP settings. This can be seen on Microsoft’s website HERE. To avoid duplication of efforts and to allow our users to only have to learn a single set of commands, rather than a Windows way and PowerCLI way together, we have gone with leveraging the Microsoft TCP/IP Powershell cmdlets.

What does this mean for me?

If you are utilizing any of these cmdlets, you will want to begin updating your scripts that utilize these experimental cmdlets. As these cmdlets will be deprecated in next release, they will still be usable for a while longer. However, they will not be supported.

There are several other ways that these commands can be utilized.

How can I tell if I am using these cmdlets?

One easy way to find out if you are currently using these cmdlets in your scripts is of course to use PowerShell to search your scripts folder for scripts containing these cmdlets, this is easily achieved using the following example, as you can see from the output, it lists the filename, the line number, and the line of code being used:

Get-ChildItem -Include *.ps1 -Recurse | Select-String -Pattern Get-VMGuestNetworkInterface, Set-VMGuestNetworkInterface, Get-VMGuestRoute, New-VMGuestRoute, Remove-VMGuestRoute

Output:

PowerCLI\Set Network Interface of My VM.ps1:4:Set-VMGuestNetworkInterface -VMGuestNetworkInterface $vmGuestNetworkInterface -GuestUser User -GuestPassword Pass02 -Netmask 255.255.255.255 -Gateway 10.23.112.58

What can I do instead?

If you haven’t had a chance to use the Invoke-VMscript cmdlet, you really should start now. It is a very powerful cmdlet that allows users to run scripts inside virtual machines. Invoke-VMscript requires a couple of parameters to run properly. Those are:

Screenshot 2014-11-25 22.31.43

  • -VM (Name of the virtual machine we will be running commands on)
  • -GuestUser or –GU (User account that will be used to run the command)
  • -GuestPassword or –GP (User Password)
  • -Scripttext (This is the command that will be run on the remote machine, generally the script will be saved as a variable and placed here)
  • -Scripttype (There are three options here: PowerShell, Bat, Bash. If the –Scripttype parameter is not used in the invoke-vmscript command, it will default to, and assume, that the script is PowerShell. It is important that you choose the right language of the script)

That’s it, so let’s see how this works! (And remember, these can be either Windows or LInux VM’s)

A) Change Network Settings for a Windows VM (equivalent of set-VMGuestNetworkInterface)

  • $IP = “10.144.99.80”
  • $Netmask = “255.255.255.0”
  • DefaultGW = “10.144.99.1”

$netsh = “c:\windows\system32\netsh.exe interface ip set address “”Local Area Connection”” static $ip $netmask $defaultgw 1″
Invoke-VMScript –VM “Test1-VCAC-IAAS”  -guestuser “administrator” -guestpassword “VMware1!” -ScriptType bat -ScriptText $netsh

Screenshot 2014-11-25 21.56.57

B) Change Network Settings on a Linux VM (Many ways to do this)

  • $IP = “10.144.99.81”
  • $num = “24”
  • $DefaultGW = “10.144.99.1”

$script = @”
echo STARTMODE=auto > /etc/sysconfig/network/ifcfg-eno16777728
echo BOOTPROTO=static >> /etc/sysconfig/network/ifcfg-eno16777728
echo IPADDR=$IP/$num >> /etc/sysconfig/network/ifcfg-eno16777728
echo default $DefaultGW – – > /etc/sysconfig/network/routes ; ifdown eno16777728 ; ifup eno16777728
“@
Invoke-VMScript -VM “TEST1-Linux” -GU root -GP vmware -ScriptText $script -ScriptType bash

Screenshot 2014-11-25 22.11.31

C) Get the VM Guest Route (equivalent of Get-VMGuestRoute)

$script = “Route Print”

Invoke-VMscript –VM “Test1-VCAC-IAAS” –gu Administrator –gp VMware1! –scripttext $script

Screenshot 2014-11-25 22.13.37

D) Set the VM Guest Route (equivalent of New-VMGuestRoute)

$script = “route add $destination  mask $netmask $gateway”

Invoke-VMscript –VM “Test1-VCAC-IAAS” –gu Administrator –gp VMware1! –scripttext $script

image

E) Remove the VM Guest Route (equivalent of Remove-VMGuestRoute)

$destination = “127.0.0.1”

$script = “route delete $destination”

Invoke-VMscript –VM “Test1-VCAC-IAAS” –gu Administrator –gp VMware1! –scripttext $script

image

Conclusion

As you can see, the functionality from the deprecated cmdlets are still available today leveraging commands like invoke-vmscript and with the help of hte amazing community we will be able to utilize new ways of doing this and even more operating systems. If you have another way that you prefer to modify these settings on a guest VM, share it in the comment box below and look out for future repositories showing even more examples.

This entry was posted in Customization, General and tagged , , , on by .
Brian Graf

About Brian Graf

Brian Graf is a well-known VMware evangelist in the IT community. Over the past 5 years, Brian has done Technical Marketing for PowerCLI Automation and ESXi Lifecycle, Product Management of vCenter Distributed Resource Management features (DRS & HA), and is currently working as a Technical Marketing Manager for VMware Cloud on AWS. Brian is a co-author of the PowerCLI Deep Dive 2nd edition book. He has helped develop VMware certification courses and exams and presents around the world at VMware User Conferences, AWS Summits, Interop, as well as other industry Conferences. Brian is also a Microsoft MVP.

8 thoughts on “Announcement: Future Cmdlet Deprecation

  1. LucD

    Great idea, use the available PowerShell cmdlets instead of rolling out PowerCLI specific versions.
    Your overview of the alternatives is excellent.

    Love how you refer to the Community as a source of info 🙂

    Reply
  2. Pingback: Announcement: Future Cmdlet Deprecation | VMware PowerCLI Blog – VMware Blogs | vRealize

  3. Pingback: Modifying guest network interface with the Invoke-VMScript cmdlet | Deans Blog

  4. Max

    Invoke-VMScript it’s a great tool, but it useless when guest is linux and ssh use keys but not passwords 🙁

    Reply
  5. Alan Renouf

    Max,

    Im not aware of the issue you talk about here, Invoke-VMScript does not use SSH, for more information on the process it uses please see here: http://www.vmware.com/files/pdf/techpaper/vsphere_powercli51r1_technote.pdf

    Let me know if i am missing the issue here.

    Reply
    1. Max

      Yes, I know that it does not use ssh 🙂
      But in our environment we use ssh/keys and can’t change and even don’t know our passwords… this is our password policy…
      I understand, this is not vmware issue but sad…..

      Reply
      1. Alan Renouf

        I see, yeah that’s a tough one, the price of security I guess 🙂

        Reply
  6. SysAdmin-E.com

    At first I was disappointed that these commands were deprecated, but then after testing this new method, I see that it’s much more powerful in that it allows sys admins to invoke pretty much any Windows or Linux command within the guest and goes beyond just network config. So we are not limited to scripts or commands provided by VMware.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

*