Como calcular cores para el licenciamiento de vSphere Foundation y VCF

 Con los nuevos modelos de paquetes y licenciamiento de VMware desde la entrada de Broadcom, así como el fin de las licencias perpetuas, moviéndonos al modelo de suscripción, nos encontramos con que tenemos que hacer bastantes cálculos de procesadores en el momento en el que nos salimos de un vSphere Essentials Plus. 

Para ello, VMware dispone del KB95927 donde se explica cómo debe realizarse este conteo de procesadores para el cálculo de licencias necesarias en nuestra infraestructura. En lineas generales, los requisitos son estos:

• Cada núcleo requiere una única licencia. Estas licencias no vienen en paquetes de 16.
• 16 núcleos en el requisito mínimo a adquirir por CPU/procesador físico.
• Cada TiB reclamado por vSAN requiere una única licencia.
• Estas licencias no vienen en paquetes, es decir, las licencias TiB no se venden en paquetes de 8, se venden como una licencia única y los clientes pueden agregar la cantidad deseada de TiB para cumplir con sus requisitos de capacidad de almacenamiento.
• 8 TiB es el requisito mínimo que se debe comprar por CPU/procesador físico para hosts en un clúster de vSAN.

En el KB anteriormente mencionado, se describe en detalle el cálculo a realizar, con ejemplos en tablas. Aun así, sigue siendo complicado realizar el cálculo, más cuanto mas grande sea la instalación. Por ese motivo, VMware ha desarrollado una herramienta PowerCLI que recopila y consolida información sobre la cantidad de licencias de núcleos (con un mínimo de 16 núcleos por CPU física) y licencias TiB (con un mínimo de 8 TiB por CPU física) requeridas para cada host conectado a un vCenter Server. Para ejecutarla seguimos los siguientes pasos:

• Necesitamos la herramienta de PowerCLI, v10 o superior. Si no la tenemos, desde un PowerShell, la descargamos con Install-Module VMware.PowerCLI -Scope CurrentUser
• Nos conectamos a un servidor vCenter con Connect-VIServer-Server vCenter_Server
• Según la documentacion del KB, importamos el módulo necesario con Import-Module .\FoundationCoreAndTiBUsage.psm1
• A mi, el comando anterior me falla. Si te sucede lo mismo, podemos descargarnos el modulo manualmente desde AQUI. Con $env:PSModulePath podemos ver los path de los módulos de PowerShell. Movemos el archivo descargado a una de estas rutas, y hacemos un "import-module rutacompletadelarchivo\FoundationCoreAndTiBUsage.psm1"
• Tras esto, ya podremos hacer un Get-FoundationCoreAndTiBUsage

Por defecto, el script pasa por todos los clusters de vSphere, y muestra los resultados:

Para sacar los resultados en un CSV, utilizamos el comando Get-FoundationCoreAndTiBUsage -Csv -Filename name.csv

Si te ha gustado el articulo, puedes invitarme a un café ;)

Como optimizar tus VMs con VMCO de Flings

Vamos con el primer post de este 2024, con una utilidad que quería comentar hace ya tiempo, Virtual Machine Computer Optimizer, o VMCO, de VMware Flings.

Lo primero...¿que es VMware Flings?

Flings son un conjunto de herramientas y utilidades creadas por la comunidad de VMware que, si bien no son oficiales, esto es, que no cuentan con soporte de VMware, y por tanto no se recomienda su uso en entornos de producción, sí que son alentadas por VMware, y soportadas en su web, en este ENLACE.

Hay algunas herramientas que ya no tienen sentido, como los drivers NVMe de la comunidad, ya que VMware ha adoptado esta tecnología en sus productos, u otras herramientas, como el Cross vCenter Workload Migration Uitlity, que han integrado directamente en algunas versiones de vCenter, según licencia.

Pero tienes otras soluciones plenamente vigentes, como el VMCO, que, aunque Aria Operations pueda facilitarte información sobre VMs sobredimensionadas o al contrario, escasas de recursos necesarios para su funcionamiento, puede ser que no tengas este producto, y para eso, VMCO va de maravilla.

Virtual Machine Computer Optimizer (VMCO) es un script y un módulo de Powershell que utiliza el módulo PowerCLI para capturar información sobre los hosts y las máquinas virtuales que se ejecutan en el entorno de vSphere, e informa sobre si las máquinas virtuales están configuradas de forma óptima en función de la CPU y la memoria del host. Marcará una máquina virtual como "TRUE" si está optimizada y "FALSE" si no lo está. En el caso de las máquinas virtuales no optimizadas, se realiza una recomendación que mantendrá el mismo número de vCPU configuradas actualmente, con el número óptimo de núcleos virtuales y sockets.

Es importante tener en cuenta que VMCO no analizará si las máquinas virtuales están configuradas con el número correcto de vCPU en función de la carga de trabajo de la máquina virtual. Una herramienta de análisis más detallada, como VMware Aria Operations Manager, puede determinar el tamaño adecuado en función de la carga de trabajo y el rendimiento real. Pero como herramienta de consulta para un primer paso a un correcto dimensionamiento, es perfecta.

Otro punto importante: VMCO no realiza ninguna modificación. Sólo consulta los objetos existentes para generar un informe, no reconfigura máquinas.

Puedes descargar VMCO desde AQUI.

La utilización de la herramienta es bastante simple, ejecutas el script de PowerShell, y éste instalará los complementos necesarios. Necesitarás también una cuenta de usuario de tu entorno del vCenter con permisos de lectura y la opción "propagate to children" habilitada, según la documentacion. Vaya, que estos permisos se encuentren sobre todos los elementos, para poder acceder a todos los objetos necesarios. 

Para su instalación, desde la ruta en la que tenemos el archivo PS1, ejecutamos".\Virtual_Machine_Compute_Optimizer_v3.0.0.ps1"

 A mi me ha dado guerra la instalación de los módulos directamente con el script. Si te pasa lo mismo, instala primero los modulos, y luego ejecutas el script. Para ello, ejecuta primero:

Install-Module -Name VMCO -Scope CurrentUser

Install-Module Vmware.VimAutomation.Core

Y después, ya ejecutas .\Virtual_Machine_Compute_Optimizer_v3.0.0.ps1

Este script generará un documento en formato CSV con distintos datos como el nombre del vCenter, detalles del cluster, detalles del host, detalles de las VMs... pero lo mas interesante, es este apartado:

En la columna de VMOptimized te indica si está optimizada o no, y en las siguientes columnas te indica las recomendaciones de cómo deberían configurarse las VMs para optimizar rendimiento.

Realmente la parte vital de esto es el modulo VMCO, de manera que si te las apañas con PowerShell, puedes realizar directamente consultas a este módulo, que lo que hace es habilitar la función Get-OptimalvCPU.

Aquí tienes varios ejemplos de lo que puedes obtener con dicho comando de PowerShell:

Obtiene todas las máquinas virtuales de vCenters conectadas actualmente
Get-OptimalvCPU

Exporta los resultados a csv

Get-OptimalvCPU | Export-CSV -path "c:\temp\vNUMA.csv" -NoTypeInformation

Abre los resultados en una ventana de cuadrícula - solo sistema operativo Windows
Get-OptimalvCPU | Out-GridView

#Gets resultados solo en la máquina virtual denominada
 "MyVmName"Get-OptimalvCPU -vmName "MyVmName"

#Gets resultados en cualquier máquina virtual con "NY-DC" en su nombre

get-optimalvCPU -vmName (get-vm -name "*NY-DC*")

#Returns toda la información de vCenter, clúster y VMHost
Get-OptimalvCPU -full

Genera informes basados en informes TDM de VMware TAM en formato JSON

Get-OptimalvCPU -tdmJsonFile <FilePath> | Export-CSV -Ruta "c:\temp\VMCO_Report.csv" -

NoTypeInformation

Si te ha gustado el articulo, puedes invitarme a un café ;)

Preparar un disco de Citrix para Azure

Ahora que todas las empresas están moviendo elementos a la nube, evaluando costos y rendimiento, se dará el caso de querer mover VMs antiguas, instaladas, y en sistemas como Citrix, a entornos como Azure.

Tenemos la ventaja que el formato de discos de los XenCenter será un .vhd, igual que el que maneja Azure. Pero aun así si intentamos la subida, obtendremos un error:

The upload size in bytes 17989773824 - 512 bytes for the VHD footer (17989773312 in this case) must be a multiple of MiB.". Esto es debido a que debemos adaptar el tamaño de los bloques de disco a 1 MiB. Para ello, debemos lanzar una serie de comandos de powershell para verificar el tamaño del bloque. Estos comandos son los siguientes:

