vSAN 8: Diferencias OSA – ESA

VMware vSAN 8 nos acerca una nueva y revolucionaria arquitectura denominada Express Storage Architecture (ESA). Se presenta como una opción revolucionaria y alternativa a la, hasta ahora, arquitectura existente, que pasa a denominarse Old Storage Architecture (OSA). Por supuesto, ambas son totalmente válidas y soportadas en vSAN 8. 

ESA viene condicionado a aquellos vSAN ReadyNodes con ciertos y selectos requisitos de hardware, capaces de ofrecer un altísimorendimiento sin parangón, además de una mayor resiliencia y escalabilidad. Para que lo tengamos claro, vSAN 8 va a ser capaz de sacar partido a todo el potencial que la tecnología actual está ofreciendo. Empezamos con detalles jugosos:

¿Pero bueno, de qué estamos hablando?

Desde un prisma de diseño, aquí ahora se utiliza una estructura nueva para su sistema de ficheros denominada vSAN Log File System (vSAN LFS). Desde una perspectiva administrativa, el cambio principal – más allá del rendimiento y simplicidad, que es su efecto inmediato – es pasar de un modelo Dual Tier a Single Tier. ¿Qué significan estos palabros para nosotros? pues básicamente desaparece la dualidad Disco Caché / Disco Capacitad, los discos en el modelo ESA se agrupan en un Storage Pool, todos los discos son independientes y todos están dedicados para almacenamiento, por ello todo resultará mucho más sencillo y transparente. Además, no estaremos sujetos a una calculadora para determinar cuantos discos necesitamos y de qué tipo, aquí el número máximo de discos lo limitará la cantidad de slots disponibles en nuestro nodo. No obstante el mínimo necesario serán 4 discos.

Y como consigue esto?. Pues obviamente dejarán de existir configuraciones Híbridas, todo será All-flash, concreta y exclusivamente NVMe basado en dispositivos TLC Flash y se requerirá un mínimo de 25 Gbps en nuestra red de vSAN. Seguidamente dejo una tabla con las principales diferencias entre ambas arquitecturas.

Más detalles sobre Rendimiento, Capacidad y Seguridad

Anteriormente, con vSAN OSA se realizaba un cuidadoso plan para decidir que tipo de política se iban a utilizar en función del rendimiento y uso del almacenamiento. vSAN ESA permite disponer de las ventajas de uso de disco que tiene un RAID-6 con el rendimiento de RAID-1, algo impensable hasta ahora. Adicionalmente el mecanismo de compresión se realiza antes de llegar a la red evitando overhead en la red. También existe nuevo método de generación de Snapshots más eficiente.

Este cambio también repercute en la capacidad y es que vSAN OSA nos ha dado un poco la vuelta a lo que teníamos interiorizado hasta ahora en lo que respecta a las políticas de almacenamiento. Por si eso fuera poco interesante usar RAID-6 con el performance de RAID-1, ahora RAID 5 también puede operar en una configuración 2+1 o 4+1, algo que nos va a permitir poder disponer de todo un cluster de tan solo 3 nodos, con almacenamiento en RAID 5, beneficiándonos de una mayor eficiencia en términos de espacio.

vSAN ESA usa una nueva estructura en su sistema de ficheros mucho más eficiente, esto es necesario para poder acometer la gestión de almacenamiento tratando los discos de forma independiente y sin contar con el Tier de Caché.Que no solo elimina un punto de fallo que teníamos a nivel de Disk Group sino que ahora todos los discos son usados para capacidad. Otro beneficio de esta estructura es que la compresion ahora puede alcanzar un ratio 4 veces superior a la arquitectura OSA, es decir, hasta un 8:1 para bloques de 4 KB. Además, la compresión se aplica a nivel de objeto, no a nivel de Disk Group. Importante mencionar que la opción “Compression Only” viene activada por defecto, aunque posteriormente podemos usar políticas para que no se usen en nuestras VMs.

En lo que respecta a seguridad también hay una diferencia importante, y es que vSAN Express Storage Architecture aplica la encriptación a nivel del host en dónde se ejecuta la máquina virtual. Los datos solo deben cifrarse una vez que están almacenados, ya no es necesario descifrarlos y volverlos a cifrar al pasar de la memoria caché a los dispositivos de capacidad. Por decirlo de otro modo, la encriptacion que antes se realizaba a nivel de clúster, ahora se realiza a nivel de objeto. Este cambio minimiza la penalizacion uso de CPU y el IO Amplification. A tener en cuenta algo que difiere también con el modelo anterior, ESA Encryption solo podrá activarse durante la creación del clúster, posteriormente no puede activarse.Un bonito warning nos lo recordará:

Por último quisiera mencionar una mejora con respecto a los Snapshots. Básicamente, desde vSAN 6.0 se usaba un método llamado vsanSparse basado en los redo logs – basicamente poner el vmdk en read-only y crear un nuevo disco hijo donde escribir los cambios. En OSA se usa una nueva estructura denominada el B+tree logical map que, sin detalles técnicos, cuando creamos un Snapshot, éste apunta a distintos bloques de datos distribuidos en nuestro vSAN Dastastore. En resumen, mejora el tiempo de consolidación, cosa que beneficia a todas las herramientas de Backup que usen la API para crear copias de seguridad. Apuntar que la degradación por uso de snapshots sigue ahí, no abuséis de ellos y eliminadlos una vez cumplido su propósito.

No me digáis que no pinta mejor ESA que OSA, OSEA, sabes ? (“Esa” ha sido buena 😉 ) Bien, ésto es todo por ahora. Próximamente buscaré hueco para ver en profundidad como son las Storage Policies en vSAN 8 ESA.

HCX Transport Analytics: Nice to meet you

Welcome again to another #HCX personal quick note. This time I’d like to make a quick overview about one useful feature we normally miss during the Service Mesh creation. Personally, I have to confess creating a SM is the most tricky and exciting moment on a Workload Migration project. It’s the right time you wait for the tunnels to be up and green, but you are also expecting the worst :-).

But let’s be optimistic for a while and picture a brilliant Service Mesh with a whole new green tunnel between your Interconnect and Network Extension appliances at both sides of your regions. We are ready to test a migration task but moreover, we’d like to know how fast we can drive. Before version 4.4 we used to ssh our HCX Manager and run perftest tool to get some figures about the tunnel throughput and bandwidth. Well, my friend, this is so much cooler now.

Now we have a new option called Transport Analytics which basically does it for you internally and shows a fancy dashboard with the results. In fact, it can show a good estimation about the total amount of possible migrations based on the figures and limits measured. The Transport Analytics page lists all Service Mesh configurations for a site pair with a separate card for each Service Mesh.

Just go to your HCX Manager GUI and click on Infrastructure > Transport Analytics

According to the internal checks, you can have an estimation of 15 parallel Bulk migrations.- This image is from the HCX Documentation.

But there’s more under the next sections for each of the SM Services enabled. If we expand each service, we’ll have the required information to assure a good network performance and also the minimum requirements for each of type of migration.

This image comes from my lab.

We haven’t finished here because last section under this Transport Analytics dashboard is the one referred to the UPLINK itself. And there, we have the available bandwidth for both upload and download and detected latency. All in a more visual and clean mode.

And if you think we have finished, you are absolutely … wrong. Because VMware rocks and still you could click on Transport Monitor and discover the real time metrics that are being collected at that moment, well, at least the last hour, or last day or even last week or custom interval. There is no doubt this is a very nice surprise for all of those who demand a closer HCX monitoring and are not using vROoops …. I mean, Aria Operations yet. 😉

That’s all for now, hope you’d enjoyed this post. Ciao..!

vSphere 8: Novedades, novedosas.

VMware vSphere 8 ya está entre nosotros desde hace unos meses y, poco a poco, vamos descubriendo novedades novedosas conforme esta versión va tomando más y más protagonismo. Son muchas las novedades, desde mi punto de vista, estas serían algunas de ellas en lo que respecta a la administración y operación de vSphere:

vNUMA Configuration and Visualization

Interesante golosina la que tenemos aquí. Pocas veces se cae en la cuenta, a la hora de crear una VM, en los NUMA Nodes existentes y su perfecto alineamiento con los vCPU de nuestra Máquina Virtual. Solo cuando realizamos un Healthcheck del entorno o un estudio de rendimiento nos acordamos este concepto, que existe de vSphere 5.0 nada menos. En vSphere 8 y bajo el Virtual Hardware 20 es posible configurar la topología NUMA desde el vSphere Client, gracias a una nueva pestaña en Summary, llamada CPU Topology.

Staging Cluster Images

Como hacíamos con las Baselines del Update Manager, ahora es posible realizar el Staging de las Imágenes de los ESXi de un cluster para su posterior Remediation. Podemos hacerlo para todos los hosts de un cluster, con solo un click. Más aún, ya no es necesario que estén en Modo Mantenimiento para realizar esta tarea.

Parallel Remediation

¿Por qué actualizar un solo host pudiendo hacer varios a la vez?. En vSphere 8 podemos realizar el Remediate de los ESXi en paralelo. Nosotros decidimos que hosts poner en MM y Lifcecycle Manager se encargará del proceso aplicando el Remediation en esos hosts, hasta un total de 10. Ahí es ná.

Enhanced Recovery of vCenter

Otra golosina rica. Recordáis el castigo divino de restaurar un vCenter del Backup. Bueno antes que nada. ¿Hacéis Backup de vuestro vCSA ?. Si la respuesta es “No” ya puedes conectarte a la VAMI y realizar una copia de seguridad a tu SFTP favorito. Como decía un sabio “No hay restore, si no hay Backup y es el Restore el que tiene que funcionar siempre.”. Bueno, eso no lo dijo un sabio sino un sordo, es decir, yo mismo.

Como comentaba, si han existido cambios en nuestros clusters desde que se realizó el backup, durante el proceso de restauración podrán producirse inconsistencias pero en vSphere 8 nuestro vCenter recién restaurado es capaz de identificar qué es lo que falta en su inventario y actualizarse con los datos en tiempo real. Ésto lo consigue distribuyendo entre los ESX porciones de información que se denominan DKVS o Distributed Key-Value Store

DRS and Persistent Memory

En vSphere 8, DRS hace un análisis del uso de memoria por las diversas cargas de trabajo mediante PMEM (Persistent Memory). Como resultado, la migración de este modo no afecta al rendimiento.

vSphere Configuration Profiles

De igual manera que usábamos los Host Profiles para poder configurar de forma rápida nuevos Hypervisores, vSphere 8 presenta vSphere Configuration Profiles. Esta vez para poder definir elementos de configuracion de los objetos de un cluster. Muy similar a como trabajan los ya mencionados anteriormente Cluster Images del LCM. Mucho que probar aquí si realmente podemos usar esos objetos de configuración para poder aplicarlos posteriormente a otro cluster.

Bueno hasta aquí por hoy. Pero hay más cositas, entre ellas el próximo día comentaré novedades relacionadas con vSAN 8.

Reporting vSAN Component details for each Virtual Machine’s Disk (PowerCLI)

Recently I had to check what the SBPM a vSAN Cluster was using on a VCF environment. Quite a delightful surprise for me knowing this time the scope was different and we had to know the Current Storage Policy each Virtual Machine was using on a vmdk-basis. Didn’t need to identify the Cluster’s vSAN Default Storage Policy, what we really want is the Policy for every vmdk.

So, hey, I’m not a nice programmer, totally admit that, but still treasure some personal resources from those years studying ICT Systems Engineering and I was younger 🙂 … and guess what?, it works for me, and now I hope it will work for you too. So, here’s the piece of code:

#########################################################
# 							
# Script to List the vSAN Components and SBPM
# applied on every Virtual Machine disk
#							
#							
# Alberto Ruiz - 2022					
#########################################################

# Parameters Definition
param(
[parameter(Mandatory = $true)]$Username,
[parameter(Mandatory = $true)]$Password,
[parameter(Mandatory = $true)]$vCenter
)


# Global Definition
$StartDate = Get-Date
$DateStamp= Get-Date -Format "ddMMyy-hhmmss"
$ReportFilePathHTML ="Output_vSAN_Report" + "_" + $DateStamp + $vCenter + ".html"
$ReportFilePathCSV ="Output_vSAN_Report" + "_" + $DateStamp + $vCenter+ ".csv"


Write-Host -ForeGround Gray "Conecting to [$vCenter] ..." -NoNewLine
Connect-ViServer $vCenter -User $Username -Password $Password -WarningAction 0 | Out-Null
Write-Host -ForeGround Green "Done."

# vSAN Checks

$OutInfo=@()

Write-Host -ForeGround Gray "Reading VMs from inventory ..." -NoNewLine

$VMList = Get-VM

Write-Host -ForeGround Green "Done."
Write-Host -ForeGround Gray "Collecting vSAN Components ..." -NoNewLine

	foreach( $VM in $VMList) 
	{
		$vSObject= Get-vSANObject -VM $VM.name
		
		foreach ($Obj in $vsObject)
		
		{	$vSComponent = Get-vSANComponent -vSanObject $Obj
		
		        foreach($Component in $vSComponent)
		        
		        {
		        	$vSANInfo=[pscustomobject] @{
		        
		        	VM=	$Obj.VM
		        	Health=$Obj.vSanHealth
		        	Compliance=$Obj.ComplianceStatus
		        	StoragePolicy=$Obj.StoragePolicy.name
		        	vSANDisk=$Component.vsanDisk
		        	Status=$Component.Status
		        	Type = $Component.Type
					Host = $Component.VsanDisk.VsanDiskGroup.VMHost.name
					Cluster = $Component.Cluster.Name
		        	}
		        
		        	$OutInfo+=$vSANInfo
		        }
		}
	}
	
	$OutInfo | ConvertTo-HTML | Out-File $ReportFilePathHTML
	$OutInfo | ConvertTo-CSV | Out-File $ReportFilePathCSV
	
	$EndDate=Get-Date
	$ExecutionTime=New-Timespan -Start $StartDate -End $EndDate
	

Write-Host -ForeGround Green "Done after: " + $ExecutionTime.TotalMinutes + " minutes"
  
Disconnect-viserver * -Confirm:$False -Force	

The script basically prompts you to enter the vCenter name and credentials, once it establishes a valid connection, for each virtual machine it reads the vSAN disk object and the information related to its components according to the applied policy. It collects the VM Name, Health Status of the component, if the object is compliance, the host where the component resides and the type (Witness, Component, etc..)

When finished, it shows the execution time – which you can basically ignore it – it was just for fun.

Inside the same folder you’ll find two files (.csv and .html) with the information collected.

And here’s a screenshot to see how the report looks like in html:

And here’s after being imported to Excel:

Code should be optimized since the more VM’s you have in the inventory the longer it takes to finish the execution. In my case this is not going to be a daily task, so it really meets the expectations after all.

VMware HCX 4.5

Hace apenas unos días, se ha liberado la version 4.5 de HCX. Aparentemente una más de lo que VMware denomina Maintenance Releases. Pero es mucho más que eso, desde mi perspectiva personal, considero esta version (a falta de probarla aún) muy, muy prometedora.

Antes de abordarla, aviso para navegantes: Un aviso, a modo de Warning color púrpura, menciona un cuidado especial para aquellos que tienen en marcha migraciones OSAM: .

Esta advertencia, básicamente sugiere que tengamos que hacer algo antes de actualizar: Buscar una ventana donde no haya migraciones OSAM en marcha. De lo contrario, corremos el riesgo de que esas tareas no terminen nunca y se queden en perdidas en el tiempo y el espacio para siempre. Esto supone un nuevo aspecto a considerar hasta ahora, y es que siempre hemos realizado los upgrades independientemente de si teníamos o no migraciones en vuelo. A fin de cuentas, los afectados de primera línea eran nuestros HCX Managers, posteriormente ya buscábamos ventana para poder actualizar los Appliances una vez terminaba de migrarse la ultima máquina. De modo que, mucha atención a este aviso.

Dicho esto, mención importante sobre aspectos de ésta release, lo primero, tiene una gran cantidad de fixes. Muchos, y además, algunos muy conocidos que harán que varios de nuestros clientes esbozen una sonrisa ;-).

También trae consigo la integración con vSphere 8, que prácticamente acaba de liberarse esta semana, pero una de las cosas más sorprendentes ahora mismo es usar HCX en un único vCenter; solamente para realizar Bulk migrations entre clusters, (Si, has oído bien, desplegar HCX solo en un vCenter). Inicialmente puede traer muchas ventajas para todas aquellas infraestructuras que necesiten unq gran migración de cargas dentro del mismo DC, el tiempo dirá si ha sido un acierto.

También nos encontramos con la opción de Seeding para RAV, que antes solamente era posible con Bulk. Y como no, OSAM ahora soporta RHEL 8.5 / 8.6. Como grata sorpresa, se soluciona algo que he sufrido personalmente en algun que otro cliente, se ha implementado una caché, para cargar el invantario de las redes de destino más rápidamene durante la creación de tareas de migration. También se actualiza MON, ahora admite Virtual Machines con Multiple IP Addresses.

Pero, por encima de esto, mención especial tiene lo que viene a denominarse Workload Migration for NSX V2T with Migration Coordinator. Algo que espero poder compartir aquí con más detalle próximamente. Nos leemos….

HCX OSAM Scale-Out

Buenos días por la mañana. Algunos proyectos de Migración suelen topar con aquellas máquinas virtuales que no están usando Hypervisores de VMware. HCX salió al rescate de este escenario y soporta migraciones de cargas de trabajo en KVM e Hyper-V.

Uno de los mayores desconocidos en HCX es OSAM (OS Assisted Migration) no solo porque el escenario es poco frecuente, sino porque es muy peculiar en cuanto a requerimientos y no es una migración sencilla, dado que lleva implícito una reconversión de la máquina virtual durante la fase de migración. Es más compleja, tarda más y tiene bastantes restricciones y limitaciones. Una de las más importantes, en términos de rendimiento, es que no permite replicar más de 50 vmdk de forma simultánea.

No voy a escribir acerca de OSAM, sino más bien de qué forma hacer el famoso Scale-Out para poder superar esa barrera de los 50 discos. Recordemos que ese límite lo sufre directamente el Sentinel Data Receiver (SDR) en destino, y no es otra cosa que la propia limitación del número máximo de discos que puede configurarse en una Máquina Virtual.

Dado que un Service Mesh solo puede tener un único SDR, la solución es tener varios Service Meshes. De éste modo, HCX nos permite – de manera totalmente soportada – tener hasta 4 Service Meshes con 1 SDR Cada uno. Esto se traduce en un nuevo tope de discos a replicar de forma simultánea, haciendo las mates, nos da un total de 200 VMDK por HCX Manager.

Inicialmente nos da muchas alas, pero hay que tener en cuenta otros factores para poder sacarle partido. Lo primero es pensar que vamos a necesitar ampliar nuestro Pool de IP’s para actualizar los Network Profiles, tanto en origen como en destino, así que hay que incorporar al equipo de networking. Además, recordemos que un Service Mesh, no es tal cosa sin su Interconnect. Eso implica que por tendremos 1 HCX-IX y 1 SGW en origen y 1 HCX-IX y 1 SDR en destino. De modo que vamos a usar más recursos tanto en origen como en destino. Concrétamente vamos a desplegar (3 SM x 2 Appliances x 2 Sites) = 12 nuevas Appliances.

OSAM Scale-Out

Además, no debemos olvidar que no va a existir una inteligencia que gestione los flujos de migracion de cada uno de los SM de forma equilibrada y balanceada. No. Seremos nosotros quienes lo tendremos que hacer dado que vamos a tener que trabajar con 4 agentes distintos, cada uno de ellos vinculado con su propio y exclusivo SGW.

Tampoco nos vale ir instalando Agentes como si no hubiera un mañana, el Sentinel Management de nuesto HCX Connector Manager tan solo permitirá tener instalados y conectados no más de 20 agentes activos. Conforme finalicen las migraciónes, podremos ir añadiendo más. Pero no es recomendable superar ese número.

Tipos de Despliegue con HCX – 1:N

Buenas tardes de nuevo. Voy a continuar el segundo post acerca de los esquemas de despliegue para HCX. :

Multi Target Deployment

Esta situación, también más compleja que la primera, es muy similar al modelo Multi Origen. Se produce cuando un cliente quiere migrar sus cargas de trabajo, y éstas residen en dos o más entornos dentro de un mismo vCenter. El destino de la migración, por tanto, serán dos vCenter o Workload Domain si tenemos un VCF.

Un ejemplo práctico: Nuestro cliente quiere migrar cargas de trabajo de un único vCenter, donde tiene separados los entornos de Producción y de Desarrollo. Ésto puede darse mediante el uso clusters de PRO y DES dentro de un mismo DC. En Destino, tenemos nuestro propio vCenter de PRO y nuestro propio vCenter de DES, con lo que tendremos dos HCX Cloud a los que repartir las migraciones.

Características:

En este escenario, cada nuestro HCX Connector tiene su propio Site Pairing con cada uno de los HCX Cloud. Además, cada uno de nuestros HCX Connector tendrá su propio Service Mesh con sus respectivos Perfiles de Red y de Cómputo. Lo mismo sucede con cada uno de nuestros HCX Cloud, que usan sus propios perfiles de Red y Cómputo para cada uno de los Service Mesh que se hayan creado, dado que, cada uno de los HCX Cloud está vinculado con un vCenter de un entorno en concreto.

En este esquema contamos con los servicios básicos de Interconnect para la generación del túnel, y los dos de migración para Bulk Migration y vMotion. Recordar que el máximo soportado de Site Pairing para modelo 1:N es N=10.

Tipos de Despliegue con HCX – N:1

Buenas tardes de nuevo. Voy a continuar el primer post acerca de los esquemas de despliegue para HCX. :

Multi Source Deployment

Esta es la situación más compleja. Se produce cuando un cliente quiere migrar sus cargas de trabajo, que residen en dos o más vCenter, a un cluster en destino, que reside en un único vCenter o Workload Domain si tenemos un VCF como destinto.

Un ejemplo sencillo: Nuestro cliente quiere migrar cargas de trabajo de un vCenter de Producción a otro vCenter de Producción. Pero dispone de varias oficinas remotas, dónde se ejecutan entornos productivos. Todas las máquinas virtuales que deseamos migrar, pertenecen al mismo entorno de Produccion, la diferencia es que están repartidas entre dos o más vCenter.

Características:

En este escenario, cada uno de los HCX Connector tiene su propio Site Pairing con nuestro único HCX Cloud. Además, cada uno de nuestros HCX Connector tendrá su propio Service Mesh con sus respectivos Perfiles de Red y de Cómputo. En cambio, nuestro HCX Cloud podrá utilizar los mismos perfiles de Red y Cómputo para cada uno de los Service Mesh que se hayan creado, dado que, con casi toda seguridad irán alguno de los Cluster de Producción definidos en el Perfil de Cómputo.

