VMware Cloud Community
LittleNickey
Enthusiast
Enthusiast
Jump to solution

PowerCLI 6.0R2 bug with Import-Module -Prefix?

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

-- Oskar
Reply
0 Kudos
1 Solution

Accepted Solutions
dmilov
VMware Employee
VMware Employee
Jump to solution

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

View solution in original post

Reply
0 Kudos
7 Replies
LittleNickey
Enthusiast
Enthusiast
Jump to solution

alanrenouf‌ any news on this from your team?

-- Oskar
Reply
0 Kudos
birdylarry
Enthusiast
Enthusiast
Jump to solution

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

Reply
0 Kudos
alanrenouf
VMware Employee
VMware Employee
Jump to solution

Sorry for the delay in getting back to you, I missed this somehow, I will try and get someone to look into this issue.

Blog: http://virtu-al.net Twitter: http://twitter.com/alanrenouf Co-author of the PowerCLI Book: http://powerclibook.com
dmilov
VMware Employee
VMware Employee
Jump to solution

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

Reply
0 Kudos
LittleNickey
Enthusiast
Enthusiast
Jump to solution

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?

-- Oskar
Reply
0 Kudos
jkav
Contributor
Contributor
Jump to solution

This still exists with 6.5.1

Reply
0 Kudos
LucD
Leadership
Leadership
Jump to solution

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

Reply
0 Kudos