$vhd = Get-VHD -Path C:\test\MyNewVM.vhd

$vhd.Size % 1MB

Aquí normalmente dará un valor de "0"

$vhd.FileSize - $vhd.Size

Normalmente da un valo entre 512 y algo como 82720062976

También en el caso de que el disco sea un .vhdx, y para arreglarlo, utilizamos el siguiente comando:

Convert-VHD -Path C:\test\MyVM.vhdx -DestinationPath C:\test\MyNewVM.vhd -VHDType Fixed

Tambien puedes utilizarlo siendo un vhd, para pasarlo a vhd, con el sufijo "fixed"

Pero para realizar todo esto, tenemos un problema adicional: no se encontrarán los comandos necesarios en PowerShell:

Para solventarlo, debemos instalar el servicio de Hyper-V en el equipo que lanzará el comando. Vale con los servicios indicados en la captura:

No sirve instalar solamente el modulo de PowerShell, deben instalarse los componentes de Hyper-V indicados, prácticamente todos, menos el hypervisor, que no es necesario. Una vez esté instalado, podremos ejecutar los comandos descritos anteriormente, que ahora si, funcionarán correctamente:

Tras esto, solo queda subir el disco a Azure de la manera que cada uno decida. Tenemos la subida desde consola de PowerShell, la subida desde el navegador, y el uso de Azure Storage Explorer. Pero eso ya es historia para otro post.

Antes de subir el disco, hay que tener en cuenta que debe prepararse también el sistema operativo de forma adecuada, no solo el formato del disco, como hemos visto aquí. Es decir, asegurarse de eliminar las Citrix Tools, deshabilitar firewall, habilitar RDP, eliminar tarjetas de red, hacer un sysprep, etc...

IMPORTANTE: aunque el formato de salida de Citrix es vhd, igual que el que puede utilizar Hyper-V, los discos pueden no funcionar, en base a la BIOS elegida. De manera que aunque el proceso es correcto en base a la documentación y consultas a Microsoft, y el disco sube a Azure, la VM creada con este disco y en base a la eleccion de BIOS, puede no funcionar. 

Para que el proceso funcione, hay que tener en cuenta si en Citrix la VM funciona con BIOS o UEFI. En Caso de ser BIOS, a la hora de montar la VM en azure, deberemos seleccionar una nueva VM Gen1. En cambio, si fuese UEFI, debemos seleccionar Gen2. Adicionalmente y antes de subirla, se puede probar a ejecutar el vhd en Hyper-V, que ya que tenemos instalado el servicio...Si funciona, lo hará igualmente en Azure.

Si te ha gustado el articulo, puedes invitarme a un café ;)

Reiniciar el periodo de gracia de 120 dias de RDS

 Supongamos que montamos una infraestructura con servidor de licencias RDS. Por defecto, el servicio de licencias RDS nos da 120 días de periodo de gracia de acceso ilimitado de conexiones, sin necesidad de instalar licencias. Terminado este periodo, deben comprarse CALs (Client Access License).  Pero a veces, no da tiempo a montar la infraestructura que queremos, o lo que tenemos es una laboratorio de pruebas, y necesitamos un poquito mas de tiempo para trastear.

Bueno, podemos resetear este contador para seguir con nuestras pruebas. Es muy fácil. Sólo debemos ir a HKLM\SYSTEM\CurrentControlSet\Control\TerminalServer\RCM\GracePeriod.  Podemos ver un registro llamado TimeBomb que no podremos eliminar, por falta de permisos. De manera que sobre GracePeriod pulsamos botón derecho y vamos a permisos

Aquí tendremos que tomar propiedad de la carpeta con, por ejemplo, la cuenta de administrador local de la maquina, y posteriormente, asignarnos permisos de full control en la carpeta.

Tras estos permisos, podremos eliminar el registro L$RTMTIMEBOMB.

Reinicia el servidor, y veras que el mensaje sigue saliendo, pero con 120 días de periodo de gracia.

Tambien puedes ver en cualquier momentos los dias que quedan de periodo de gracia con el siguiente comando:

wmic /namespace:\\root\CIMV2\TerminalServices PATH Win32_TerminalServiceSetting WHERE (__CLASS !="")

La segunda manera de realizar esto es prepararte el siguiente código en un archivo .ps1 y lanzarlo con un .\Reset-TSGracePeriod.ps1 -force

