Migrar de VMware Workstation a Hyper-V con discos RAID-1

Después de de aplicar la última actualización VMware Workstation en mi laboratorio casero y darme cuenta que fué retirado el soporte a las máquinas compartidas decidí migrar a un hypervisor tipo-1 (baremetal).

Una característica indispensable que estaba buscando es mantener la capacidad de RAID-1 por software para mi arreglo de 2 discos Seagate de 2 TB.

VMware ESXi es un hypervisor con el que he trabajado profesionalmente desde hace mas de 10 años, y en realidad me agrada mucho, pero tenía dos problemas:

  • No soporta software RAID-1
  • No soporta la tarjeta Realtek de mi motherboard (ASUS Prime B365M-A) de manera nativa*

Después de investigar un poco, decidí probar Microsoft Hyper-V Server 2019, el cual tiene estas ventajas:

  • Soporta software RAID-1
  • Soporta la tarjeta Realtek sin tener que instalar parches adicionales
  • Es gratuito
  • No requiere instalar Windows Server 2019

Es importante recalcar que estoy hablando de la versión Hyper-V Server 2019, no de Windows Server 2019 con el rol de Hyper-V, que son cosas diferentes.

Ambiente antes de migración

El ambiente actual esta formado de una máquina armada:

  • Motherboard ASUS Prime B365M-A
  • Procesador Intel i5-9400
  • 2 módulos  de 16 GB – Kingston HyperX Fury PC4-21300 CL16 (HX426C16FB3/16)
  • 1 modulo NVMe – Kingston A400 SSD 960 GB (SA400S37/960G)
  • 2 discos Western Digital SSD WD Green – 120GB, SATA III, 2.5″ (WDS120G2G0A)

La máquina corre Debian Linux 10.3, y funciona como nuestro servidor de archivos (con Samba). Además es un host de dos máquinas virtuales con VMware Workstation 15.

El sistema operativo arranca desde el disco NVMe, y todos los archivos y las VMs viven en un volumen espejeado en dos discos:

Ambiente al final

Al final de la migración debe quedar de la siguiete manera:

La máquina ahora correrá Microsoft Hyper-V Server 2019, y lo que teníamos en el servidor de archivos server ahora será otra máquina virtual con Debian Linux 10.

Migración de datos

El primer problema es migrar los datos, que actualmente están en un volúmen RAID-1 formateado con ext4. El plan es el siguiente:

  1. Romper el arreglo RAID-1 para formatear uno de los discos en NTFS y dejar ahi los discos virtuales
  2. Transformar los VMDK a VHDX y copiarlos el NTFS
  3. Una vez que estemos corriendo Hyper-V volver a crear el arreglo RAID-1

Esto lo hacemos de la siguiente manera:

  • Desde el host actual con Linux, romper el arreglo RAID-1 y remover el disco /dev/sda del arreglo:
mdadm --fail /dev/mda /dev/sda
mdadm --remove /dev/md0 /dev/sda
  • Instalar Hyper-V en el disco NVMe
  • En Hyper-V los discos se ven asi:
    • Disk 0: Disco Seagete #1 — Este disco se va a formatear con NTFS
    • Disk 1: Disco Seagate #2 — Este disco se deja con ext4 (tiene los datos)
    • Disk 2: Disco NVMe
  • Preparar disco 1 para uso de Hyper-V
DISKPART
SELECT DISK 0
CLEAN
CONVERT DYNAMIC
CREATE VOLUME SIMPLE
ASSIGN LETTER=E
FORMAT FS=NTFS QUICK
  • Compartir disco para tener acceso desde la estacion de trabajo:
NET SHARE DATASTORE=E:\ /GRANT:Administrator,CHANGE
  • En el servidor Hyper-V preparar el disco 1 para montarse directamente en la VM “server”
SELECT DISK 1
OFFLINE DISK
  • Crear nueva VM con Debian llamada “server” y asignarle dos discos:
    • Disco 1: Archivo VHDX que vive en el disco NVMe
    • Disco 2: Acceso físico al disco #1 (que será montado en /mnt)
  • Desde la nueva VM se copian los datos del disco#2 al disco #1
cp -r /mnt/home/public /home/public
  • En la VM “server” se habilita una carpeta compartida “vmware” con Samba donde se comparten los VMDKs del VMware Workstation.
  • Los discos de VMware estan en formato ESXi (tipo 4) que no es soportado por Microsoft Virtual Machine Converter, de manera que hay que convertirlos de formato con vmware-vdiskmanager y dejarlos en C:\TEMP en la estación de trabajo:
vmware-vdiskmanager -r "\\server\vmware\nvr\nvr-0.vmdk" -t 6 c:\temp\nvr-0.vmdk"
vmware-vdiskmanager -r "\\server\vmware\unifi\unifi-0.vmdk" -t 6 c:\temp\nvr-0.vmdk"
  • Ahora falta copiar y convertir los discos virtuales de las VM “nvr” y “unifi”. Vamos a utilizar la herramienta Microsoft Virtual Machine Converter:
Import-Module "C:\Program Files\Microsoft Virtual Machine Converter\MvmcCmdlet.psd1"
ConvertTo-MvmcVirtualHardDisk -SourceLiteralPath "C:\temp\nvr-0.vmkd" -DestinationLiteralPath "\\hyperv\datastore\VirtualDisks\nvr-0.vhdx" -VhdType DynamicHardDisk -VhdFormat vhdx -Verbose
ConvertTo-MvmcVirtualHardDisk -SourceLiteralPath "C:\temp\unifi-0.vmkd" -DestinationLiteralPath "\\hyperv\datastore\VirtualDisks\unifi-0.vhdx" -VhdType DynamicHardDisk -VhdFormat vhdx -Verbose

Activación de RAID-1 en Hyper-V

Una vez migrados todos los datos y convertidos los archivos VMDK a VHDX, podemos desmontar el disco 0 de la VM “server” y quitarlo de la configuración.

Finalmente se agrega el disco al volumen dinámico en Hyper-V:

DISKPART
SELECT VOLUME E:
ADD DISK=0

Validamos la configuración del volumen:

Conclusiones

Hemos logrado los objetivos:

  • El hypervisor paso de ser un tipo 2 a un tipo 1.
  • El Linux (que era mi hypervisor tipo 2) quedó virtualizado
  • Las otras dos máquinas fueron transformadas de VMware a Hyper-V
  • Los discos trabajan en un arreglo RAID-1 controlado a nivel hypervisor.

Habilitar Linux como Access Point

Tengo un servidor MintBox cuyas antenas wireless no estoy usando… así que decidí incrementar la cobertura de mi red inalámbrica habilitándolo como un Access Point. El servidor está corriendo Linux Mint 16 Petra, pero este procedimiento debe funcionar con cualquier variante de Debian.

Nótese que es un Access Point, no un router. Es decir, el server no ofrece servicios DHCP, DNS o de ruteo, para eso tengo un ruter. Simplemente conecta la red inalámbrica al resto de mi LAN.

Arquitectura

El servidor cuenta con tarjetas Ethernet (eth0 y eth1) y una tarjeta Wi-Fi (wlan0).

Vamos a crear un bridge (br0) entre la tarjeta wlan0 y la eth0. La tarjeta eth1 no está en uso.

Requisitos

Instalar los paquetes bridge-utils y hostapd.

# apt-get install hostpad
# apt-get install bridge-utils

Configuración de hostapd

Editar el archivo /etc/default/hostapd. Descomentar y ajustar el valor de DAEMON_CONF para que apunte al archivo de configuración:

DAEMON_CONF="/etc/hostapd/hostapd.conf"

Crear el arhivo /etc/hostapd/hostapd.conf con los siguientes valores. Esto configura una red WPA2-PSK con autenticación TKIP y cifrado AES/CCMP.

#
# See https://w1.fi/cgit/hostap/plain/hostapd/hostapd.conf for reference
#
interface=wlan0
bridge=br0
driver=nl80211
hw_mode=g
ieee80211n=1
wmm_enabled=1
ht_capab=[HT40][HT20][SHORT-GI-20]
country_code=MX
ieee80211d=1
channel=3
ignore_broadcast_ssid=0
ssid=mi-nombre-de-red
wpa=2
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP
wpa_passphrase=mi-contraseña
auth_algs=1
macaddr_acl=0

Configurar las interfaces de red

Editar el archivo /etc/network/interfaces para crear el bridge y eliminar la configuración de la tarjeta eth0:

auto lo br0

iface lo inet loopback

iface wlan0 inet manual

iface eth0 inet manual

iface br0 inet static
        bridge_ports wlan0 eth0
        address 192.168.1.10
        netmask 255.255.255.0
        gateway 192.168.1.254
        dns-nameserver 192.168.1.254

Reiniciar

Tu nueva SSID debe estar visible al reiniciar.

Notas sobre el almacenamiento en la Samsung Galaxy Tab 7 (GT-P1000)

La Galaxy Tab 7 (GT-P1000) tiene 3 sistemas de almacenamiento:

  • Memoria flash interna
  • Tarjeta SD interna
  • Tarjeta SD externa (extraíble)

Desde el punto de vista del sistema operativo, estos dispositivos son visibles con los siguientes nombres respectivamente:

/dev/block/bml0
/dev/block/mmcblk0
/dev/block/mmcblk1

La memoria flash está dividida en áreas llamadas particiones. Algunas de ellas tienen sistemas de archivos y otras son para uso crudo. Las harramientas como ODIN o Heimdall, utilizadas para grabar custom ROMs o kernels graban en esta memoria.

La tabla de particiones de la memoria flash interna se organiza como sigue (se muestran los nombres de los dispositivos BML, así como el nombre del archivo que es grabado por ODIN en cada zona):

/dev/block/bml1   IBL+PBL:[boot.bin]           # Initial Boot Loader + Primary Boot Loader
/dev/block/bml2   PIT:[gt-p1000.pit]           # Partition Information Table
/dev/block/bml4   SBL:[sbl.bin]                # Secondary Boot Loader
/dev/block/bml5   SBL2:[sbl.bin]               # Secondary Boot Loader 2
/dev/block/bml6   PARAM:[param.lfs]            # param file system
/dev/block/bml7   KERNEL:[zImage]              # Kernel image
/dev/block/bml8   RECOVERY:[zImage]            # Kernel image for recovery
/dev/block/bml9   FACTORYFS:[factoryfs.rfs]    # Factory file system
/dev/block/bml10  DBDATAFS:[dbdata.rfs]        # dbdata file system
/dev/block/bml11  CACHE:[cache.rfs]            # cache file system
/dev/block/bml12  MODEM:[modem.bin]            # Modem firmware

Los dispositos BML (Block Management Layer) dan acceso crudo a la memoria flash, ya sea como un dispositivo único (bml0) o a por particion (bml1, bml2, etc.)

Debido a que la memoria flash se va dañando con el uso, existe una capa de software llamada STL (Sector Translation Layer) que gestiona la asignación de los bloques que “ven” los sistemas de archivos montados en la flash, y así poder balancear su uso. En los dispositivos llamados USB Drives, esta gestión se hace en la propia circuitería y no requiere intervención del sistema operativo.

Por lo anterior, el kernel expone algunas áreas de la flash como dispositivos STL (/dev/block/stlx), y sobre éstos van montados los sistemas de archivos de la siguiente manera:

/dev/block/stl3   /efs        rfs
/dev/block/stl6   /mnt/.lfs   j4fs #(verificar)
/dev/block/stl9   /system     rfs
/dev/block/stl10  /dbdata     rfs
/dev/block/stl11  /cache      rfs

La tarjeta SD interna (/dev/block/mmcblk0) también está dividida en 3 particiones:

mmcblk0p1 /mnt/sdcard    vfat
mmcblk0p2 /data          rfs
mmcblk0p3 /preload       vfat

La partición /mnt/sdcard es el área a la que el usuario tiene acceso desde las aplicaciones.

La tarjeta SD externa (/dev/block/mmcblk1) tiene una sola partición:

mmcblc1p1  /mnt/sdcard/external_sd

GlobcalScale Technologies DreamPlug

El DreamPlug de GlobalScale Technologies es un kit de desarrollo basado en el controlador SoC (“System-On-Chip”) Marvell® 88F6281 with Sheeva™. Estos dispositivos son, como su nombre lo indica, todo un “sistema en un chip” ya que integran en una sola pastilla lo siguiente:

  • CPU de arquitectura ARMv5TE con 256KB de cache L2
  • 2 puertos Ethernet Gigabit
  • 2 puertes SerialATA
  • Controlador USB 2.0
  • SDIO
  • Controlador DDR
  • Puerto PCI-E
  • 2 canales TDM
  • Audio y Video MPEG
  • Controlador NAND, 2 x UART, TWSI y SPI
  • 4 IDMA/XOR