En este esquema contamos con los servicios básicos de Interconnect para la generación del túnel, y los dos de migración para Bulk Migration y vMotion.

Tipos de Despliegue con HCX – 1:1

Buenas tardes. Voy a compartir con vosotros algunos esquemas gráficos que ayuden a entender la forma de desplegar VMware HCX. En base a la infraestructura existente en origen, yo propongo tres posibilidades:

Single Deployment

Esta es la situación más sencilla, que se da, cuando un cliente quiere migrar sus cargas de trabajo, que residen en un único vCenter, a un cluster en destino, que reside en un único vCenter o Workload Domain si tenemos un VCF como destino.

Un ejemplo sencillo: Nuestro cliente quiere migrar cargas de trabajo de un vCenter de Producción a otro vCenter de Producción. Todas las máquinas virtuales que deseamos migrar, pertenecen al mismo entorno de Produccion y están en un único vCenter.

Características:

Se requiere un único Site Pairing entre ambos HCX y un único Service Mesh, dado que, inicialmente se mantiene el tipo de Entorno durante la migración. En este esquema contamos con los servicios básicos de Interconnect para la generación del túnel, y los dos de migración para Bulk Migration y vMotion.

VMware HCX 4.3.0 is out – Highlights

Updated. Check at the bottom of this post.

Just after a few days a security update came out with version 4.2.3 to mitigate the VMSA-2021-0028 vulnerability, a new update is available with a very significant fixes and improvements like Network Extension HA, database transition to PostgresSQL and RHEL 8 for OSAM.

Let’s summarize what we’ll find within HCX 4.3.0.

Network Extension High Availability (EA)

This is a feature we all have been waiting for since the very beginning. Yep, vSphere HA was always there for you but it never was a valid action to prevent downtime. Now, the number of NE appliances are duplicated, having 2 (Active-Passive) nodes at Source and another 2 (Active-Passive) at Target, forming an HA Group with heart beating control between them, obviously all served with the proper DRS Affinity Rules.

Transition to PostgresSQL

From now on, HCX moves to PostgresSQL, leaving behind MongoDB. New installations will deploy this database, but when upgrading, a conversion process takes place automatically. There’s also a KB to revert this conversion if needed. I really hope this could make the overall job management more efficient.

OS Assisted Migration Enhancements for Guest OS Support  

It’s here, and finally REHL / CentOS 8.x (x64) is now supported for both KVM and Hyper-V. Also Windows Server 2019 Guest OS in Hyper-V.

Interoperability and Enhancements

• HCX 4.3.0 is now supporting NSX-T 3.2.
• OSAM Migration is available for vSphere 7 U3 environments.
• No need to set the SDR Datastore in Compute Profiles for OSAM. HCX validates whether the selected Datastore for migrations is accessible by the SDR automatically.
• The Redeploy selection in the Service Mesh > View Appliances page now supports specific deployment options for each appliance
• The PowerCLI 12.4 release resolves issues with the Start-HCXReplication and GET-HCXMigration cmdlets

Resolved Migration Issues

• RAV migration of a VM having a disk of exactly 2 TB size fails with the error – “Operation timed out”.
• During Bulk migration switchover, Power OFF task failed as the virtual machine was already powered OFF due to delayed shutdown, resulting in migration failure.
• The Guest OS version for CentOS 6.x 32/64bit migrated virtual machines are incorrectly set to CentOS 4/5.

And that’s all, check the Release Notes for a more detailed information and let us know your thoughts.

Important UPDATE: Some issues are found when upgrading to 4.3.0. Besides migration history could be lost after the database transition (use PowerCLI to export the information after upgrading) . A most severe problem comes when filesystem is completely full for /common partition:

We strongly suggest waiting for new release in the following days to solve this issue. In the meantime, revert to the 4.2.4 which surely meets the security requirements.