Yesterday I installed a couple of brand new Win2012R2 servers and of course installed PowerCLI 6.0R2.
To avoid multiple commands with the same name, we use the -Prefix parameter for the modules. This worked excellent in R1 but I'm facing issues with R2.
Loading the modules with below code:
$VMwareModules = "VMware.VimAutomation.Core", "VMware.VimAutomation.Vds"
foreach($Module in $VMwareModules){
if(!(Get-Module | ?{$_.Name -eq $Module})){
Try{
Import-Module -Name $Module -Prefix "VMW"
}
Catch{
$ErrorMessage = $_.Exception.Message
break
}
}
}
While running Get-Module now, the modules show but the Core-module does not show any ExportedCommands (which it did in R1).
Also, Core modules now shows as "script" instead of "manifest" as in R1.
Not sure if this has anything to do with it though.
When comparing the count of "VMW" commands in R1 and R2, there is missing the 300 commands from the Core-module in R2.
Is this a bug? Is there a workaround?
R2:
PS C:\> get-module
ModuleType Version Name ExportedCommands
---------- ------- ---- ----------------
Script 0.0 Initialize-VMware_VimAutomation_Vds
Manifest 3.1.0.0 Microsoft.PowerShell.Management {Add-Computer, Add-Content, Checkpoint-Computer, Clear-Con...
Manifest 3.1.0.0 Microsoft.PowerShell.Utility {Add-Member, Add-Type, Clear-Variable, Compare-Object...}
Script 6.0.0.0 VMware.VimAutomation.Core
Manifest 6.0.0.0 VMware.VimAutomation.Sdk
Binary 6.0.0.0 VMware.VimAutomation.Vds {Add-VDSwitchPhysicalNetworkAdapter, Add-VDSwitchVMHost, E...
PS C:\> get-vitoolkitversion
PowerCLI Version
----------------
VMware vSphere PowerCLI 6.0 Release 2 build 3056836
---------------
Component Versions
---------------
VMWare AutoDeploy PowerCLI Component 6.0 build 2358282
VMWare ImageBuilder PowerCLI Component 6.0 build 2358282
VMware vSphere PowerCLI Component 6.0 build 3052101
VMware VDS PowerCLI Component 6.0 build 3052101
PS C:\> (get-command *vmw*).count
33
R1:
PS C:\> get-module
ModuleType Version Name ExportedCommands
---------- ------- ---- ----------------
Script 0.0 Initialize-VMware_VimAutomation_Vds
Manifest 3.1.0.0 Microsoft.PowerShell.Management {Add-Computer, Add-Content, Checkpoint-Computer, Clear-Con...
Manifest 3.1.0.0 Microsoft.PowerShell.Utility {Add-Member, Add-Type, Clear-Variable, Compare-Object...}
Manifest 6.0.0.0 VMware.VimAutomation.Core {Add-PassthroughDevice, Add-VirtualSwitchPhysicalNetworkAd...
Manifest 6.0.0.0 VMware.VimAutomation.Sdk
Binary 6.0.0.0 VMware.VimAutomation.Vds {Add-VDSwitchPhysicalNetworkAdapter, Add-VDSwitchVMHost, E...
PS C:\> get-vitoolkitversion
PowerCLI Version
----------------
VMware vSphere PowerCLI 6.0 Release 1 build 2548067
---------------
Component Versions
---------------
VMWare AutoDeploy PowerCLI Component 6.0 build 2358282
VMWare ImageBuilder PowerCLI Component 6.0 build 2358282
VMware License PowerCLI Component 6.0 build 2315846
VMware vSphere PowerCLI Component 6.0 build 2548068
VMware VDS PowerCLI Component 6.0 build 2548068
PS C:\> (get-command *vmw*).count
322
Hello,
First I have to say you are absolutely right. This is a regression introduced in 6.0 R2 caused by updates in module's manifest that targets to address another bug. Let me give you more detail explanation about the specifics of VMware.VimAutomation.Core module.
VMware.VimAutomation.Core binary is still snap-in in 6.0 R1, 6.0R2 and 6.0 R3. That is related to some internal constraints that would be overcome in the upcoming release and the binary would be converted to module as it should be.
As VMware.VimAutomation.Core binary is snap-in PowerCLI makes it look as a module declaring a module manifest that loads the snap-in and thus loads its commands with the load of this "fake" module. Thus the VMWare.VimAutomation.Core module consist of powershell module manifest which reference a script that loads the VMWare.VimAutomation.Core binary snap-in. Both script files, the manifest and the one that loads the snap-in are in the module's folder: "<powercli install path>\Modules\VMware.VimAutomation.Core".
Now the problem you're facing is that in 6.0R1 the script that loads the snap-in was referenced in NestedModules of the module's manifest, which means all commands imported as nested module are imported in the module's session scope. That makes the snapin commands to look as module's command and that's why your use case worked with 6.0R1. The problem with that was that if someone call Remove-Module command for this module it removes the commands from the current session, and if Import-Module is called again in the same session it fails with an error "The VMware.VimAutomation.Core is already added", thus no commands are loaded once the module is removed from the current session. Because of this bug we decided not to reference the snap-in load script in NestedModules but in ModulesToProcess of the module's manifest. When it is referenced in the ModulesToProcess that makes the script commands to be loaded in the global session scope which means those command won't be removed from the session when Remove-Module is called and if Import-Module is called again it won't fail because the module manifest won't try to load the sanp-in again. Respectively when the commands are in global scope they are not affected by modules specifics and that's why they cannot be imported with the desired prefix as you wish to.
To be honest we didn't realize this side effect when we addressed the initial bug with Remove-Module. All those problems will be solved in the next PowerCLI release when VMware.VimAutomation.Core binary will become module. Until then I can suggest you a workaround with fixing the VMWare.VimAutomation.Core manifest file.In order to do that you need to open and edit <powercli install path>\Modules\VMware.VimAutomation.Core\VMware.VimAutomation.Core.psd1
the following way:
1. set ModuleToProcess to an empty string
2. set NestedModules to @('VMware.VimAutomation.Core.ps1')
This will make the module to behave the same way as in 6.0R1
Regards,
Dimitar Milov
alanrenouf any news on this from your team?
I have this same issue with Powecli 6.0 R3 on Windows 10. Running get-module doesn't show any of the powercli modules. get-vicommand does show the cmdlets from DeployAutomation and ImageBuilder but none of the vmdlets from core module.
Can somebody please help here
Sorry for the delay in getting back to you, I missed this somehow, I will try and get someone to look into this issue.
Hello,
First I have to say you are absolutely right. This is a regression introduced in 6.0 R2 caused by updates in module's manifest that targets to address another bug. Let me give you more detail explanation about the specifics of VMware.VimAutomation.Core module.
VMware.VimAutomation.Core binary is still snap-in in 6.0 R1, 6.0R2 and 6.0 R3. That is related to some internal constraints that would be overcome in the upcoming release and the binary would be converted to module as it should be.
As VMware.VimAutomation.Core binary is snap-in PowerCLI makes it look as a module declaring a module manifest that loads the snap-in and thus loads its commands with the load of this "fake" module. Thus the VMWare.VimAutomation.Core module consist of powershell module manifest which reference a script that loads the VMWare.VimAutomation.Core binary snap-in. Both script files, the manifest and the one that loads the snap-in are in the module's folder: "<powercli install path>\Modules\VMware.VimAutomation.Core".
Now the problem you're facing is that in 6.0R1 the script that loads the snap-in was referenced in NestedModules of the module's manifest, which means all commands imported as nested module are imported in the module's session scope. That makes the snapin commands to look as module's command and that's why your use case worked with 6.0R1. The problem with that was that if someone call Remove-Module command for this module it removes the commands from the current session, and if Import-Module is called again in the same session it fails with an error "The VMware.VimAutomation.Core is already added", thus no commands are loaded once the module is removed from the current session. Because of this bug we decided not to reference the snap-in load script in NestedModules but in ModulesToProcess of the module's manifest. When it is referenced in the ModulesToProcess that makes the script commands to be loaded in the global session scope which means those command won't be removed from the session when Remove-Module is called and if Import-Module is called again it won't fail because the module manifest won't try to load the sanp-in again. Respectively when the commands are in global scope they are not affected by modules specifics and that's why they cannot be imported with the desired prefix as you wish to.
To be honest we didn't realize this side effect when we addressed the initial bug with Remove-Module. All those problems will be solved in the next PowerCLI release when VMware.VimAutomation.Core binary will become module. Until then I can suggest you a workaround with fixing the VMWare.VimAutomation.Core manifest file.In order to do that you need to open and edit <powercli install path>\Modules\VMware.VimAutomation.Core\VMware.VimAutomation.Core.psd1
the following way:
1. set ModuleToProcess to an empty string
2. set NestedModules to @('VMware.VimAutomation.Core.ps1')
This will make the module to behave the same way as in 6.0R1
Regards,
Dimitar Milov
Thank you alanrenouf for getting some attention to this.
Thank you dmilov for that explanation and the workaround, now I understand why R1 works with -Prefix. And I agree that the Remove-Module bug is very annoying as well and I don't think a lot of people use the -Prefix parameter, so it's probably better to have this bug.
It's good that it will be fully converted to module in the next release, but I think I will try out your workaround with R3 just for fun, even though running R1 works with what I need right now. When is the next PowerCLI release planned?
This still exists with 6.5.1
Are you sure that is 6.5.1 and not 6.5R1?
Those are not the same!
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference