Hola Habr!
De vez en cuando, escucho de ingenieros en ejercicio algo extraño: VMDK, VHD y VHDX son formatos de disco virtual completamente diferentes, casi cerrados, y la conversión de uno a otro es un proceso largo y doloroso. Hoy demostraré que esto no es así, averiguaré cómo se relacionan estos formatos entre sí y cómo realizar una conversión rápida al migrar de Hyper-V a VMware y viceversa.
Un poco de teoría Desde el punto de vista de las propiedades, los discos virtuales se dividen en dos tipos:
- delgado (disco dinámico) y
- grueso (disco fijo). Todo lo demás (diferencia, aprovisionamiento grueso, cero perezoso), solo variaciones sobre el tema.
No me detendré en esto en detalle. Solo puedo decir que más adelante hablaremos de discos gruesos.
Formatos de disco
RAW : imagen "en bruto" de cualquier unidad. Este es un contenedor normal que no contiene encabezados y pies de página específicos y representa la imagen del disco "tal cual". Si abrimos dicha imagen con un editor HEX, veremos inmediatamente los encabezados del GPT / MBR y / o el sistema de archivos. La misma imagen exacta se obtiene a través del comando dd en Linux. RAW en este sentido es absolutamente honesto con nosotros.
El comienzo del archivo RAW.
Fin del archivo RAW.VMDC. VMware ESXi es un RAW ordinario, donde la geometría del disco se describe en un descriptor de archivo de texto normal (descriptor). Es su nombre el que vemos en vSphere Console cuando conectamos un disco virtual a una máquina virtual o exploramos el contenido de un directorio en Datastore. VMware ESXi no hace nada con la imagen. Absolutamente El disco descansa sobre sí mismo y se expande según sea necesario. En la mejor tradición de VMware, el formato del descriptor es muy simple:
# Disk DescriptorFile version=1 encoding="UTF-8" CID=fffffffe parentCID=ffffffff isNativeSnapshot="no" createType="vmfs" # Extent description RW 15122560 VMFS "disk-example-flat.vmdk" # The Disk Data Base #DDB ddb.adapterType = "lsilogic" ddb.geometry.cylinders = "941" ddb.geometry.heads = "255" ddb.geometry.sectors = "63" ddb.longContentID = "4f5dc83d0a5270bee54e2d85fffffffe" ddb.uuid = "60 00 C2 93 b4 38 ed dd-a3 85 88 48 68 40 2f c0" ddb.virtualHWVersion = "13"
Y no solo es simple, sino también funcional: es suficiente para tomar notas en el archivo descriptor para expandir el disco virtual a cualquier valor admitido. Esto le permite llenar discos con ceros o marcarlos como delgados, sin tener que mantener la información de geometría en los encabezados del disco.
A continuación se presentan algunos valores estándar para todas las secciones del descriptor:
Puede encontrar una descripción de todos los valores en la especificación de formato:
VMware Virtual Disk Format 1.1Vhd. El VHD grueso es el mismo RAW, pero con un pie de página de 512 bytes, que describe la geometría del disco. La máquina virtual Microsoft Hyper-V no tiene un archivo descriptor separado. La descripción de la geometría del disco toma 4 bytes. En realidad, a partir de aquí, la limitación en el tamaño del disco de 2 TB.
Pie de página Los últimos 512 bytes del disco.Lo más interesante es que si crea un archivo descriptor y desliza un disco VHD con un pie de página en el ESXi, el hipervisor VMware ignorará este pie de página y aceptará VHD como nativo.
Cuando Storage vMotion convierte un disco en delgado, simplemente corta este pie de página, y en la salida obtenemos el mismo RAW sin ceros al final. Y cuando se convierte en un disco grueso, honesto RAW. Esto es lo que voy a demostrar un poco más tarde.
VHDX. Toda la información de la geometría del disco se almacena en los primeros 4096 Kbytes del disco virtual, en el área del encabezado.
El esquema general del disco grueso VHDX.¿Cómo es esta área? Contiene dos copias de los encabezados con sus registros, el BAT y el área de metadatos son comunes.
La estructura lógica del encabezado del disco.En una unidad de tiempo, solo una copia del encabezado está activa. Esto proporciona un cierto nivel de tolerancia a fallos de encabezado en caso de interrupciones no planificadas en las operaciones de lectura / escritura. Después de cada operación de E / S, la copia se replica y se realiza un cambio.
Diseño del área del encabezado.Para convertir VHDX a RAW, solo necesitamos cortar los primeros 4096 KB.
Iniciar datos a 5 MB.Un lector atento, por supuesto, dirá: ok, Zhenya, pero ¿convertir RAW a VHDX débilmente? A lo que responderé: depende del sistema de archivos y de cuánto le permita escribir datos al comienzo del archivo. Manualmente en el sistema de archivos NTFS, esto se puede hacer desplazando el inicio del archivo 4 MB hacia adelante en la MFT y agregando el encabezado a este lugar.
La utilidad
vhdxtool.exe funciona con el mismo principio
. Sin embargo, con esta conversión, no obtendremos una imagen hermosa en forma de un encabezado de 4 MB y RAW. El disco será visible e incluso funcionará correctamente como VHDX, pero también habrá una gran cantidad de "basura" de ceros que aparecieron debido a manipulaciones con desplazamientos. La unidad no se optimizará. Se recomienda migrar las máquinas virtuales con dicho disco a otro volumen u optimizarlas mediante los cmdlets Convert-VHD u Optimize-VHD. Si esto no se hace, el disco ocupará más espacio del que debería y puede funcionar más lentamente.
Sin embargo, en escenarios de migración de VMware a Hyper-V, esta utilidad es indispensable, ya que le permite realizar conversiones in situ sin tener que leer el disco de origen byte por byte y crear una copia al lado. Toda la aspereza se suavizará en la primera migración de Storage Live.
Conclusión: los discos gruesos de los formatos VMDK, VHD, VHDX en realidad no son muy diferentes entre sí. Se basan en RAW con varios aditivos. Usando el mismo editor HEX o funciones del sistema operativo para trabajar con el sistema de archivos, podemos convertir 10 TB de VMDK o VHDX en el disco del hipervisor de destino en un par de segundos.
Echemos un vistazo a cómo VMware Exsi trata con VHD.
- Como ejemplo, creé una imagen de Windows Server usando Convert-WindowsImage con una inyección de controladores y parámetros de VMware:
- Versión del sistema operativo: Windows Server 2019 Standard,
- Tipo de disco: fijo,
- Diseño de disco: GPT,
- Tamaño del disco: 30 GB.
Preste atención a los parámetros FileSize (tamaño real del archivo) y Size (tamaño del disco en términos de VM). La diferencia entre los valores es exactamente 512 bytes, el tamaño del pie de página VHD. - Cambie el nombre de la unidad a Win2019-test2-flat.vmdk para cargarla en el almacén de datos de ESXi.
- A continuación, creo una máquina virtual vacía en VMware ESXi con un disco grueso (ansioso a cero) para que el descriptor VMDK se cree automáticamente y no tenga que calcular manualmente los cilindros.
- Nos conectamos al host a través de WinSCP y reemplazamos el archivo existente:
Todo es justo: el pie de página está en su lugar. - Encienda la VM y vea que el sistema operativo se inicia sin ningún problema. Solo queda instalar VMware Tools, que será simple, ya que Convert-WindowsImage nos permite instalar controladores de dispositivo.
- Mueva el disco a otro Datastore a través de Storage vMotion y conviértalo en un disco delgado.
- Compruebe el tamaño: el disco se ha adelgazado.
- Si volvemos a convertir a un disco grueso o migramos la VM al almacenamiento de archivos, obtenemos el RAW más puro sin encabezados.
El pie de página se rompió.
El mismo enfoque funciona para los RAW creados a través de dd. E incluso en la dirección opuesta. De esta manera, verá que VMware ESXi acepta discos de pie de página o RAW de terceros.
Si no quieres trucos, puedes usar las herramientas a continuación.
Para resumir. Los diferentes formatos de discos virtuales gruesos no son tan diferentes. En el corazón de todo RAW con varios "aditivos".
La conversión de formatos de disco virtual no da miedo y, como he mostrado, a veces puede prescindir de ella.
El principal beneficio de todo esto es la reducción del tiempo de migración de Hyper-V a VMware y viceversa y el tiempo de inactividad de VM durante la migración. En DataLine, practicamos esto con el tiempo de inactividad de VM por menos de 30 minutos. El registro es de 40 segundos de tiempo de inactividad de VM durante la migración entre hipervisores.
Solo recuerde que al migrar entre diferentes hipervisores, una conversión no es suficiente. Como mínimo, primero debe instalar los componentes de integración del hipervisor de destino, eliminar o deshabilitar el inicio de los componentes del hipervisor de origen, eliminar los dispositivos virtuales del hipervisor de origen, etc. Pero esta es una historia completamente diferente, sobre la cual también puedo contar.
Enlaces utiles: