jueves, 31 de diciembre de 2020

Ver los parches instalados en el host ESXi

 Una duda que me surgió a la hora de ver los parches instalados en los ESXi por motivos de seguridad, sobre todo. Porque la ver la versión del host o su actualización es simple, sobre todo con el vCenter. 

Para el host, en cambio, disponemos de un par de útiles comandos.

Por una parte tenemos # excli software vib list, que nos mostrará todos los paquetes de software (VIBs) instalados, y su versión.

Pero más útil que esto, disponemos el comando # excli software profile get que nos amplia la anterior información facilitándonos las fechas de instalación, con los que se nos muestra como un "histórico" de actualizaciones.


Si adicionalmente quieres ver la version del ESXi y su nivel de parche, aunque se ve cómodamente con vCenter, tambien puedes obtenerlo, ya metidos en comandos, con # excli system version get.

Espero que estos tres comandos os hayan sido de utilidad, y mucho cuidado con las vulnerabilidades, ¡chequead que tengáis todo correctamente actualizado!

lunes, 16 de noviembre de 2020

Windows Server 2016 y 10 no descargan actualizaciones

 Realizando una actualización de un servidor Windows Server 2016 directamente desde Windows Update en una red con proxy, me he encontrado con el caso que localiza las actualizaciones, pero no inicia la descarga.


Lo curioso es que el sistema detecta los parches disponibles.

Para Windows Server 2016 la configuración de proxy que se realiza a traves del panel de control de Internet Explorer no afecta al servicio de actualización, de manera que para ello debe forzarse la configuración del proxy para winhttp.

Hay dos formas de hacerlo. La primera consiste en importar la misma configuración de proxy que tienes en tu configuración de conexiones en Internet Explorer. La que tienes en Propiedades de Internet / pestaña conexiones / botón Configuración de LAN:

A continuación, desde una ventana de comando, escribes:

netsh winhttp import proxy source=ie

Después del cambio, debes reiniciar el servicio de Windows Update. Ya que estamos en la ventana de comando, podemos escribir Restart-service wuauserv

También podemos ver la configuración del proxy winhttp con el comando netsh winhttp show proxy

La segunda manera de cambiar la configuración es pasar la configuración del proxy winhttp directamente por linea de comando, sin importación. Así:

netsh winhttp set proxy proxy-server="192.168.1.1:8080" bypass-list="*.thinkinvirtual.com"

Básicamente le pasamos la dirección del servidor proxy con su puerto, y podemos agregar una lista de webs que no accedan por proxy con el comando "bypass-list". Para que funcione correctamente, deberiamos agregar tambien aquellas webs a las que necesitamos acceso anónimo a Microsoft Update Server desde el servidor proxy. Por ejemplo, agregamos *.microsoft.com, microsoft.com, *.windowsupdate.com, windowsupdate.com, *.trafficmanager.net y trafficmanager.net
 
Igualmente reiniciamos el servicio de Windows Update, y probamos.

miércoles, 7 de octubre de 2020

Aumentar el espacio de reglas en Exchange Online (o365)

 Cada vez recibimos más mails, y para poder lidiar con ellos, cada vez debemos crear más reglas organizativas. Pero si estás trabajando con o365, aun teniendo una licencia e3, te puedes encontrar con el caso de no poder aplicar más reglas, al llegar al límite de espacio aplicable para las mismas.

Si, resulta que O365 tiene un límite por defecto para las reglas ,de 32 kb. En el caso que me he encontrado, esto permite crear hasta unas 130 reglas de correo. Si aun así te quedas corto, es posible modificar dicho límite. 

Para ello, lo primero, conectamos a o365. Pongo aquí los comandos del tirón, aunque tengo otro artículo indicando el proceso. (todo sin comillas).

"connect-msolservice" y pasamos nuestras credenciales

"Set-ExecutionPolicy RemoteSigned

"$UserCredential = Get-Credential" y pasamos credenciales

"$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection" Esto es el comando de conexión.

"Import-PSSession $Session -DisableNameChecking"

Ahora sí entramos con los comandos para la modificación de las cuotas de espacio para las reglas:

Empezamos viendo el tamaño de cuota del que dispone con este comando:

Get-Mailbox -Identity "<MailboxIdentity>" | Format-List RulesQuota

Reemplazar <MailboxIdentity> por la cuenta del usuario, por ejemplo, 

Get-Mailbox -Identity "mimail@midominio.com" | Format-List RulesQuota

El valor que dará será normalmente de 32 KB, pero puedes modificarlo hasta los 256 KB. Vamos con el comando de modificación, una vez que hemos visto el valor disponible:

Set-Mailbox -Identity <MailboxIdentity> -RulesQuota "<32 KB to 256 KB>"

Esto seria ,de nuevo por ejemplo, algo así:

Set-Mailbox -Identity mimail@midominio.com -RulesQuota "256 KB"

Tienes más info en este LINK de Microsoft, donde describen cómo aplicar esta modificación a un listado de cuentas, por ejemplo, en vez de a usuarios individuales, pero he preferido no extenderme más, ya que no se da mucho el caso de usuarios que excedan el límite de reglas.

miércoles, 16 de septiembre de 2020

Ya está disponible VMWare Workstation 16 y Fusion 12

¡Hoy es día de estrenos! VMware ha lanzado las nuevas versiones de sus productos para escritorio, VMware Workstation Pro 16, Workstation Player 16, y Fusion 12 para los Mac. Estas son sus mejoras:


Soporte para Kubernetes y Containers: Se pueden utilizar imagenes container con los comandos Build, Run, Pull y Push utilizando el CLI vctl. Tambien soporta clústeres KIND Kubernetes que se ejecutan sobre Workstation Pro. Pero para estas funcionalidades, requieres una versión de Windows 10 1809 o superior.

Soporte para nuevos Sistemas Operativos: estos son los nuevos sistemas soportados.
RHEL 8.2
Debian 10.5
Fedora 32
CentOS 8.2
SLE 15 SP2 GA
FreeBSD 11.4
ESXi 7.0

Soporte para DirectX 11 y OpenGL 4.1 en la vm:
Esta ventaja trae una serie de requerimientos de hardware que deben cumplirse, como son una GPU con soporte DirectX 11, y en Linux, que sea una gráfica Nvidia, además.
En cuestion de requisitos de software, el Sistema operativo debe ser Windows 7 o superior, y de 64 bits. Para linux, debe traer drivers Nvidia con soporte OpenGl 4.5 o superior, y el driver SVGA3D

Soporte de Render 3D en Linux
Workstation 16 Pro permite el soporte 3D para las GPU Intel en el host Linux para entregar DirectX 10.1 y OpenGL 3.3 a las VM que usan el renderizador Vulkan.

Sandboxed Graphics
La seguridad de la máquina virtual se mejora al eliminar el renderizado de gráficos de vmx y ejecutarlo como un proceso de espacio aislado por separado.

USB 3.1 Controller Support: Se pasa de soporte 3.0 a 3.1

Monster VM´s: Ahora puedes montar VMs con hasta 8 GB de memoria grafica virtual, 32 virtual CPUs y 128 GB de RAM. Eso si, se requiere que tu equipo y tu cpu soporten ambos 32 procesadores lógicos.

Dark Mode: está de moda

Soporte para vSphere 7.0: esto te permite lo siguiente.
Conectar a vSphere 7.0.
Subir una VM local a vSphere 7.0.
Descargar una VM remota corriendo en vSphere 7.0 a tu equipo local con VMware Workstation Pro.
Mejoras de rendimiento.
Velocidades mejoradas en las transferencias de archivos con arrastrar y soltar, y CopyPaste.
Mejora en el tiempo de apagado de la VM.
Mejoras en el rendimiento de los discos NVMe.

Y para terminar, unos enlaces rápidos de descarga:
Workstation 16 Pro Direct DownloadWorkstation 16 Player Direct Download
Fusion 12 Pro

viernes, 21 de agosto de 2020

Recupera el control de las actualizaciones en Windows 10

 A estas alturas, seguro que ya has hecho el cambio a Windows 10, un sistema que se está mostrando como el digno sucesor de Windows 7, muy estable y seguro, además de disponer de un gran número de nuevas características de las que las anteriores versiones carecían. Pero hay un punto negativo en concreto en el que parece que todo el mundo está de acuerdo, y es la pérdida de control de las actualizaciones.

Incluso si hemos instalado ya la última gran actualización del sistema, la 2004 "May 2020 update", no tenemos un control completo de las actualizaciones, estando todavía a merced de los deseos de Microsoft sobre estas, pudiéndonos ocasionar grandes perjuicios por los tiempos o la calidad de los parches instalados (es de todos conocido el problema que han estado dando los parches en Windows 10, causados en gran medida por la disminución de las pruebas sobre estos que se realizaban, en comparacion con anteriores versiones de Windows)

Ahora tenemos una magnífica solución para este problema, la aplicación Patchfluent.

Patchfluent es una aplicación que surgió en Github para solventar esta deficiencia del sistema, permitiéndonos retomar el control de las instalaciones "manuales". La pagina del proyecto en Github está AQUI, mientras que la aplicación la podéis descargar de este otro ENLACE

Es importante leer las instrucciones, ya que se recomienda encarecidamente deshabilitar las actualizaciones automáticas cuando utilices esta aplicación. Por suerte, el desarrollador ha tenido nuestra comodidad en cuenta, y ademas de indicar un procedimiento para su deshabilitado mediante las GPOs, también agrega una opción en su aplicación para desactivarlas desde ahí (imagen superior, justo debajo de "Customize Windows Updates")

Otra gran mejora de este sistema de actualizaciones son las explicaciones de qué incorpora cada nueva actualización, incluso agregando el link a la web de Microsoft para comprobar todos los detalles.

Curiosamente, aunque el sistema con Windows Update tradicional esté completamente al día, con Patchfluent encontramos algunas actualizaciones nuevas:

En definitiva, una gran herramienta, que ni siquiera requiere instalación.

jueves, 18 de junio de 2020

Recursos para el examen AZ-900

Microsoft está realizando serios cambios en su sistema de certificaciones. La verdad es que hablar de esto da para un post bastante extenso por si solo, asi que en este quiero centrarme en la certificación AZ-900 Fundamentals. ¿Que es esto?


El examen AZ-900 fundamental es "la intro", por asi decirlo ,de los servicios de Azure. Es un conocimiento genérico de lo que ofrece la plataforma, no llegando a entrar en profundidad en ningún apartado, pero a la vez, tocando todos.

Si es una intro, ¿para qué molestarse en certificarse? Pues muy fácil: hasta ahora, y desde el siglo pasado prácticamente, podías ser MCSA-MCSE sin renovar las certificaciones. Esto es, podías haberte examinado de MCSA con Windows Server 2003, y ser siendo MCSA a estas alturas y versiones. Pues eso se ha acabado. Ahora las certificaciones hay que renovarlas cada 2 años...con una única excepción, el AZ-900 Fundamentals. Y ahí la utilidad del mismo. Ademas, es más económico, y si conoces la plataforma, es realmente sencillo sacarlo.

Dicho esto, dejo unos cuantos recursos facilitados por Microsoft en sus cursos oficiales, para la preparación del examen:

Documentación del curso 
  • Inglés: https://docs.microsoft.com/en-us/learn/paths/azure-fundamentals/ 
  • Español: https://docs.microsoft.com/es-es/learn/paths/azure-fundamentals/
  • Learning path infographics: https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RE38YZj
  • Certification landing page: https://docs.microsoft.com/en-us/learn/certifications/azure-fundamentals 
  • Skills measured: https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RE3WzVA 
  • Syllabus: https://www.microsoft.com/en-us/learning/course.aspx?cid=AZ-900T01#syllabus 

Toda la documentación de Azure: https://docs.microsoft.com/en-us/ 

Laboratorios para AZ-900: 
  • https://microsoftlearning.github.io/AZ-900T0x-MicrosoftAzureFundamentals/ 
  • Hands-On LABs: https://www.microsoft.com/handsonlabs · Azure Charts: https://azurecharts.com/ 

Third-parties
  • https://linuxacademy.com/course/microsoft-azure-fundamentals-az-900-exam-prep/ 
  • https://www.pluralsight.com/courses/azure-fundamentals 
  • https://www.edx.org/learn/azure 
  • https://www.udemy.com/topic/microsoft-azure/ 

Exámenes de prueba:
  • https://www.measureup.com/microsoft-technical.html 
  • https://www.itexams.com/exam/AZ-900 

Como hacer el examen online:
  • https://ptdrv.linkedin.com/0d74m7z

Technical Skills for Business - Azure Training and Certifications
  • https://ptdrv.linkedin.com/ea1pjqz
Cómo hacer los exámenes:
  • Link
  • https://www.examtopics.com/exams/microsoft/az-900/view/

martes, 31 de marzo de 2020

Deshabilitar TOE (TCP-IP Offload Engine). Por qué se debe deshabilitar

Primero, una breve intro sobre qué es TCP Chimmney Offload, mas conocido como TOE.
Mas o menos a comienzos de siglo, con la aparicion de Windows Server 2003 y el comienzo del uso de las redes Gigabit Ethernet, se desarrolló una tecnología que permitía desplazar carga del trabajo de la CPU en relación a la transferencia de datos, a las tarjetas de red. Se pensó especialmente para la sobrecarga de datos asociada a los protocolos iSCSI y NFS.


Hay que tener en cuenta que TOE es realmente un procesador de la tarjeta de red, mientras que TCP Chimney Offload es un protocolo de Microsoft que se aplica al sistema operativo para el funcionamiento de TOE. Dicho de otro modo, TOE consta de dos partes: una física en la tarjeta, que se controla desde la pestaña de propiedades avanzadas de la tarjeta de red, y otra parte que se controla desde el sistema operativo.

Para explicar de forma simple cómo funciona TOE: normalmente, la descarga TCP consiste en un envio de paquetes monolíticos, mientras que Chimnney Oflload permite una descarga parcial de los paquetes. Cuando funciona, la ventaja es que reduce el tráfico de red, mejorando las comunicaciones.

Lamentablemente, no todas las tarjetas de red gestionan correctamente esta opción de proceso de los paquetes, haciendo que, en vez de mejorar el trafico de red, se pierdan paquetes, o lleguen mal. Son especialmente famosas por estos errores las tarjetas de la marca Broadcom. Y esta es la razón por la que es mejor deshabilitar esta opción, especialmente hoy día.

Vamos con el proceso para deshabilitar esta opción, que como comentaba,consta de 2 partes.

Parte 1. Deshabilitar la opcion TCP Chimney Offload en el sistema operativo.

  1. Abre una ventana de comandos
  2. escribe: netsh int tcp set global chimney=disabled

Si quisieras ver el estado en el que se encuentra esta opción, solo debes poner netsh int tcp show global

Con el comando netstat -t verás que la ultima columna de información que te facilita es el "offload state" o bien "estado de descarga".

Parte 2. Deshabilitar TCP Offload en la tarjeta de red.

Vamos hasta las propiedades del adaptador, y damos en "cambiar las opciones del adaptador", o bien "configurar", según la versión del sistema.


Una vez pulsamos, nos vamos a la pestaña de "opciones avanzadas"


