Now it is available my session on VMUGIT 2023
ESXi
VMware Pre Broadcom vs VMware Broadcom – Primi dati reali
Attenzione è una mia valutazione….quindi non sparate sul sistemista
Broadcom ha acquisito VMware, ormai lo sappiamo tutti.
La situazione di incertezza aleggia ovunque soprattutto sul mondo vSphere e sui costi (con tanti competitor che provano a ritagliarsi la loro fetta di mercato togliendole al leader indiscusso di questi anni)
Finalmente in questi giorni incomincio ad avere i primi dati effettivi (Prezzi ecc…) su cui iniziare a fare i primi ragionamenti.
!!Attenzione non voglio dare giudizi ma voglio solo paragonare due offerte fatte allo stesso cliente che abbiamo dovuto rivedere a seguito del nuovo listino (E parliamo di prezzi di listino.. senza eventuali scontistiche)!!
Ragioniamo su un cluster vSphere con 3 nodi da 2 processori ciascuno da 16 core.
Con le precedenti licenze e il vecchio listino nello scenaro ipotizzato dovevamo considerare:
- Licenza VMWARE VCENTER SERVER 8 STANDARD
- Licenza VMWARE VSPHERE 8 STANDARD FOR 1 PROCESSOR
- Support/Subscription
- Support/Subscription
Con il nuovo listino e le nuove tipologie di licenze invece dobbiamo considerare:
- VMWARE VSPHERE STANDARD per core (Che comprende la licenza di vCenter)
Entrambe le soluzioni con 5 anni.
Da una prima analisi le prime valutazioni sono:
Con il nuovo listino si viene a pagare circa 30-35% in meno.
Ho una semplificazione nella quotazione (una sola voce rispetto alle 4 precedenti)
Ovviamente:
- Non abbiamo le licenze perpetue (comunque chi non vuole il supporto sul proprio ambiente di produzione o la possibilità di effettuare aggiornamenti?)
- é una prima offerta e la quotazione può dipendere da vari fattori e i prezzi potrebbero nuovamente cambiare
- Le funzionalità all’interno dei bundle possono essere leggermente differenti (il link per vedere le funzionalità presenti nei nuovi bundle VMware vSphere® Product Line Comparison)
- Posso aver sbagliato i calcoli 🙂
- Possono avermi dato dei prezzi sbagliati 🙂 spero di no per il cliente 🙂
ma aspettavo di avere due informazioni reali per fare le mie prime considerazioni.
L’unica cosa che posso dire è di valutare con attenzione il cambio …. (io sono il primo che accetta nuove sfide..) ma attenzione a tutti i prezzi nascosti e valutate bene!
P.S. se qualcuno ha delle esperienze in merito … condividiamole.
Check TCP port 443
During the maintenance and updating of the Horizon Connection server components, one aspect is the necessary wait for the connection servers to correctly resume responding on TCP port 443.
During one of the many activities on Horizon my customer created a simple and effective door test script.
Even though it is very simple and intuitive, I want to share the code with you:
do {
$check = netstat -ano | findstr 0.0.0.0:443
"Waiting 5 seconds and retry"
sleep 5
} while (!$check)
$check
DRS and HPE SimpliVity
In recent days, a customer reported an anomaly on an HPE SimpliVity cluster hosting instant clone Horizon VDIs. In detail:
- vSphere with seven hosts present, two were always at 98% CPU utilization and 90% RAM utilization.
- Continuous vMotion generated by the VM DRS to and from those two HOSTS.
After a careful analysis, we identified that there were no problems at the vSphere infrastructure level.
The issue was due to a Simplivity feature called IWO.
By disabling IWO and keeping DRS active (Full automatic) I have an optimal balance of CPU and RAM load between hosts at the expense of a slight increase in I/O trip times
Scenario – Even VM Load Distribution
I want even VM load across my cluster in terms of CPU and memory. Data locality and I/O performance are not top priorities. Most applications are CPU and memory intensive, and adding 1ms to 2ms to I/O trip times will not impact application performance.
In this scenario, IWO can be disabled thus ensuring no DRS affinity rules are populated into vCenter server. Suppressing DRS affinity rules will allow VMware DRS or allow you to directly distribute VMs across the cluster as desired to ensure all VMs are adequately resourced in terms of CPU and memory. The ‘Data Access Not Optimized’ alarm can be suppressed within vCenter server.
More information:
Configure ControlUp for VMware Horizon Instant Clone VDI monitoring
In this guide, we will analyze how to configure ControlUP COP (ControlUP on-Premise) to monitor a VMware Horizon 2309 infrastructure with Instant Clone Desktop Pools (we will not cover the installation part of the product)
The following steps are required:
- Control UP COP Server Component Installation (Optionally use an external SQL instance or SQL EXPRESS present in the Server component installation)
- Installing the Control UP Console (Can also be installed on the same server)
- Installing Agent Control Up on the GoldImage
- Horizon Infrastructure Inventory
- VirtualMachine Inventory (For this step we can also implement an automatism)
Requirements for the server part:
COP Server |
COP Server | Console Machine |
Machine | Windows Server | Windows Server orWindows |
Operating System | Windows Server supported versions:2022,2019,2016 | Windows Server supported versions:2022,2019,2016 OR Windows 11, 10 |
CPU* | 2 CPUs | 2 CPUs |
Memory* | 8 GB RAM | 8 GB RAM |
Disk Space* | 10 GB | 10 GB |
Required Software & Permissions |
|
.NET Framework 4.5 or later |
Requirements for Part DB:
MSSQL Versions (Standard, Enterprise, or Express) | Maximum Database Size | Collation |
2022,2019,2017,2016,2014 | 10 GB | SQL_Latin1_General_CP1_CI_AS |
Requirements for the VDI part:
ControlUp Agent |
ControlUp Agent |
Machine | No server installation necessary. Deployed onto Windows machines that are monitored by ControlUp(Linux monitored via API). |
Operating system | Windows Server supported versions: 202220192016 (Core or Full)ORWindows 11, 10 |
Required installed software | .NET 4.5 or later |
TCP PORT | 40705 |
A Service Account to access the Horizon infrastructure:
The Read-Only role is sufficient for all monitoring purposes. If you want to perform built-in Horizon actions, then the service account needs the following permissions:
- Enable Farm and Desktop Pools
- Manage Machine
- Manage Sessions
- Manage Global Sessions (Cloud Pod architecture only)
So what is needed is:
Download the version of ControlUP COP from the VMware site
Log in to the customer portal and in the product area under Desktop & End-User Computing
Log in to OEM Addons
Download the on-premise version
Perform the basic installation
Once the COP version is installed and the console is installed, log in to our ControlUP installation
How to install the agent on the GoldImage:
- The agent MSI file is on the downloaded file zip from VMware Portal
- Open the Real-Time Console and go to Agent Settings and copy your Agents Authentication Key. The key is used to connect the Agent to your ControlUp environment.
- Run the installation of the MSI package on the machine where you want to install the Agent.
- During the installation, paste the authentication key that you copied from the Real-Time Console.
- Complete the installation. The Agent is installed on the machine and the machine can be monitored from the Real-Time Console.
- Take the snapshot
- Deploy the new master image on Desktop Pool
Now from the ControlUp Management console, we are able to:
- Connect our Vmware Horizon infrastructure
- Connect the instant clone machine
Add Horizon infrastructure:
Add the infrastructure info
Click on OK
Add the pod to the console
Now on the left panel, we have our Horizon infrastructure added.
To monitor correctly our instant clone (after adding the agent) we need to discover the VM like a Machine
Search with the partial name of the VDI machines
Select cancel
We are VM on the left control panel in black status
After a few seconds the VDI VM Goes to Green
Auto connect state must be enabled (this function is important when the instant clone VDI is removed and recreated).
Now we can monitoring the Instant-Clone VDI
Check the VDI logon duration
Now we can manage and control the infrastructure, for example, to check the logon duration
What happens when VDI instant clones are regenerated?
If a user disconnects from his VDI of the instant clone type, it is destroyed and recreated, on the ControlUp side this is put in the Red -> Yellow state until it returns to Green
When recreating
After recess
Dynamic inventory
For a dynamic inventory of VDI, we can use Synchronization with Universal Sync Script (I’ll talk about this in a future post)
EUC Synchronization with Universal Sync Script (controlup.com)
After installation, we can schedule or start manually the script to sync my ControlUP with my EUC infrastructure.
References:
How to Deploy the Agent on Your Master Image for PVS/MCS/Linked/Instant Clones (controlup.com)
EUC Synchronization with Universal Sync Script (controlup.com)
vSphere Distributed Switch health check
For us VMware systems engineers who every day find ourselves “dialoguing” with those who manage the network ecosystem, we can only find the vSphere Distributed Switch health check function useful.
- What these checks allow us to highlight:
These are some of the common configuration errors that health check identifies:
- Mismatched VLAN trunks between a vSphere distributed switch and a physical switch.
- Mismatched MTU settings between physical network adapters, distributed switches, and physical switch ports.
- Mismatched virtual switch teaming policies for the physical switch port-channel settings.
The network health check in vSphere monitors the following three network parameters at regular intervals:
- VLAN: Checks whether vSphere distributed switch VLAN settings match trunk port configuration on the adjacent physical switch ports.
- MTU: Checks whether the physical access switch port MTU setting based on per VLAN matches the vSphere distributed switch MTU setting.
- Network adapter teaming: Checks whether the physical access switch ports EtherChannel setting matches the distributed switch distributed port group IP Hash teaming policy settings.
- How to activate:
Access the network section of our vCenter
Select the vDS on which we want to activate health checks
And enable the check that interests us:
- Where to check the outcome of the checks?
Wait a few minutes and already first feedback we can have it on ESXi hosts using the vDS in question, where if there are problems the classic red dot will be displayed
For more details, access the network section of our vCenter and select the vDS in question
And we can see that on the vmnic0 and vmnic3 of the first host, there are vLANs of which we have a Portgroup but which are not proposed correctly on all the ports of the switches to which we have attested our hosts. Then we have to have the configuration verified by our colleagues in the network.
- How to turn it off:
Repeat the enabling steps but this time select disable.
- Risks in activating it (we always consider activating it for a short time)
Depending on the options that you select, the vSphere Distributed Switch Health Check can generate a significant number of MAC addresses for testing teaming policy, MTU size, vLAN configuration, resulting in extra network traffic.
Ensure the number of MAC addresses to be generated by the health check will be less than the size of the physical switch(es) MAC table. Otherwise, there is a risk that the switches will run out of memory, with subsequent network connectivity failures. After you disable vSphere Distributed Switch Health Check, the generated MAC addresses age out of your physical network environment according to your network policy.
More info:
vDS Health Check reports unsupported VLANs for MTU and VLAN (2140503) (vmware.com)
Enabling vSphere Distributed Switch health check in the vSphere Web Client (2032878) (vmware.com)
Enable copy and paste between Guest Operating System and Remote Console
Copy and paste operations between the guest operating system and remote console are deactivated by default.
To enable it:
- Browse to the virtual machine in the vSphere Client inventory
- Right-click the virtual machine and click Edit Settings.
- Select Advanced Parameters.
- Add or edit the following parameters.
isolation.tools.copy.disable False
isolation.tools.paste.disable False
isolation.tools.setGUIOptions.enable True
These options override any settings made in the guest operating system’s VMware Tools control panel. - Click OK.
- (Optional) If you made changes to the configuration parameters, restart the virtual machine.
Remove an instant clone desktop pool in a deleting state
If we are removing a desktop pool from a Horizon infrastructure and we find ourselves in a situation that remains in a deleting state:
We can force the removal as follows:
- Remove any VDI VMs still in your vSphere infrastructure.
- Remove VM template, replication and parent.
In my example, we have the following situation
To remove them we use the tool iccleanup.cmd, we find te command on the connection servers by launching the following command to access:
iccleanup.cmd -vc <ome of vcenter> -uid < admin user of vcenter>
We enter the account password
Run with the list command the list of service VMs to be deleted
In my case, they are the VMs indicated with ID 2 and 3
We start from 2 and first launch the unprotect indicating with -I the number 2 (unprotect -I 2) and confirm by writing unprotect
Then we delete with the question delete -I 2 and confirm by writing delete
Let’s go back by writing Back
Relaunch the List command and verify that Index has taken the other chain of system VMs to be deleted
Ha was taken as index 2
We review the operations of unprotect and delete once again for index 2
At the end of the vCenter (they are service VM from other pools that should not be deleted)
Already in this case, we may have deleted the DesktopPool that was in a deleting state.
If the Pool in question is still present and in a deleting state, we proceed to access the ADSI Edit console and modify the ADAM DB by deleting the references left to the pool in deleting state (in my case ICTPM)
- Remove Desktop Pool from ADAM Database
To connect follow this KB:
Connecting to the Horizon View Local ADAM Database (vmware.com)
remove the pool from Adam as follows.
vSphere DRS functionality was impacted due to an unhealthy state vSphere Cluster Service
If you see such an error on the Cluster object of a vSAN (in my case it appeared on two vSAN clusters managed by the same vCenter)
vSphere DRS functionality was impacted due to an unhealthy state vSphere Cluster Service …….
an unhealthy state of the Service cluster
Errors such as the following in the EAM log. vCenter LOG
EAM.log:
2023-01-26T13:16:39.996Z | INFO | vim-monitor | VcListener.java | 131 | Retrying in 10 sec.
2023-01-26T13:16:41.432Z | ERROR | vlsi | DispatcherImpl.java | 468 | Internal server error during dispatch
com.vmware.vim.binding.eam.fault.EamServiceNotInitialized: EAM is still loading from database. Please try again later.
at com.vmware.eam.vmomi.EAMInitRequestFilter.handleBody(EAMInitRequestFilter.java:57) ~[eam-server.jar:?]
at com.vmware.vim.vmomi.server.impl.DispatcherImpl$SingleRequestDispatcher.handleBody(DispatcherImpl.java:373) [vlsi-server.jar:?]
at com.vmware.vim.vmomi.server.impl.DispatcherImpl$SingleRequestDispatcher.dispatch(DispatcherImpl.java:290) [vlsi-server.jar:?]
at com.vmware.vim.vmomi.server.impl.DispatcherImpl.dispatch(DispatcherImpl.java:246) [vlsi-server.jar:?]
at com.vmware.vim.vmomi.server.http.impl.CorrelationDispatcherTask.run(CorrelationDispatcherTask.java:58) [vlsi-server.jar:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_345]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_345]
at java.lang.Thread.run(Thread.java:750) [?:1.8.0_345]
2023-01-26T13:16:50.007Z | INFO | vim-monitor | ExtensionSessionRenewer.java | 190 | [Retry:Login:com.vmware.vim.eam:b55a7f93b59f0f7e] Re-login to vCenter because method: currentTime of managed object: null::ServiceInstance:ServiceInstance failed due to expired client session: null
2023-01-26T13:16:50.007Z | INFO | vim-monitor | OpId.java | 37 | [vim:loginExtensionByCertificate:913aec585658e328] created from [Retry:Login:com.vmware.vim.eam:b55a7f93b59f0f7e]
2023-01-26T13:16:51.440Z | ERROR | vlsi | DispatcherImpl.java | 468 | Internal server error during dispatch
com.vmware.vim.binding.eam.fault.EamServiceNotInitialized: EAM is still loading from database. Please try again later.
And you see the lack of vCLS VMs in the two vSANs
To resolve the anomaly you must proceed as follows:
- vCenter Snapshots and Backup
- Log in to the vCenter Server Appliance using SSH.
- Run this command to enable access the Bash shell:
shell.set --enabled true
- Type shell and press Enter.
- Run this command to retrieve the vpxd-extension solution user certificate and key:
mkdir /certificate
/usr/lib/vmware-vmafd/bin/vecs-cli entry getcert --store vpxd-extension --alias vpxd-extension --output /certificate/vpxd-extension.crt
/usr/lib/vmware-vmafd/bin/vecs-cli entry getkey --store vpxd-extension --alias vpxd-extension --output /certificate/vpxd-extension.key
- Run this command to update the extension’s certificate with vCenter Server.
python /usr/lib/vmware-vpx/scripts/updateExtensionCertInVC.py -e com.vmware.vim.eam -c /certificate/vpxd-extension.crt -k /certificate/vpxd-extension.key -s localhost -u "Administrator@domain.local"
Note: If this produces the error “Hostname mismatch, certificate is not valid for ‘localhost'”, change ‘localhost’ to the FQDN or IP of the vCenter. The process is checking this value against the SAN entries of the certificate.
Note: The default user and domain is Administrator@vsphere.local. If this was changed during configuration, change the domain to match your environment. When prompted, type in the Administrator@domain.local password.
- Restart EAM and start the rest of the services with these commands:
service-control --stop vmware-eam
service-control --start --all
This account is currently not available (UAG Login user root)
It often happens to forget the existence of UAG (Unified Access Gateway) in a VMware Horizon infrastructure and consequently also of root and admin passwords.
Let us remember that the UAG is the object of a Horizon infrastructure, exposed to the outside and therefore more subject to informed attacks. So, it is good and right to keep it constantly updated.
So if we forgot the root and admin passwords of our virtual appliance VMWare has the necessary documentation to reset these accounts, which you can find in these links:
Reset root user password set
Reset admin user password
Lately, it happened to me on a customer that even if the root user’s password had been reset, he still did not log in, the error was as follows:
The cause of the problem is the deactivation of the root user shell, evidence of this situation is in the /etc/passwd file of the virtual appliance which is thus configured for the root user
(The following commands can be executed by accessing the virtual appliance console in the manner indicated for changing the root user’s password and are available at this link)
cat /etc/passwd
To fix the situation, simply run the following command:
At this point, we restart with the command reboot -f and we will be enabled to access.