So prior to PowerCLI 5.1 Release 2 there was not a lot you could script with PowerCLI regarding the VMWare Distributed vSwitch (I deliberately use different names and abbreviations for the VDS as the official name changed over time and I lost track).
But now with the Release 2 there are a whole bunch of new cmdlets to work with VDS. Having these new cmdlets and the added support for vCloud Director 5.1 will give the VCD admin a lot of new automation possibilities.
I won't write a blog post on the new VDS cmdlets, for this I refer you to the blog post of Alan Renouf on Virtu-al.net.
A other thing supported by PowerCLI 5.1 Release 2 is PowerShell v3.0 and it's enhancements, one cool and very handy feature I want to point out. This feature is very handy when your new to PowerShell or PowerCLI and will give you a better understanding on how a command is "build". PowerCLI always had a syntax explanation of a cmdlet when you added "-Syntax" to your cmdlet, but this would give you a short description of all the parameters you could use with the specific cmdlet and is not really helpful if you do not exactly know what it is you are looking for or maybe doing wrong.
When you install PowerShell v3.0 and PowerCLI 5.1 Release 2 you can use the "show-command" cmdlet to get a small GUI for the cmdlet you want to use.
Let's look at a simple cmdlet "Connect-VIserver" you will need it for most PowerCLI scripts as this will connect you to a vCenter server(s) or ESXi Host(s).
When you run "show-command connect-viserver"
It will present a GUI in which you can enter the needed data, after when you click OK it will show and run the proper formed command to the PowerCLI prompt. This way you will know the next time how to use the cmdlet to get what you want (Ok maybe it will take you a couple of runs before you get it).
06 June, 2013
05 June, 2013
VMtools on vSphere 5.1 reboot no longer needed ?
VMware wrote in their "What's new in VMware vSphere 5.1" document that starting from version 5.1 no reboots (Zero-downtime) would be required when updating them to a newer version on a Microsoft OS (Vista and up).
Soon after they William Lam wrote a clarification blog post on the VMware blog which explained in more detail under what circumstances Zero downtime was needed when updating VMtools.
The blog post informs us that there are less VMtools update actions that need a reboot, but there are still some drivers or other components that will require a reboot when being updated or replaced.
From the vSphere (web) client you can update VMtools automatically and with advanced options you can suppress the reboot (even if it is required to complete the update).
But if you want to quickly update VMtools on multiple VMs at once then the easiest way is to do it by PowerCLI, by using a simple one-liner you can update them and suppress a reboot.
If you want more details on which update situations require a reboot, please take a look at the VMware KB2015163
Soon after they William Lam wrote a clarification blog post on the VMware blog which explained in more detail under what circumstances Zero downtime was needed when updating VMtools.
The blog post informs us that there are less VMtools update actions that need a reboot, but there are still some drivers or other components that will require a reboot when being updated or replaced.
From the vSphere (web) client you can update VMtools automatically and with advanced options you can suppress the reboot (even if it is required to complete the update).
But if you want to quickly update VMtools on multiple VMs at once then the easiest way is to do it by PowerCLI, by using a simple one-liner you can update them and suppress a reboot.
If you want more details on which update situations require a reboot, please take a look at the VMware KB2015163
vSphere 5.X Storage vMotion
VMware has addressed a lot of bugs with their Update 1a for vSphere (ESXi and vCenter), one of them being the long awaited "renaming" feature when SvMotioning a VM. This "feature" slipped into vSphere somewhere in version 4.X really as a undocumented feature, as it turned out it was pretty useful for online renaming of VM's. The team responsible for Storage vMotion thought differently and reported this as a bug that needed to be fixed, which they did with the introduction of vSphere 5.0.
After a lot of "complaints" from VMware customers around the globe they re-introduced the bug / feature again with Update 2 for vSphere 5.0, but the feature acted differently then before. The feature would now only rename the folder of the VM on the Datastore, but would not rename the files that make up the VM.
Now with vSphere 5.1 and Update 1a the latter is possible again, but not out of the box. You will need to add a advanced feature to the vCenter settings for it to work again. So now you have a choice if you want to use this renaming feature or not, which is a nice gesture but why leave it disabled by default. In my opinion it would have been better to have it enabled by default with the option to disable it. For sure there VMware will have a good reason why they didn't do it.
Anyway, if you want to use the feature and keep your VM names consistent with the corresponding folders and files on the Datastore you will have to add the following key "provisioning.relocate.enableRename" to the "Advanced Settings" in "vCenter Server Settings" the key needs to get the value "true".
After adding the key it will show up as "config.provisioning.relocate.enableRename"
After a lot of "complaints" from VMware customers around the globe they re-introduced the bug / feature again with Update 2 for vSphere 5.0, but the feature acted differently then before. The feature would now only rename the folder of the VM on the Datastore, but would not rename the files that make up the VM.
Now with vSphere 5.1 and Update 1a the latter is possible again, but not out of the box. You will need to add a advanced feature to the vCenter settings for it to work again. So now you have a choice if you want to use this renaming feature or not, which is a nice gesture but why leave it disabled by default. In my opinion it would have been better to have it enabled by default with the option to disable it. For sure there VMware will have a good reason why they didn't do it.
Anyway, if you want to use the feature and keep your VM names consistent with the corresponding folders and files on the Datastore you will have to add the following key "provisioning.relocate.enableRename" to the "Advanced Settings" in "vCenter Server Settings" the key needs to get the value "true".
After adding the key it will show up as "config.provisioning.relocate.enableRename"
And after closing "vCenter Server Settings" the renaming of VM files during a SvMotion should work.
Subscribe to:
Posts (Atom)