# This Script is intended to be used for Querying remaining time and resetting Terminal Server (RDS) Grace Licensing Period to Default 120 Days.

## Developed by Prakash Kumar (prakash82x@gmail.com) May 28th 2016

## www.adminthing.blogspot.com

## Disclaimer: Please test this script in your test environment before executing on any production server.

## Author will not be responsible for any misuse/damage caused by using it.

Param(

        [Parameter(Mandatory=$false)] [Switch]$Force

     )

 

Clear-Host

$ErrorActionPreference = "SilentlyContinue"

 

## Check if PowerShell Console has been launched As Administrator

if (([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)) {

 

## Display current Status of remaining days from Grace period.

$GracePeriod = (Invoke-CimMethod -InputObject (Get-CimInstance -Namespace root/CIMV2/TerminalServices -ClassName Win32_TerminalServiceSetting) -MethodName GetGracePeriodDays).DaysLeft

Write-Host -fore Green ======================================================

Write-Host -fore Green 'Terminal Server (RDS) grace period Days remaining are' : $GracePeriod

Write-Host -fore Green ====================================================== 

Write-Host

 

## Check if -Force Parameter has been used, If so, It will not prompt for Y/N while executing the script and will simply reset the Grace Period.

If (-not $Force)

{

$Response = Read-Host "Do you want to reset Terminal Server (RDS) Grace period to Default 120 Days ? (Y/N)"

}

 

if ($Response -eq "Y" -or $Force) {

## Reset Terminal Services Grace period to 120 Days

 

$definition = @"

using System;

using System.Runtime.InteropServices;

namespace Win32Api

{

       public class NtDll

       {

             [DllImport("ntdll.dll", EntryPoint="RtlAdjustPrivilege")]

             public static extern int RtlAdjustPrivilege(ulong Privilege, bool Enable, bool CurrentThread, ref bool Enabled);

       }

}

"@

 

Add-Type -TypeDefinition $definition -PassThru

 

$bEnabled = $false

 

## Enable SeTakeOwnershipPrivilege

$res = [Win32Api.NtDll]::RtlAdjustPrivilege(9, $true, $false, [ref]$bEnabled)

 

## Take Ownership on the Key

$key = [Microsoft.Win32.Registry]::LocalMachine.OpenSubKey("SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\GracePeriod", [Microsoft.Win32.RegistryKeyPermissionCheck]::ReadWriteSubTree,[System.Security.AccessControl.RegistryRights]::takeownership)

$acl = $key.GetAccessControl()

$acl.SetOwner([System.Security.Principal.NTAccount]"Administrators")

$key.SetAccessControl($acl)

 

## Assign Full Controll permissions to Administrators on the key.

$rule = New-Object System.Security.AccessControl.RegistryAccessRule ("Administrators","FullControl","Allow")

$acl.SetAccessRule($rule)

$key.SetAccessControl($acl)

 

## Finally Delete the key which resets the Grace Period counter to 120 Days.

Remove-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\GracePeriod'

 

write-host

Write-host -ForegroundColor Red 'Resetting, Please Wait....'

Start-Sleep -Seconds 10

 

}

 

Else

    {

Write-Host

Write-Host -ForegroundColor Yellow '**You Chose not to reset Grace period of Terminal Server (RDS) Licensing'

  }

 

## Display Remaining Days again as final status

tlsbln.exe

$GracePost = (Invoke-CimMethod -InputObject (Get-CimInstance -Namespace root/CIMV2/TerminalServices -ClassName Win32_TerminalServiceSetting) -MethodName GetGracePeriodDays).DaysLeft

Write-Host

Write-Host -fore Yellow =====================================================

Write-Host -fore Yellow 'Terminal Server (RDS) grace period Days remaining are' : $GracePost

Write-Host -fore Yellow =====================================================

 

if ($Response -eq "Y" -or $Force)

        {

            Write-Host -Fore Cyan `n"IMPORTANT: Please make sure you restart following services manually to bring this reset in effect:`n`n* Remote Desktop Configuration Properties `n* Remote Desktop Services"

        }

}

Else

{

    Write-Host -fore RED =====================================================

    Write-host -ForegroundColor RED *`0`0`0`0 Please Launch PowerShell as Administrator `0`0`0`0*

    Write-Host -fore RED =====================================================

}

## Cleanup of Variables

Remove-Variable * -ErrorAction SilentlyContinue