For those of you who follow me on Twitter, you may have seen a few tweets from me hinting at a vSphere deployment script that I have been working on. This was something I had initially built for my own lab use but I figured it probably could benefit the larger VMware community, especially around testing and evaluational purposes. Today, I am please to announce the release of my vGhetto vSphere Lab Deployment (VVLD) scripts which leverages the new PowerCLI 6.5 release which is partly why I needed to wait until it was available before publishing.
There are literally hundreds if not more ways to build and configure a vSphere lab environment. Over the years, I have noticed that some of these methods can be quite complex simply due to their requirements, or incomplete as they only handle specific portion of the deployment or add additional constraints and complexity because they are composed of several other tools and scripts which can make it hard to manage. One of my primary goals for the project was to be able to stand up a fully functional vSphere environment, not just deploying a vCenter Server Appliance (VCSA) or a couple of Nested ESXi VMs, but rather the entire vSphere stack and have it fully configured and ready for use. I also wanted to develop the scripts using a single scripting language that was not only easy to use, so that others could enhance or extend it further but also with the broadest support into the various vSphere APIs. Lastly, as a stretch goal, I would love to be able to run this script across the different OS platforms.
With these goals in mind, I decided to build these scripts using the latest PowerCLI 6.5 release. Not only is PowerCLI super easy to use, but I was able to immediately benefit from some of the new functionality that was added in the latest PowerCLI release such as the native VSAN cmdlets which I could use a sub-set of the cmdlets against prior releases of vSphere like 6.0 Update 2 for example. Although, not all functionality in PowerCLI has been ported over to PowerCLICore, you can see where VMware is going with it and my hope is that in the very near future, what I have created can one day be executed across all OS platforms whether that is Windows, Linux or Mac OS X and potentially even ARM-based platforms 🙂
Changelog:
- 11/22/16
- Automatically handle Nested ESXi on vSAN
- 01/20/17
- Resolved "Another task in progress" thanks to Jason M
- 02/12/17
- Support for deploying to VC Target
- Support for enabling SSH on VCSA
- Added option to auto-create vApp Container for VMs
- Added pre-check for required files
- 02/17/17
- Added missing dvFilter param to eth1 (missing in Nested ESXi OVA)
- 02/21/17 (All new features added only to the vSphere 6.5 Std deployment)
- Support for deploying NSX 6.3 & registering with vCenter Server
- Support for updating Nested ESXi VM to ESXi 6.5a (required for NSX 6.3)
- Support for VDS + VXLAN VMkernel configuration (required for NSX 6.3)
- Support for "Private" Portgroup on eth1 for Nested ESXi VM used for VXLAN traffic (required for NSX 6.3)
- Support for both Virtual & Distributed Portgroup on $VMNetwork
- Support for adding ESXi hosts into VC using DNS name (disabled by default)
- Added CPU/MEM/Storage resource requirements in confirmation screen
- 04/18/18
- New version of the script vsphere-6.7-vghetto-standard-lab-deployment.ps1 to support vSphere 6.7
-
Added support for vCenter Server 6.7, some of the JSON params have changed for consistency purposes which needed to be updated
-
Added support for new Nested ESXi 6.7 Virtual Appliance (will need to download that first)
-
vMotion is now enabled by default on vmk0 for all Nested ESXi hosts
-
Added new $enableVervoseLoggingToNewShell option which spawns new PowerShell session to provide more console output during VCSA deploy. FR by Christian Mohn
-
Removed dvFilter code, since thats now part of the Nested ESXi VA
Requirements:
- 1 x Physical ESXi host OR vCenter Server running at least ESXi 6.0 Update 2 or greater
- PowerCLI 6.5 R1 installed on a Window system
- Nested ESXi 6.0 or 6.5 Virtual Appliance OVA
- vCenter Server Appliance (VCSA) 6.0 or 6.5 extracted ISO
- NSX 6.3 OVA (optional)
- ESXi 6.5a offline patch bundle
Supported Deployments:
The scripts support deploying both a vSphere 6.0 Update 2 as well as vSphere 6.5 environment and there are two types of deployments for each:
- Standard - All VMs are deployed directly to the physical ESXi host
- Self Managed - Only the Nested ESXi VMs are deployed to physical ESXi host. The VCSA is then bootstrapped onto the first Nested ESXi VM
Below is a quick diagram to help illustrate the two deployment scenarios. The pESXi in gray is what you already have deployed which must be running at least ESXi 6.0 Update 2. The rest of the boxes is what the scripts will deploy. In the "Standard" deployment, three Nested ESXi VMs will be deployed to the pESXi host and configured with vSAN. The VCSA will also be deployed directly to the pESXi host and the vCenter Server will be configured to add the three Nested ESXi VMs into its inventory. This is a pretty straight forward and basic deployment, it should not surprise anyone. The "Self Managed" deployment is simliar, however the biggest difference is that rather than the VCSA being deployed directly to the pESXi host like the "Standard" deployment, it will actually be running within the Nested ESXi VM. The way that this deployment scenario works is that we will still deploy three Nested ESXi VM onto the pESXi host, however, the first Nested ESXi VM will be selected as a "Bootstrap" node which we will then construct a single-node vSAN to then deploy the VCSA. Once the vCenter Server is setup, we will then add the remainder Nested ESXi VMs into its inventory.
For most users, I expect the "Standard" deployment to be more commonly used but for other advanced workflows such as evaluating the new vCenter Server High Availability feature in vSphere 6.5, you may want to use the "Self Managed" deployment option. Obviously, if you select the latter deployment, the provisioning will take longer as you are now "double nested" and depending on your underlying physical resources, this can take quite a bit more time to deploy as well as consume more physical resources as your Nested ESXi VMs must now be larger to accommodate the VCSA. In both scenarios, there is no reliance on additional shared storage, they will both create a three node vSAN Cluster which of course you can expand by simply editing the script.
Deployment Time:
Here is a table breaking down the deployment time for each scenario and vSphere version:
| Deployment Type | Duration |
|---|---|
| vSphere 6.5 Standard | 36 min |
| vSphere 6.0 Standard | 26 min |
| vSphere 6.5 Self Managed | 47 min |
| vSphere 6.0 Self Managed | 34 min |
Obviously, your miles will vary based on your hardware configuration and the size of your deployment.
Scripts:
There are four different scripts which covers the scenarios we discussed above:
- vsphere-6.0-vghetto-self-manage-lab-deployment.ps1
- vsphere-6.0-vghetto-standard-lab-deployment.ps1
- vsphere-6.5-vghetto-self-manage-lab-deployment.ps1
- vsphere-6.5-vghetto-standard-lab-deployment.ps1
Instructions:
Please refer to the Github project here for detailed instructions.
Verification:
Once you have saved all your changes, you can then run the script. You will be provided with a summary of what will be deployed and you can verify that everything is correct before attempting the deployment. Below is a screenshot on what this would look like:
Sample Execution:
Here is an example of running a vSphere 6.5 "Standard" deployment:
Here is an example of running a vSphere 6.5 "Self Managed" deployment:
If everything is succesful, you can now login to your new vCenter Server and you should either see the following for a "Standard" deployment:
or the following for "Self Managed" deployment:
I hope you find these scripts as useful as I do and feel free to enhance these scripts to perform additional functionality or extend them to cover other VMware product deployments such as NSX or vRealize products for example. Enjoy!
Hi William.
This is great! - do you have any plans to release scripts to load a lab like this into workstation instead of ESXi?
Thanks
Graham
No plans, but you can definitely contribute back to the community 🙂
I see what you did there 🙂 I'm already up to my eyeballs in VMware community work but I will definitely add it to my list!
William great articles. I am new to VM and was trying to deploy the lab using your powershel script but ran into issues which i dont seem to understand and hope you or someone may shed some light into what i may have missed.
How can i share the screen shots of the errors that i am getting?
William, looking forward to trying this out on my new Skull Canyon NUC (with two NVMe SSD drives). Will this work pointed at that? I know you had some previous posts about bootstrapping into such an environment but I thought perhaps you needed some non-flash storage also?
And, it doesn't work. I believe I need storage or network (a dv switch?) configured on the physical host, which is a 6.0.0U2 booted from USB on my NUC. I think we need clarification on these two parameters:
$VMNetwork = "dv-access333-dev"
$VMDatastore = "himalaya-local-SATA-dc3500-2"
For either config, or at least (I'm trying) the self-managed:
Do these need to already exist as whatever we set them to be on the physical host? Which means we need physical storage at the lowest physical layer? This isn't clear from your instructions, which (I gathered and could be completely wrong) said the script installs it all. Too much to wish for of course. 🙂
I'll try again with a USB datastore mounted and a dv switch created. But some confirmation would be wonderful, I'd love to get this working.
Thanks much!
Really appreciate Willian! Nicely done.
Great Job!
Awesome, thank for share!
Excellent script and well explained too! Thanks William
Really you are the best thanks for all
any special requirements to the physical server that will host the lab?
and can we use the free esxi license on the physical host?
does not work with free license! no "import-vapp" allowed
[11-22-2016_03-20-24] Deploying the VCSA ...
Task failed. Status: ERROR Progress: 5% Starting VMware Identity Management
Service... Error: Problem Id: None Component key: idm Detail:
Encountered an internal error. Traceback (most recent call last): File
"/usr/lib/vmidentity/firstboot/vmidentity-firstboot.py", line 2018, in main
vmidentityFB.boot() File
"/usr/lib/vmidentity/firstboot/vmidentity-firstboot.py", line 349, in boot
self.configureSTS(self.__stsRetryCount, self.__stsRetryInterval) File
"/usr/lib/vmidentity/firstboot/vmidentity-firstboot.py", line 1479, in
configureSTS self.startSTSService() File
"/usr/lib/vmidentity/firstboot/vmidentity-firstboot.py", line 1141, in
startSTSService returnCode = self.startService(self.__sts_service_name,
self.__stsRetryCount * self.__stsRetryInterval) File
"/usr/lib/vmidentity/firstboot/vmidentity-firstboot.py", line 88, in
startService return service_start(svc_name, wait_time) File
"/usr/lib/vmware/site-packages/cis/utils.py", line 784, in service_start
raise ServiceStartException(svc_name) ServiceStartException: { "resolution":
null, "detail": [ { "args": [
"vmware-stsd" ], "id":
"install.ciscommon.service.failstart", "localized": "An error
occurred while starting service 'vmware-stsd'", "translatable": "An
error occurred while starting service '%(0)s'" } ],
"componentKey": null, "problemId": null } Resolution: This is an
unrecoverable error, please retry install. If you run into this error again,
please collect a support bundle and open a support request.
Collecting the support bundle from the deployed appliance...
anyone can help with this error?
ah, stupid me! I only forgot to activate Promiscuous Mode on physical host
Can I deploy a 6.5 lab on ESXi 6.0u2 (6.5 nested supported on 6.0 ?)
Hi William,
Very nice effort and very helpful. Thanks.
Regards,
William, excellent write up. Thanks for sharing this valuable information.
Hi William,
This is awesome...I've just binned my script for yours, it's great!
I had trouble getting the OVF configuration to stick to my nested ESXi hosts (I'm deploying to vCenter (VCSA 6.0u2)) using the "$vm.ExtensionData.ReconfigVM_Task($spec)" method.
Instead I used Get-OvfConfiguration and set the properties before using Import-VApp with the -OvfConfiguration parameter:
$ovfConfig = Get-OvfConfiguration -Ovf $NestedESXiApplianceOVA
$ovfConfig.Common.guestinfo.hostname.Value = $VMName
$ovfConfig.Common.guestinfo.ipaddress.Value = $VMIPAddress
$ovfConfig.Common.guestinfo.netmask.Value = $VMNetmask
$ovfConfig.Common.guestinfo.gateway.Value = $VMGateway
$ovfConfig.Common.guestinfo.dns.Value = $VMDNS
$ovfConfig.Common.guestinfo.domain.Value = $VMDomain
$ovfConfig.Common.guestinfo.ntp.Value = $VMNTP
$ovfConfig.Common.guestinfo.syslog.Value = $VMSyslog
$ovfConfig.Common.guestinfo.password.Value = $VMPassword
$ovfConfig.Common.guestinfo.ssh.Value = $VMSSH
$ovfConfig.Common.guestinfo.createvmfs.Value = $VMVMFS
$ovfConfig.NetworkMapping.VM_Network.Value = $network
Write-Log "Deploying Nested ESXi VM $VMName ..."
$vm = Import-VApp -Server $vCenter -VMHost $pEsxi -Source $NestedESXiApplianceOVA -OvfConfiguration $ovfConfig -Name $VMName -Location $cluster -Datastore $datastore -DiskStorageFormat thin
Hope that helps!
Hi William, thanks a lot for this awesome work!
Just for those folks like me who try to use the script with a system proxy set (even with local bypass), you'll got this kind of error until you disable it :
2016-11-24 16:15:37,447 - vCSACliInstallLogger - ERROR - An error occurred when connecting to "10.95.1.12": Failed to login to host 10.95.1.12, as user root: [Errno socket error] [Errno 1] _ssl.c:510: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
This looks like a limitation of the invoke-Expression cmdlet
For those getting this error when running the script, you need to have the PortGroup set to Ephemeral connecting to the ESXi host.
[11-27-2016_04:46:04] Deploying Nested ESXi VM vesxi65-1 ...
Set-NetworkAdapter : 11/27/2016 4:47:12 PM Set-NetworkAdapter The specified DV portgroup 'LAB-701' can not be used for vnic connection: Invalid portgroup type.
At C:\Users\anthony.spiteri\Dropbox\Files\scripts\vsan_lab_deploy_2..ps1:196 char:51
+ ... er $pEsxi | Set-NetworkAdapter -Portgroup $network -confirm:$false | ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (:) [Set-NetworkAdapter], InvalidArgument
+ FullyQualifiedErrorId : Client20_VirtualNetworkServiceImpl_TryGetAvailableDVPortGroup_NotValidPortgroupType,VMware.VimAutomation.ViCore.Cmdlets.Commands.VirtualDevice.SetNetworkAdapter
Set-NetworkAdapter : 11/27/2016 4:47:12 PM Set-NetworkAdapter The specified DV portgroup 'LAB-701' can not be used for vnic connection: Invalid portgroup type.
At C:\Users\anthony.spiteri\Dropbox\Files\scripts\vsan_lab_deploy_2..ps1:196 char:51
+ ... er $pEsxi | Set-NetworkAdapter -Portgroup $network -confirm:$false | ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (:) [Set-NetworkAdapter], InvalidArgument
+ FullyQualifiedErrorId : Client20_VirtualNetworkServiceImpl_TryGetAvailableDVPortGroup_NotValidPortgroupType,VMware.VimAutomation.ViCore.Cmdlets.Commands.VirtualDevice.SetNetworkAdapter
Great work. The deployment works great. My only problem is that the ESXi hosts deployet is not accessible through the vSphere Client or Web GUI. So, the add ESXi to cluster failed. But this is not new to me. The same thing happends to my fresh installed nested ESXi host (not with appliance). When it bootes up for the first time it is not possible to login through the vSphere Client or Web GUI with the given DHCP address. My only "fix" was to power o ff the VM (not shutdown) and power it back on. Then the password was set to blank and I could login to the address from the DHCP server. No difference if no DHCP is active and I have to configure static IP address for the first time, still unavailable. Any tips where I should start look to fix this? The pESXi have the Mac Learn dvFilter configured. This gives me headache..
Again, great job.
Cheers
Having all sorts of issues... Physical host running 6.0u2. I get an error message when configuring the nested hosts:
Set-NetworkAdapter : 12/5/2016 7:29:54 PM Set-NetworkAdapter The operation for the entity "labesx602" failed with the
following message: "Another task is already in progress."
At C:\users\Marc\Desktop\Homelab-Build\vsphere-6.0-vghetto-standard-lab-deployment.ps1:196 char:51
+ ... er $pEsxi | Set-NetworkAdapter -Portgroup $network -confirm:$false | ...
Then it continues and deploys the VCSA. at 25% done, it tries to continue the script and to connect to vcenter, and everything else fails (it's not finished deploying yet).
Any idea why these two issues arise?
Fourth reinstallation without any changes and I still get the Another task is already in progress, but this time the VCSA did install?! I don't quite understand the logic behind it all... Need some 'splaining 😉
Is this a standalone ESXi host that you're deploying to or do you have a vCenter Server as well?
Standalone. Tried on ESXi 6.5 and 6.0. Same result. Now the VCSA installs every time so no idea why it failed the first few times. Still have the other error however ("Another task is already in progress").
I'm having the same issue with a esxi host that is part of a vcenter.
First off, awesome script, thanks alot for sharing William!
For those who are having the "Another task is already in progress.” problem. This occurs when more then one network adapter object is piped to Set-NetworkAdapter on line 204 of vsphere-6.5-vghetto-self-manage-lab-deployment.ps1.
I solved it by replacing this:
$vm | Get-NetworkAdapter -Server $pEsxi | Set-NetworkAdapter -Portgroup $network -confirm:$false | Out-File -Append -LiteralPath $verboseLogFile
with this:
$adapters = $vm | Get-NetworkAdapter -Server $pEsxi
foreach ($adapter in $adapters) {
$adapter | Set-NetworkAdapter -Portgroup $network -confirm:$false | Out-File -Append -LiteralPath $verboseLogFile
}
Hi Peter,
I actually had another individual who submitted the exact same fix but haven't had time to update. I just pushed the changes this morning, so let me know if you have any issues.
While this is a wonderful script, it would be terrific if it were updated to target a vCenter rather than a single host.
thanks William.Much Appreciated.
One quick one while i am setting this up on NUC with esxi 6.5, next step would be to install windows and powershell on a VM and then run the above scripts.
I used this and it worked perfectly first time.
One feature request - given this is for lab use it'd be good to add a variable to the script to set the webclient timeout to 0 (ie no timeout). If I find time I'll have a look (I don't imagine it's difficult) but I imagine you can do it in your sleep.
In your script comments in the script under the vCenter section, you say to change the hostname to the IP if you don't have valid DNS. Have you ever had the script work without valid DNS? I tried several different configurations but it always failed during firstboot. I'm not sure that vCenter can be installed without valid DNS.
Hi Brandon,
Yes. If you don't have DNS at all, then you wouldn't want to make up the value of DNS property as a lookup is performed (recently ran into this as well). Go ahead and set the DNS to the same IP as your VC. This should get you past the firstboot issue which I'm guessing has something to do with STS service.
Thanks William. This is Awesome!
This will save me some serious time whenever starting my environment from scratch (which I do quite frequently!)
Great Job!
I wonder how can I add the hosts to the vCenter by hostname instead of IPs. Anyone knows what I would need to edit to get this accomplished?
Thanks
Nevermind. Figured it out...
How?
FYI, I used the 6.5 standard lab deployment script.
In line 320, the "Add-VMHost" command, I changed the value for the "-Name" parameter from "$VMIPAddress" to "$VMName"
Hi William,
I have the following problem when running either the "Standard" or "Self-Managed" 6.0 scripts:-
I want the VCSA to have be on a class B subnet and despite confirming that $VMNetmask = "255.255.0.0" I always end up with a VCSA having a "255.255.255.0" subnet mask. The IP address is correct but the mask is always wrong. This causes the script to fail to complete the post-deployment configurations.
Once I log on to the VCSA I can manually change the mask to establish communication. It appears that the script is ignoring the $VMNetmask variable and always defaulting to 255.255.255.0
Any ideas as to what I'm doing wrong?
Many thanks in advance.
Doh! - Just worked out what my error was. I should have set $VCSAPrefix = "16"
Using the latest script that adds vCenter deployment, the step to move VMs into a vApp fails if using an ESXI deployment. The moveVMsIntovApp variable is initialized to 1 at the top of the script and never changed. It should be set to 0 if DeploymentTarget -eq "ESXI" somewhere.
Great to be able to deploy a whole environment in 29 minutes!
Right, the vApp is only applicable for when deploying to vCenter Server. I'll add some logic to ensure that it only runs when deploymentTarget is VCENTER. Thanks for feedback
[02-15-2017_10:08:09] Disconnecting from new VCSA ...
[02-15-2017_10:08:09] vSphere 6.5 Lab Deployment Complete!
[02-15-2017_10:08:09] StartTime: 02/15/2017 09:45:43
[02-15-2017_10:08:09] EndTime: 02/15/2017 10:08:09
[02-15-2017_10:08:09] Duration: 22.44 minutes
And I can mess it up, and redeploy if needed. This is beyond awesome!
Hi William,
I want to install esxi servers in another vlan, how can we specify vlan id in script ?
Do you have any plans to extend the scripts ? like deploying multiple vsan clusters using same scripts .
Thanks,
Surya
The Nested ESXi VMs only support native VLANs, this is the most common way folks are deploying this in the lab. Not saying other method isn't valid, but I chose to optimize on the 80%. If you need to provide a VLAN ID, then you can deploy the Nested ESXi VM to a known native VLAN, then using the vSphere APIs (includes PowerCLI), you can create a new VMkernel which accepts VLAN ID (basically, handle this as part of a custom post-deploy)
In terms of multiple vSAN Clusters, there's no plan atm
Hi William, could you point me in the direction within the .ovf where I could use "vSphere 6.0 Standard" but with multiple nics?
Finally got some time to test your script - awesome work, William. You saved me a heaps of time.
Had a minor issue with it. If I configure script to update hosts to 6.5, but don't choose to deploy NSX manager the update process fails because vESXi servers haven't booted yet. The script tries to update the first server right after it completed deployment of the last. In my case I had only 3 vESXI and the first one was ready yet for an update.
I also deployed the nested lab using NSX virtual switches in my physical setup. So, network is nested as well 🙂 to make it more interesting it is possible to enable VLAN tagging on virtual switches.
Are you planning to continue developing this script? It would be great to have an option to deploy 2 sites with vCenters in ELM.
I am also thinking to re-use some parts of this script https://powernsx.github.io/2016/11/14/NSX-Full-Stack-Deployment.html to automate configuration of NSX - preparing hosts, creating logical switches, configuring DRL and deploying 3-tier web app.
Thanks again. that's gonna be my favourite tool for the next year 🙂
I threw in a "start-sleep -seconds 120" after the OVA deploy loop to fix the issue with the upgrade failing.
Actually, this doesn't work either. It seems like updating from a local file doesn't work, at least not with the 6.5d patch. The only way I've been able to get it to work is to put it on a web server and use -WebPath with Install-VMHostPatch. Any ideas?
Hi Matt,
I am not sure if you resolved your issue but I was having a similar issue when deploying NSX on the nested ESXi vms. In the script I disabled deployment of VCSA,ESXi and vsan configs and only configured it to deploy NSX and set it up.
When trying to connect to the NSX Manager, the NSX Manager VM would not have booted yet and the script would fail. To avoid this I added the below code just after
"if($configureNSX -eq 1 -and $DeployNSX -eq 1 -and $setupVXLAN -eq 1) {"
My-Logger "Waiting for NSX Manager to boot..."
do {
sleep 1
} until(Test-NetConnection $NSXHostname -Port 443 -WarningAction SilentlyContinue| ? { $_.TcpTestSucceeded } )
This was the resulting output:
[06-12-2017_09:40:58] Disconnecting from vcenter65-1.nested.local ...
[06-12-2017_09:40:58] Waiting for NSX Manager to boot...
[06-12-2017_09:45:36] Successfully logged into NSX Manager nsx63-1.nested.local
...
[06-12-2017_09:45:36] Registering NSX Manager with vCenter Server vcenter65-1.ne
sted.local ...
[06-12-2017_09:45:59] Registering NSX Manager with vCenter SSO vcenter65-1.neste
d.local ...
[06-12-2017_09:46:12] Disconnecting from NSX Manager ...
[06-12-2017_09:46:12] vSphere 6.5 Lab Deployment Complete!
[06-12-2017_09:46:12] StartTime: 06/12/2017 09:38:20
[06-12-2017_09:46:12] EndTime: 06/12/2017 09:46:12
[06-12-2017_09:46:12] Duration: 7.86 minutes
This can be modified and placed in your script to wait for the nested ESXi vms.
Note: Make sure promiscuous mode is set to Accept on the vSwitch of the physical server, otherwise it will not communicate with the VMs running on the nested ESXis
Thanks for this awesome script William.
Just tired this script. Errored out me. Any ideas?
Import-VApp : 04/04/2017 19:05:54 Import-VApp A general system error
occurred:
At C:\Users\x\Desktop\vLamAuto\vsphere-6.5-vghetto-standard-lab-deployment.ps1:
446 char:19
+ $vm = Import-VApp -Server $viConnection -Source
$NestedESXiAppliance ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~
+ CategoryInfo : NotSpecified: (:) [Import-VApp], SystemError
+ FullyQualifiedErrorId : Client20_VappServiceImpl_ExportVApp_Error,VMware
.VimAutomation.ViCore.Cmdlets.Commands.ImportVApp
...er...fixed the issue...had the ESXI in maintenance mode...I was playing with another script and got over excited.
Hi William, nicely done scripting. WOW.. awsome.
But I got some error. Everytime i activate the vsan I get a "network partition state" of my vESXi Hosts. I can do what I want, no chance to get rid of this error. I can setup a seperate vnic with an uplink to an external switch or not... enabling igmp snooping on external switch, with v3 or v2, nothing, it makes no diffrence.
Do you have some tipps for me? We have production support at vmware, so i called them today. They only told me, its not a supported installation. But everywhere in the web the nested vsan is working fine. But not here in my LAB? 🙁
Hi Great Work !
I'have few errors at the end of vsan setup with the standard script :
New-VsanDiskGroup : 19/05/2017 14:35:10 New-VsanDiskGroup VSAN runtime fault
on server '/VIServer=itc.infra\[email protected]:443/': Unknown
server error.
At C:\Users\admin\Desktop\vmware\Vmware deploy.ps1:872 char:13
+ New-VsanDiskGroup -Server $vc -VMHost $vmhost -SsdCanonic ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (:) [New-VsanDiskGroup], ViErro
r
+ FullyQualifiedErrorId : Storage_Impl_VsanServiceImpl_ErrorCreatingDiskGr
oup,VMware.VimAutomation.Storage.Commands.Cmdlets.Vsan.NewVsanDiskGroup
This error repeat for all of my esxi.
Can you help ?
Thx
Hi,
Doing the standard setup. I get similar error as the one above:
[06-27-2017_09:55:22] Creating VSAN DiskGroup for vesxi65-1.vsphere.local ...
New-VsanDiskGroup : 27.06.2017 21:55:23 New-VsanDiskGroup VSAN runtime fault on server '/VIServer=vsphere.local\[email protected]:443/': Unknown server erro
r.
At C:\Vmware\vsan-lab.ps1:873 char:13
+ New-VsanDiskGroup -Server $vc -VMHost $vmhost -SsdCanonic ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (:) [New-VsanDiskGroup], ViError
+ FullyQualifiedErrorId : Storage_Impl_VsanServiceImpl_ErrorCreatingDiskGroup,VMware.VimAutomation.Storage.Commands.Cmdlets.Vsan.NewVsanDiskGroup
Please help someone, I am this close to getting it all to work...
I had the same error as the above two posts.
New-VsanDiskGroup : 6/28/2017 9:50:31 AM New-VsanDiskGroup VSAN runtime fault on server '/VIServer=lab.local\[email protected]:443/': Unknown server error.
+ New-VsanDiskGroup -Server $vc -VMHost $vmhost -SsdCanonic ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (:) [New-VsanDiskGroup], ViError
+ FullyQualifiedErrorId : Storage_Impl_VsanServiceImpl_ErrorCreatingDiskGroup,VMware.VimAutomation.Storage.Commands.Cmdlets.Vsan.NewVsanDiskGroup
And I think (at least) in my case the reason is that my host doesn't have any SSD drives. For VSAN there is a minimum requirement of having at least one SSD. Sooooo I think I need to get a SSD before I can continue! I hope I'm wrong.
Hi William. As in my previous post I had assumed that the error is due to not having a SSD on the physical host, well that was a wrong assumption. I added a 256GB SSD and the error remains. Don't know what am I doing wrong!
+1. Getting the same "New-VsanDiskGroup" error as above on a NUC i7 with a single Samsung 960 EVO M.2 installed. Any help would be appreciated.
Great Script!! Works perfectly on my New Intel NUC Skull Canyon / 32GB DDR4 G.Skill Ripjaws Memory / 512GB Samsung 960 Pro SSD
Actually I did get the New-VsanDiskGroup” error as above but still worked in the end
A few minor changes if downloading the latest 6.0u3 VCSA and deploying from that, the JSON is slightly different:
$config.'target.vcsa'.esxi.hostname = $bootStrapNode
$config.'target.vcsa'.esxi.username = "root"
$config.'target.vcsa'.esxi.password = $VMPassword
$config.'target.vcsa'.esxi.datastore = "vsanDatastore"
Also it appeared to have failed during following too,
$config.'target.vcsa'.network.'dns.servers'[1] = $null
And I added a -Force to the end of the New-AdvancedSetting commands to get rid of the red text, as it appears to be already set on the VM.
Either way is working perfectly now. 🙂
Also deployed another lab for a friend to use, but got rekt by promisc not being enabled, as a test, you could add in the following to the top before it attempts the deploy:
Try { $Promisc=Get-VDPortGroup -name $VMNetwork | Get-VDSecurityPolicy | Select AllowPromiscuous -ErrorAction Stop
}
Catch
{
$Promisc=Get-VirtualPortGroup -name $VMNetwork | Get-VirtualSwitch | Get-SecurityPolicy | Select AllowPromiscuous -ErrorAction Stop
}
Finally
{
if ($Promisc -like "*True*") {
Write-Host "Promisc Enabled"
} else {
Write-Warning "Promisc Disabled"
}
}
This *should* warn you as to whether your port group that you're attempting to spin on has promisc enabled or not, I'm sure you can write it a little bit better than myself as when I write powershell I sound like a Cali girl.
For our lab environment, I'd like to be able to deploy NSX to the self managed vCenter in the automated deployment. any special gotchas to doing this? I assume this is basically what the NSX HOL's are doing?..
Thank you for sharing this, William. There appear to be alerts in the final script execution with creating the vApp for Nested Lab and some VSAN issues, details @ https://pastebin.com/AWb1ihk5 - Could this be an issue with the lab deployment using either the latest ESXi OVA from your site (Nested_ESXi6.5d_Appliance_Template_v1.0.ova) or possibly the VCSA (VMware-VCSA-all-6.5.0-5973321.iso) not being compatible with the script?
can we use this for deployment with physical server
This script deploys to a physical server, so yes 🙂
Hi, i'm trying this with the "vsphere-6.7-vghetto-standard-lab-deployment.ps1" script to a ESXi 6.7 host
All goes well untul it should deploy the VCSA, it's seems to just skip it (
see:
[06-13-2018_02:29:03] Deploying Nested ESXi VM vesxi67-1 ...
[06-13-2018_02:29:22] Updating VM Network ...
[06-13-2018_02:29:29] Updating vCPU Count to 4 & vMEM to 32 GB ...
[06-13-2018_02:29:30] Updating vSAN Caching VMDK size to 50 GB ...
[06-13-2018_02:29:34] Updating vSAN Capacity VMDK size to 100 GB ...
[06-13-2018_02:29:38] Adding guestinfo customization properties to vesxi67-1 ...
[06-13-2018_02:29:38] Powering On vesxi67-1 ...
[06-13-2018_02:29:39] Deploying Nested ESXi VM vesxi67-2 ...
[06-13-2018_02:29:54] Updating VM Network ...
[06-13-2018_02:30:00] Updating vCPU Count to 4 & vMEM to 32 GB ...
[06-13-2018_02:30:01] Updating vSAN Caching VMDK size to 50 GB ...
[06-13-2018_02:30:04] Updating vSAN Capacity VMDK size to 100 GB ...
[06-13-2018_02:30:07] Adding guestinfo customization properties to vesxi67-2 ...
[06-13-2018_02:30:07] Powering On vesxi67-2 ...
[06-13-2018_02:30:09] Deploying Nested ESXi VM vesxi67-3 ...
[06-13-2018_02:30:24] Updating VM Network ...
[06-13-2018_02:30:30] Updating vCPU Count to 4 & vMEM to 32 GB ...
[06-13-2018_02:30:31] Updating vSAN Caching VMDK size to 50 GB ...
[06-13-2018_02:30:34] Updating vSAN Capacity VMDK size to 100 GB ...
[06-13-2018_02:30:37] Adding guestinfo customization properties to vesxi67-3 ...
[06-13-2018_02:30:37] Powering On vesxi67-3 ...
[06-13-2018_02:30:39] Creating VCSA JSON Configuration file for deployment ...
[06-13-2018_02:30:39] Deploying VCSA ...
[06-13-2018_02:30:39] Disconnecting from ################# ...
[06-13-2018_02:30:39] Connecting to the new VCSA ...
Connect-VIServer : 6/13/2018 2:31:01 PM Connect-VIServer Could not resolve the requested VC server.
Additional Information: There was no endpoint listening at https://172.30.0.184/sdk that could accept the message. This is often caused by an incorrect address or SOAP
I've extracted the ISO to folder.
See config part of script:
# Physical ESXi host or vCenter Server to deploy vSphere 6.7 lab
$VIServer = "############"
$VIUsername = "root"
$VIPassword = "VMware1!"
# Specifies whether deployment is to an ESXi host or vCenter Server
# Use either ESXI or VCENTER
$DeploymentTarget = "ESXI"
# Full Path to both the Nested ESXi 6.7 VA + extracted VCSA 6.7 ISO
$NestedESXiApplianceOVA = "D:\labfiles\Nested_ESXi6.7_Appliance_Template_v1.ova"
$VCSAInstallerPath = "D:\labfiles\VMware-VCSA-all-6.7.0-8546234"
$NSXOVA = "D:\labfiles\VMware-NSX-Manager-6.4.1-8599035.ova"
$ESXi65OfflineBundle = "D:\labfiles\VMware-ESXi-6.7.0-8169922-depot\vmw-ESXi-6.7.0-metadata.zip" # Used for offline upgrade only
$ESXiProfileName = "ESXi-6.5.0-20170404001-standard" # Used for online upgrade only
# Nested ESXi VMs to deploy
$NestedESXiHostnameToIPs = @{
"vesxi67-1" = "172.30.0.50"
"vesxi67-2" = "172.30.0.51"
"vesxi67-3" = "172.30.0.52"
}
# Nested ESXi VM Resources
$NestedESXivCPU = "4"
$NestedESXivMEM = "32" #GB
$NestedESXiCachingvDisk = "50" #GB
$NestedESXiCapacityvDisk = "100" #GB
# VCSA Deployment Configuration
$VCSADeploymentSize = "tiny"
$VCSADisplayName = "vcenter67-1"
$VCSAIPAddress = "172.30.0.184"
$VCSAHostname = "172.30.0.184" #Change to IP if you don't have valid DNS
$VCSAPrefix = "24"
$VCSASSODomainName = "vsphere.local"
$VCSASSOPassword = "VMware1!"
$VCSARootPassword = "VMware1!"
$VCSASSHEnable = "true"
# General Deployment Configuration for Nested ESXi, VCSA & NSX VMs
$VirtualSwitchType = "VSS" # VSS or VDS
$VMNetwork = "vcplab-network"
$VMDatastore = "datastore2"
$VMNetmask = "255.255.255.0"
$VMGateway = "172.30.0.1"
$VMDNS = "172.30.0.100"
$VMNTP = "pool.ntp.org"
$VMPassword = "VMware1!"
$VMDomain = "vcplab.com"
$VMSyslog = "172.30.0.170"
# Applicable to Nested ESXi only
$VMSSH = "true"
$VMVMFS = "false"
# Applicable to VC Deployment Target only
$VMCluster = "vcplab-Cluster"
# Name of new vSphere Datacenter/Cluster when VCSA is deployed
$NewVCDatacenterName = "Datacenter"
$NewVCVSANClusterName = "VSAN-Cluster"
# NSX Manager Configuration
$DeployNSX = 0
$NSXvCPU = "2" # Reconfigure NSX vCPU
$NSXvMEM = "8" # Reconfigure NSX vMEM (GB)
$NSXDisplayName = "nsx63-1"
$NSXHostname = "nsx63-1"
$NSXIPAddress = "172.30.0.250"
$NSXNetmask = "255.255.255.0"
$NSXGateway = "172.30.0.1"
$NSXSSHEnable = "true"
$NSXCEIPEnable = "false"
$NSXUIPassword = "VMware1!"
$NSXCLIPassword = "VMware1!"
# VDS / VXLAN Configurations
$PrivateVXLANVMNetwork = "PrivateVXLANVMNetwork" # Existing Portgroup
$VDSName = "VDS-6.7"
$VXLANDVPortgroup = "VXLAN"
$VXLANSubnet = "172.16.66."
$VXLANNetmask = "255.255.255.0"
# Advanced Configurations
# Set to 1 only if you have DNS (forward/reverse) for ESXi hostnames
$addHostByDnsName = 0
# Upgrade vESXi hosts (defaults to pulling upgrade from VMware using profile specified in $ESXiProfileName)
$upgradeESXi = 0
# Set to 1 only if you want to upgrade using local bundle specified in $ESXi65OfflineBundle
$offlineUpgrade = 0
# Enable verbose output to a new PowerShell Console. Thanks to suggestion by Christian Mohn
$enableVerboseLoggingToNewShell = 1
What am i doing wrong ?
Also cannot find why VCSA is not deployed in the log.
Hi William,
Today i tried this again. still the same issue, script just skips the VCSA deployment
esxi OVF deployment by script no issue.
DNS is correct, i can deploy vcenter by hand, no issue.
I deploy this on a standalone HPE Proliant DL380 ESXi 6.7 host (latest build) with local storage.
see last part log:
[12-27-2018_03:25:33] Creating VCSA JSON Configuration file for deployment ...
[12-27-2018_03:25:33] Deploying VCSA ...
[12-27-2018_03:25:33] Disconnecting from 172.30.0.2 ...
[12-27-2018_03:25:33] Connecting to the new VCSA ...
[12-27-2018_03:25:56] Creating Datacenter VCP_DS ...
[12-27-2018_03:25:56] Creating VSAN Cluster VSAN-Cluster ...
[12-27-2018_03:25:56] Adding ESXi host 172.30.0.10 to Cluster ...
[12-27-2018_03:25:56] Adding ESXi host 172.30.0.11 to Cluster ...
[12-27-2018_03:25:56] Adding ESXi host 172.30.0.12 to Cluster ...
[12-27-2018_03:25:56] Enabling VSAN Space Efficiency/De-Dupe & disabling VSAN Health Check ...
[12-27-2018_03:25:56] Clearing default VSAN Health Check Alarms, not applicable in Nested ESXi env ...
[12-27-2018_03:25:56] Enabling vMotion on ESXi hosts ...
[12-27-2018_03:25:56] Disconnecting from new VCSA ...
[12-27-2018_03:25:56] vSphere 6.7 Lab Deployment Complete!
[12-27-2018_03:25:56] StartTime: 12/27/2018 15:24:00
[12-27-2018_03:25:56] EndTime: 12/27/2018 15:25:56
[12-27-2018_03:25:56] Duration: 1.92 minutes
any ideas.
Can this script be run under MacOX now that powershell and powercli are on the mac?
Not yet, although PowerShell for MacOS and Linux is available, its not 100% parity between the platforms. I actually ran into some of this over the weekend while updating another similiar deployment script. Having said that, I believe I've got some workarounds that'll decouple the Windows requirements today. I'm hoping I'll get some time over the coming weeks to perform some more testing, but goal is to enable all these vGhetto-Lab-Delpoyment* scripts to run on any system 🙂 Stay tuned
Ok thanks.
Hi William, I'm trying to emulate what you have done here but doing it manually and trying to figger out which storage did you use on the physical host to store the virtualized VM hosts and how did you create the shared datastore. I believe you are using a VSAN but how is it configured?
I have a Brix GB-BRi5H-8250 with 240GB SSD, 32GB RAM and ESX installed on a 32GB USB.
Thanks.
Great work on this William!
For posterity... in a recent version of PowerCLI, the Move-VM cmdlet throws an error when trying to move a VM into a vApp. Observed by Luc Dekens and confirmed as a known bug by Kyle Ruddy on Twitter.
Bottom line is that line 783 in the 6.7 script won't properly work as written. The script block can however be modified to leverage the API as Luc Dekens pointed out to move a VM into a vApp. Example of that here: https://pastebin.com/0za0TiWm and in case that page goes away...
$vapp = Get-VApp -Name TestvApp
$vm = Get-VM -Name TestVM
$spec = New-Object VMware.Vim.VirtualMachineRelocateSpec
$spec.Pool = $vapp.ExtensionData.MoRef
$vm.ExtensionData.RelocateVM($spec,$null)
Hi, tried to deploy 6.5 self managed but getting a number of issues.
The new ESXi OVA has the dvfilter changes already embedded so to prevent the error throwing, I'm commented out the two lines associated with this. Line 373 and 374.
I presume this is OK to do?
As above, the Move-VM command does not work. Not sure exactly what I need to change in the script to get this to function but I'll try what is mentioned above.
When using the self managed option, the script failed to connected to the VCSA for a network related issue that I am still working out. Rather than stopping at that point, the script carried on and modified the vCenter that the Nested ESXi VMs were created on and created a new vSAN + assocauited nested lab configs that should have been created on the self managed VCSA.
Am I missing something or should there be some logic there to cancel out in the event that the self managed VCSA is not available?
hi, william
Can I run on powershell for mac?
Hi i'm learning VSphere 6.7 via linkedin learning and they have used your script
# Physical ESXi host or vCenter Server to deploy vSphere 6.7 lab
$VIServer = "10.10.0.10"
$VIUsername = 'root'
$VIPassword = 'VMware1!'
# Specifies whether deployment is to an ESXi host or vCenter Server
# Use either ESXI or VCENTER
$DeploymentTarget = "VCENTER"
# Full Path to both the Nested ESXi 6.7 VA + extracted VCSA 6.7 ISO
$NestedESXiApplianceOVA = 'C:\Users\Admin\Desktop\VCC PROJECT FILES\Nested_ESXi6.7_Appliance_Template_v1.ova'
$VCSAInstallerPath = 'D:\'
# Nested ESXi VMs to deploy
$NestedESXiHostnameToIPs = @{
"vesxi67-1" = "10.10.0.11"
"vesxi67-2" = "10.10.0.12"
"vesxi67-3" = "10.10.0.13"
}
# Nested ESXi VM Resources
$NestedESXivCPU = "2"
$NestedESXivMEM = "6" #GB
$NestedESXiCachingvDisk = "4" #GB
$NestedESXiCapacityvDisk = "8" #GB
# VCSA Deployment Configuration
$VCSADeploymentSize = "tiny"
$VCSADisplayName = "vcenter67-1"
$VCSAIPAddress = "10.10.0.17"
$VCSAHostname = "vcenter67-1.lab.local" #Change to IP if you don't have valid DNS
$VCSAPrefix = "24"
$VCSASSODomainName = "lab.local"
$VCSASSOSiteName = "MiniProject"
$VCSASSOPassword = "VMware1!"
$VCSARootPassword = "VMware1!"
$VCSASSHEnable = "true"
# General Deployment Configuration for Nested ESXi, VCSA & NSX VMs
$VirtualSwitchType = "VDS" # VSS or VDS
$VMNetwork = "Host Network"
$VMDatastore = "pESXi67-1-VM"
$VMNetmask = "255.255.255.0"
$VMGateway = "10.10.0.2"
$VMDNS = "10.10.0.20"
$VMNTP = "pool.ntp.org"
$VMPassword = "VMware1!"
$VMDomain = "lab.local"
$VMSyslog = "10.10.0.20"
# Applicable to Nested ESXi only
$VMSSH = "true"
$VMVMFS = "false"
# Applicable to VC Deployment Target only
$VMCluster = "Primp-Cluster"
# Name of new vSphere Datacenter/Cluster when VCSA is deployed
$NewVCDatacenterName = "Datacenter"
$NewVCVSANClusterName = "VSAN-Cluster"
# Advanced Configurations
# Set to 1 only if you have DNS (forward/reverse) for ESXi hostnames
$addHostByDnsName = 1
# Upgrade vESXi hosts (defaults to pulling upgrade from VMware using profile specified in $ESXiProfileName)
$upgradeESXi = 0
# Set to 1 only if you want to upgrade using local bundle specified in $ESXi65OfflineBundle
$offlineUpgrade = 0
# Enable verbose output to a new PowerShell Console. Thanks to suggestion by Christian Mohn
$enableVerboseLoggingToNewShell = 1
I have added a portgroup "Host Network" and currently my controlcenter is using this port group named "Host Network" but when i run this script i get an error
Get-VDPortgroup : 6/20/2019 10:58:31 PM Get-VDPortgroup VDPortgroup with name 'Host Network' was not found using the
specified filter(s).
At C:\Users\Admin\Desktop\VCC PROJECT FILES\vsphere-6.7-vghetto-standard-lab-deployment(Original).ps1:434 char:20
+ ... $network = Get-VDPortgroup -Server $viConnection -Name $VMNetwork | ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (:) [Get-VDPortgroup], VimException
+ FullyQualifiedErrorId : Core_OutputHelper_WriteNotFoundError,VMware.VimAutomation.Vds.Commands.Cmdlets.GetVDPort
group
William, will you be also adding the 6.7 self-managed script anytime soon?
William
The hosts showing in pic 172.30.0.171, 172.30.0.172, 172.30.0.173 are vESXi or physical hosts.
because when i deployed vESXi logo look like VM but in your lab its vmware Host logo.
i created manually .
FYI if you are still maintaining these scripts.
if($enableVerboseLoggingToNewShell -eq 1) {..
code block is missing from the VCSA deployment to an ESXI host (it should exist around line 771). The code block only exists and works when deploying the VCSA to a vCenter Server.
Thanks Jason. I've just updated it to be included in the ESXi section
Hi William,
Thank you for the script. I have followed them for a few years and I finally got around to using it. Just some feedback.
vsphere-6.7-vghetto-standard-lab-deployment.ps1
1. If the ova and vcsa directory paths have spaces the script errors out at "Deploying VCSA ..." Invoke-Expression "$($VCSAInstallerPath).... The logs got over written, but it was something to the effect of 'D:\d_iso\VMware\vGhetto ' was not a valid command or function. The directory name was 'D:\d_iso\VMware\vGhetto Nested ESXi Lab\Nested_ESXi6.7u3_Appliance_Template_v1.ova'. When spaces were removed it worked.
2. I had multiple hosts in the management cluster and wanted to deploy to a specific host. I added a variable for the hostname and changed the select -first 1 in the deploymenttarget section to $vmhost = $cluster | Get-VMHost $DeploymentVMHost. Maybe targeting a specific host when deploying to a vcenter cluster could added as a feature in the future.
PSVersion 5.1.18362.145
VMware PowerCLI 11.3.0 build 13990089
Win1 0
Thanks again
Rob
Hi,
First, thank you for all your contributions to the community. On many occasions I have turned to your blog for inspiration.
Is there a technical reason why there is no Self-Manage version of the 6.7 deployment or is just something you have not gotten around to? Not asking you to do, but if it is the latter I will likely make the change to deploy it Self-Managed.
Thank you,
Mike
Hi
I am really struggeling to get anything usefull out of the lab deployment script.
Deploying towards VCENTER, fails with a malformed $ovfconfig since get-ovfconfiguration doesnt format it to be usable it seems.
And deploying towards ESXI, the nested appliances works, but still VCSA deployment is not completing for unknown reasons.
I really admire the effort of creating this setup, but I would love to see it actually working.
If there is anybody who has any working section of this, please let me know.
I ran the vsphere-6.7-vghetto-standard-lab-deployment.ps1 and recv' the following warning message...Creating VSAN Cluster vSphere-Cluster ...
WARNING: Parameter 'VsanDiskClaimMode' is obsolete. The VsanDiskClaimMode parameter of New-Cluster cmdlet is deprecated and will be ignored on VC version 6.7U2 onwards.
WARNING: The VsanDiskClaimMode parameter of New-Cluster cmdlet is deprecated and will be ignored on VC version 6.7U2 onwards.... how do I correct this warning message and /or what is the new cmdlet for New-Cluster, since 'VsanDiskClaimMode' is obsolete.
You should take a look at the PowerCLI cmdlet documentation which explains each cmdlet used in great detail, there you'll see the default is now "Manual" https://vdc-repo.vmware.com/vmwb-repository/dcr-public/73d6de02-05fd-47cb-8f73-99d1b33aea17/850c6b63-eb82-4d9c-bfcf-79279b5e5637/doc/New-Cluster.html. This script was created prior to this new default but as the message shows, its simply warning
Quick Question William since this thread still seems to be relatively live. With the VCSA automated Deployment, I'm getting output with the following when I run the command (it's not in the log file but in my powershell window):
Could not find the hardware virtualization key from the ESXi host
'esxi01.fqdn.com'.
The OVA seems to deploy just fine, but curious if you or anybody else has seen this error. Google came up with zilch. My physical hosts are Zen2 AMD hosts and I haven't tried the scripts against Intel hosts yet, that will be in the near future. So not sure if that is part of the issue.
Some feedback for future consumption/reference......
I'm also kind of bummed that I can't deploy the VCSA directly to a ResourcePool or a VApp. It always defaults to the root of the cluster (of the ResourcePool I told it to use in the JSON file) - which requires me to move it once it is deployed.
I've also run into issues deploying the VCSA directly to a VVOL datastore; it just won't do it. It states there is not enough storage available; which is definitely not the case in this instance. I think the 8PB that the vVol is reporting may be the problem; yeah I don't have that much either though ti would be awesome! So I have to fall back to VSAN; which is a fraction of the available storage on this system.
Any chance of a future installment where we don't redeploy the vcsa everytime but just clone a "master" with a hostname and IP address change? I know, its more difficult than it sounds but it would certainly cut down deployment times; especially on that vVol I mentioned earlier.
Re: Could not find the hardware virtualization key - This sounds like you may not have AMD-V enabled on your physical host for Virtualization. Please double check your setup
VCSA can be deployed to RP, but the script deploys to root of vSphere Cluster AND then moves it after its done. The script is open source, so you can always modify based on your own personal needs.
VVOL sounds like some other issue, suggest you take a closer look as there's probably something wrong which throws that error. I'd also suggest deploying it manually to see if it works.
No plans for "cloning" since most users will deploy this from scratch and then use it. There are many incarnations on how this type of a lab can be setup and the whole point of it being open source is that folks can adjust based on their own needs.
I am new and excited to consume your automated process for my lab. Being a newbie and all, I do have one question. Is the Nested ESX OVA a requirement for the deployment, or can the native vSphere 6.7U3 ISO format can be use?
Hi Mr Lam, can i use this Script for a vSphere 7 Evoirement? Best Regards
I would like to know the same. I want to leverage this script and deploy 7.0.2
I understand that there is no "support" for any of these things. I have asked this question in a different thread, and have not gotten any response from Mr.Lam or anyone else. Really sad, i want to learn VM and i am having difficulties with deployment.
For those interested in deploying 7.x labs, please take a look at some of the recent Automated Lab Deployment Scripts that uses 7.x as a base https://williamlam.com/home-lab
I don't re-qualify every possible combination, usually it should just work and in some cases, things may have changed. I'd book mark any Automation Lab script I produce as it'll generally favor newer vSphere releases and you can certainly comment out the non-vSphere specific features if you want basic lab
Hi,
Just now deployed nestd esxi OVf file, unable to login , please provide the the password.