DreamPlug de GlobalScale Technologies

DreamPlug de GlobalScale Technologies

Con el DreamPlug, obtenemos una poderosa computadora de bajo consumo lista para usarse.  Viene con Debian 6.0.5 “squeeze” pre-instalado. El plug trae:

  • 2 puertos USB
  • 1 puerto eSATA
  • 1 puerto óptico S/PDIF para audio digital
  • 1 puerto mini-jack para audífonos
  • 1 puerto mini-jack para micrófono
  • 1 puerto JTAG
  • 1 puerto para memoria SD
  • 512 MB DDR2 de 800 MHz
  • 2 MB de memoria serial flash SPI para uBoot
  • 1 microSD interna
  • 1 ranura SD de expansión

El puerto JTAG sirve para tener acceso a la consola y requiere la compra del módulo opcional JTAG, cosa que recomiendo mucho si se desean hacer cosas como cambiar el sistema operativo o modificar los valores de la memoria flash.

DreamPlug con el módulo JTAG conectado. La caja de CD es para dar una idea del tamaño real del dispositivo.

DreamPlug con el módulo JTAG conectado. La caja de CD es para dar una idea del tamaño real del dispositivo.

La memoria microSD interna es utilizada para el sistema operativo y tiene 3 particiones: la primera, de tipo FAT-16, contiene el núcleo del sistema operativo en formato uImage; la segunda partición tiene el sistema de archivos raiz y la tercera tiene una copia de respaldo del núclero y del fileystem en un archivo .tgz.

El hecho de tener el filesystem en una memoria microSD es una gran ventaja respecto a los plug anteriores que utilizaban memoria flash para el SO, lo que los hacía mas difíciles de actualizar.

Para empezar a utilizarlo, sólo se conecta el plug al módulo JTAG y éste a la computadora por el puerto USB. Debemos descargar los controladores del convertidor UART a USB, después iniciamos nuestro emulador de terminal preferido (en mi caso, PuTTY) y lo configurarmos a 115200,8,1,N y listo.

Al encender el plug, la terminal mostrará lo siguiente:

U-Boot 2011.06 (Oct 15 2011 - 02:02:08)
Marvell-DreamPlug

SoC:   Kirkwood 88F6281_A0
DRAM:  512 MiB
SF: Detected MX25L1606 with page size 256, total 1 MiB
In:    serial
Out:   serial
Err:   serial
Net:   egiga0, egiga1
88E1121 Initialized on egiga0
88E1121 Initialized on egiga1
Hit any key to stop autoboot:  0
Marvell>>

Hasta aquí como intruducción al DreamPlug. En los próximos artículos hablaremos sobre cómo crear un sistema de video vigilancia con el software ZoneMinder.

Configuración de Postfix con Yahoo! Mail Plus

El escenario consiste en un servidor con Ubuntu Server 10.4 que utilizará a los servicios de Yahoo! Mail Plus como relay host.

Lo que se debe hacer es lo siguiente:

# apt-get install postfix

Crear un nuevo archivo /etc/postfix/main.cf y con lo siguiente:

biff = on
append_dot_mydomian = yes
redme_direcotry = no
myhostname = tuhostname.dominio.tld
mydomain = dominio.tld
myorigin = /etc/mailname
mydestination = hostname.dominio.tld, localhost
smtp_use_tls = yes
smtp_tls_loglevel = 0 # Aumentar para diagnostico
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl-passwords
smtp_sasl_security_options = noanonymous
smtp_sender_dependent_authentication = yes
relayhost = [plus.smtp.mail.yahoo.com]:587
inet_protocols = ipv4

Se debe crear el archivo con las contraseñas SASL /etc/postfix/sasl-passwords:

usuario1@dominio.com usuario1@dominio.com:contraseña
usuario2@dominio.com usuario2@dominio.com:contraseña
...

Compilar el archivo de contraseñas:

# postmap hash:/etc/postfix/sasl-passwords

Finalmente, reiniciar el servicio de postfix:

# service postfix restart

Probar el envío de correos:

echo -e "Subject: Prueba\nEsta es una prueba" | sendmail -f usuario@yahoo.com destinatario@domino.com

En caso de problemas, verificar el archivo /var/log/syslog.