Aquí son varias opciones las que debemos cambiar. En la imagen superior se ve IPv4 Checksum Offload, pero hay que cambiar las siguientes:

  • IPv4 Checksum Offload
  • Large Receive Offload
  • Large Send Offload
  • TCP Checksum Offload
  • Receve Side Scaling
Sobra decir que hay que cambiarlas a "disabled"

Una vez cambiadas, damos ok a todo, y con esto, hemos terminado.

viernes, 10 de enero de 2020

Solventar problemas de conexion a Drac5

Una magnífica herramienta de soporte de los servidores Dell es la iDrac, Drac en versiones antiguas. Perfecta para acceder a los servidores, incluso apagados, permitiendo hasta la conexión de medios virtuales y la reinstalación en remoto.

La ejecución de la consola virtual se puede lanzar de dos formas, a través de java o con el plugin nativo. La ejecución java suele traer consigo problemas de versiones, y si tienes que conectar a múltiples servidores es fácil que acabes con una variedad de versiones java instaladas simultáneamente. Nada recomendable. Es por ello que la mejor opción es la ejecución del plugin nativo de la iDrac.


Conectamos a la consola de la Drac, en este caso. Como se ve, ha evolucionado bastante en sus últimas versiones. En la pestaña de consola, al conectar al servidor, si no hemos pasado anteriormente por una Drac i iDrac, puede salirte el siguiente mensaje:


Es el plugin que instala en el navegador para ejecutar la aplicación de forma nativa, en vez de con Java. Hay que aceptar siempre su instalación. Esto abrirá una nueva ventana del navegador (permitir para este sitio los pop-ups).


Y aquí es cuando vemos un problema con la ejecución de la consola. Por descartar problemas y tratándose de Drac antiguas, probar la conexión con Internet Explorer. Si el problema persiste y tenemos el complemento anterior instalado, significa entonces que no está funcionando adecuadamente. En este caso, iremos a la administracion de complementos del navegador, preferiblemente IE, como dije antes:


Veremos que en las herramientas y extensiones tenemos 2 complementos instalados, ambos habilitados, y de distintas versiones. Chequeamos las versiones instaladas, y deshabilitamos el complemento más antiguo.


Hecho esto, no necesitamos ni reiniciar el navegador. Intentamos de nuevo la conexión, y debería funcionar sin problemas.

jueves, 9 de enero de 2020

Solventar limite de conexion de usuarios a 64 equipos

Es común encontrarse en la situación de tener que generar cuentas de usuario que deben tener restringido el acceso a unos equipos concretos, al margen de sus permisos. Ya sabes, para limitar los equipos sobre los que un usuario puede iniciar sesión, en su objeto de AD vamos a la pestaña Cuenta, y en "iniciar sesión en" se indica los equipos sobre los que puede iniciar la sesión el usuario.

Puede suceder que el usuario requiera iniciar sesión en más de 64 equipos. Y es aquí cuando aparece el problema, al intentar agregar una máquina mas, superando ese límite, que aparece el siguiente mensaje:


Esto es una limitación de esquema de Directorio Activo, que puede ser modificada con el ADSI Edit o Powershell, siempre que seas admin de esquema. Por ejemplo, así:
$Attr = [ADSI]"LDAP://cn=User-Workstations,cn=Schema,cn=Configuration,dc=MyDomain,dc=com"
$Attr.rangeUpper = 2048
$Attr.SetInfo()
Tienes más Info AQUI. y AQUI.

La GUI de ADUC asume 16 caracteres por nombre de NetBIOS, independientemente de los que tenga en realidad los nombres de equipos. Pero esto no se aplica si actualizas el atributo en el código. Aún así, incluso con 16 caracteres por nombre, según los technets de Microsoft, no debe superar los 8192.

Una vez realizado este cambio, se pueden agregar más máquinas vía comando powershell a la cuenta de usuario, sobrepasando ese límite de 64 equipos (la interfaz gráfica seguirá marcando la limitación).

El comando powershell a utilizar para agregar más equipos es el siguiente:
$variable = (Get-ADUser -Identity USER -Properties *).userWorkstations
$newvariaBLE ="EQUIPONUEVO,$VARIABLE"
Set-ADUser -Identity USER -LogonWorkstations $newvariaBLE 
Reemplazar "USER" por el nombre de usuario, y "EQUIPONUEVO" por el nombre del equipo a agregar.

También es conveniente utilizar el siguiente comando,

$variable = (Get-ADUser -Identity user -Properties *).userWorkstations
seguidamente de:

  write-host $variable     
Esto te mostrará los equipos a los que el usuario que has metido en la variable tiene acceso. Es muy conveniente para comprobar que el comando ha funcionado correctamente.

miércoles, 8 de enero de 2020

Modificar el tipo de mailbox en Exchange

A lo largo de los años y en diferentes empresas vengo observando que normalmente los usuarios utilizan algún tipo de cuenta genérica a la que acceden uno o varios miembros del mismo departamento. Normalmente es una cuenta de usuario, con su password, y es compartida por las personas que quieren acceder a la misma. La otra opción es un grupo de distribución que distribuye, valga la redundancia, los mails, a los miembros del grupo.


Lo que no he visto habitualmente es un mailbox compartido, o shared mailbox.
Un shared mailbox tiene varias características interesantes frente a las anteriores opciones:

  1. El usuario asociado a la cuenta se deshabilita automáticamente. No se accede con el user/pass del usuario de cuenta a la cuenta de correo.
  2. Los permisos a esta cuenta pueden ser de acceso y/o envío, de manera que el usuario no tiene que recordar más passwords. Simplemente puede agregar esa cuenta de correo compartida a su mailbox en Outlook.
  3. No hay límite de usuarios accediendo a una cuenta compartida, mientras que en una cuenta común en la que se comparte el user/pass, hay un límite que viene definido no por el número de personas conectadas, sino por el numero de operaciones que se realizan sobre la cuenta. Es decir, pueden conectarse 20 personas, por ejemplo sin tocar nada, pero uno o dos moviéndose por carpetas y enviando mails, o 5 personas trabajando sobre la cuenta simultáneamente. Esto no es un problema en un shared mailbox.

Vamos a tomar como ejemplo, una cuenta llamada "correoprueba", el dominio es lo de menos  ;)

Si hacemos una busqueda en exchange, aparece como "user mailbox"


A continuación, ejecutamos el comando que nos permite cambiar el buzon de usuario a cuenta compartida, shared mailbox: Set-Mailbox correoprueba -Type shared
Lo lanzamos desde la consola de comandos de Exchange.


Tras esto, veremos que Exchange detecta la cuenta de otra manera:


Bien, ahora toca dar accesos a este buzón. Para ello, en la misma búsqueda de la cuenta en Exchange, pulsamos botón derecho, y veremos las siguientes opciones:


Para dar permisos de envío deberemos hacer click sobre "Manage Send As Permission" y agregar a los usuarios aquí. Por el contrario, si solo queremos que puedan acceder a la cuenta pero no enviar, deberemos dar "Full Access Permission"

Una vez asignados los permisos, agregar la cuenta al usuario para que pueda trabajar con ella en su Outlook es muy fácil. En Outlook vamos a Archivo-> Configuración de la cuenta, y ahí, en la primera pestaña, en correo electrónico, agregamos la cuenta pulsando en "nuevo.


Aparecerá el nuevo buzón debajo de vuestro Inbox habitual.
Despues de agregar el shared mailbox, hay que tener cuidado con el campo "de", ya que si tienes permisos de "send as", puedes enviar desde tu cuenta habitual, y desde la cuenta compartida.

A modo de "bonus", no sólo puedes cambiar de cuenta "regular" de usuario a "shared", sino que dispones de estos tipos de mailbox: Regular, Room, Equipment, y Shared, que es la que hemos visto. de manera que revertir el cambio seria tan fácil como hacer "Set-Mailbox -Identity "usuario" -Type Regular.

Y otro truco mas: esto tambien aplica en o365. Seria, por ejemplo, Set-Mailbox -Identity mailbox@contoso.onmicrosoft.com -Type Shared

jueves, 2 de enero de 2020

Renombrar una VM en ESXi

Algo habitual que suele pasar es que una VM cambie de función, y por ello, se suele requerir su cambio de nombre, para identificarla más adecuadamente con su función.

En versiones antiguas de ESX o las primeras de ESXi, una manera de cambiar el nombre consistia simplemente en apagar la máquina, modificar el nombre de la maquina, y seguidamente los nombres de todos sus archivos. Luego, una pequeña modificación en su archivo .vmx con la nomenclatura nueva de los archivos vmdk, y esto solía bastar

A partir de ESXi 5.0 tenemos varias maneras de realizar el cambio de nombre. Vamos a verlas.


Renombrado de VM con Storage vMotion

Sobre la máquina que queremos renombrar, hacemos estos dos pasos:
1º Boton derecho, y renombrar.
2º Ahora iniciamos un storage vMotion a otro datastore.

Renombrado de VM con Cold Storage Migration

1º Boton derecho, y renombrar.
2º Ahora iniciamos un cold storage Migration.

¡Pero si las dos primeras opciones son iguales!, diras. Bueno...si, realmente, lo unico que cambia de una a otra es la red por la que se realiza el movimiento de la VM, y el estado de la VM. Si hacemos un Storage vMotion, el movimiento de la maquina se realiza a traves de la red de vMotion, mientras que si realizamos un cold storage migration, con la VM apagada, la maquina se transfiere mediante la red de gestion. La transferencia es más rápida, pero se come el ancho de banda.

Clonar la máquina

La ventaja de clonar la máquina es que te permite realizarlo en el mismo datastore, si el espacio lo permite. No hay restricciones. Logicamente, si la Vm está apagada, el clonado es más rápido.
Tambien puedes realizar el clonado por medio de VMware vCenter Converter

Renombrado utilizando la consola

Es más laborioso, pero, oye, si te gusta la linea de comandos, ¡adelante! Basicamente es el sistema indicado al principio del artículo, el renombrado archivo por archivo.

  • Apagamos la VM, y seguidamente la eliminamos del inventario NO LA BORRAMOS.
  • Conectamos por SSH al ESXi donde esté la VM, con, por ejemplo, putty, y navegamos hasta el directorio donde se encuentre la VM. por poner un ejemplo,

# cd /vmfs/volumes/DatastoreName/originalname

  • Renombramos el archivo .vmdk con el comando vmkfstools -E. Por ejemplo,

# vmkfstools -E "nombreantiguo.vmdk" "nuevonombre.vmdk"

  • Copia el archivo .vmx con el comando copy de siempre:

# cp "nombreantiguo.vmx" "nuevonombre.vmx"

  • Editamos el archivo .vmx nuevo, con por ejemplo, vi:

# vi "nuevonombre.vmx"
...y modificamos todos los nombres antuguos al nuevonombre de archivos, y guardamos

  • Renombramos todos los demas archivos, menos el vmx. Puedes utilizar el comando mv, para ello:

# mv "nombreantiguo.nvram" "nuevonombre.nvram"

  • Ya solo queda volver a agregar la Vm al inventario. Podemos hacerlo mediante el explorados en el vCenter, y sobre el archivo .vmx dar a "agregar a inventario", o bien, ya metido en comandos, utilizar el siguiente:

# vim-cmd solo/registervm /vmfs/volumes/DatastoreName/nuevonombre/nuevonombre.vmx

Todo esto lo tienes también en este kb de VMware.