Clonacion virtual
Qué sucedería si quisiéramos viajar a una ciudad distante, pero no podemos llevar nuestra laptop, pero necesitamos nuestros programas y archivos. Tal vez la respuesta más fácil es programas portables. Cargamos nuestros archivos y programas dentro de un dispositivo usb y fín de la historia. Pero; y si queremos llevar TODO el contenido de la laptop (sistema operativo, app, archivos, etc) ya que necesitamos las configuraciones que tenemos. En este punto lo primero que nos viene a la cabeza es, sacar el disco de la laptop y conectarlo a otro equipo y resuelto el problema; pero los expertos saben muy bien que esto afecta la activación de los Sistemas Windows, ya que existe una limitación en los cambios del hardware que puede impedir que un DD de un equipo funcione en otro. Además está el problema de los drivers, pantallazos azules y otros problemas derivados de este cambio.
Sin embargo este es el menor de los problemas. En los entornos críticos como servidores en producción, datacenters, etc, a veces necesitan trasladarse a diferentes ubicaciones, por reordenamiento de las empresas hacia nuevos sitios con destinación específica, entre otras causas, pero hacerlo implica una pesadilla logística... Y si hablamos de copias de seguridad, el asunto se pone aún más grave.
Supongamos que tenemos un servidor que controla nuestra red local, bases de datos, correos, etc. Y necesitamos moverlo a otra oficina (para no poner la cosa muy dramática). Hay que hacerlo en un horario donde nadie dependa de sus servicios, pero si ese horario no existe, ya que es un servidor web 24/7 o un proxy. La única manera es apagarlo, y trasladarlo a la nueva ubicación, y de paso mover toda una infraestructura dependiente (switches, cableado estructurado, etc). Una odisea que puede tardar horas, y a veces días.
Otro caso que se puede presentar es el tiempo de recuperación si falla un servidor principal (proxy) y se paraliza nuestra empresa. Aquí lo más lógico es usar un sistema de Backup. Puede ser un sistema de hardware redundante con tecnología Raid o por software, usando programas de backup como Norton Ghost, Acronis, Paragon, etc. Son sistemas muy buenos pero..... El "pero" es que si falla nuestro sistema primario, el tiempo de respuesta (reemplazar el sistema con la copia de seguridad) puede tardar muchas horas y en ambos casos es tiempo que no tenemos... Y ni hablar de los sistemas Raid (Raid 5 discos en espejo), ya que duplican los errores en todos los discos, por tanto no deben siquiera ser considerados como alternativa.
En la actualidad los sistemas de respaldo tradicionales, ya sean por hardware o por software, no responden a la dinámica exigente de los entornos críticos altamente volátiles y cambiantes y las empresas no pueden permitirse el lujo de parar su producción por un cambio de localidad o por una copia de seguridad.
Se necesitan alternativas capaces de respaldar sistemas completos online y ponerlos en funcionamiento en fracciones de segundos, sin interrupción en los procesos o uso de Raid o Discos de Reserva (Raid)... Y para matar todos estos pájaros de un solo tiro, o más bien estos mosquitos con un cañón, la solución perfecta es la Clonación Virtual.
Sin embargo este es el menor de los problemas. En los entornos críticos como servidores en producción, datacenters, etc, a veces necesitan trasladarse a diferentes ubicaciones, por reordenamiento de las empresas hacia nuevos sitios con destinación específica, entre otras causas, pero hacerlo implica una pesadilla logística... Y si hablamos de copias de seguridad, el asunto se pone aún más grave.
Supongamos que tenemos un servidor que controla nuestra red local, bases de datos, correos, etc. Y necesitamos moverlo a otra oficina (para no poner la cosa muy dramática). Hay que hacerlo en un horario donde nadie dependa de sus servicios, pero si ese horario no existe, ya que es un servidor web 24/7 o un proxy. La única manera es apagarlo, y trasladarlo a la nueva ubicación, y de paso mover toda una infraestructura dependiente (switches, cableado estructurado, etc). Una odisea que puede tardar horas, y a veces días.
Otro caso que se puede presentar es el tiempo de recuperación si falla un servidor principal (proxy) y se paraliza nuestra empresa. Aquí lo más lógico es usar un sistema de Backup. Puede ser un sistema de hardware redundante con tecnología Raid o por software, usando programas de backup como Norton Ghost, Acronis, Paragon, etc. Son sistemas muy buenos pero..... El "pero" es que si falla nuestro sistema primario, el tiempo de respuesta (reemplazar el sistema con la copia de seguridad) puede tardar muchas horas y en ambos casos es tiempo que no tenemos... Y ni hablar de los sistemas Raid (Raid 5 discos en espejo), ya que duplican los errores en todos los discos, por tanto no deben siquiera ser considerados como alternativa.
En la actualidad los sistemas de respaldo tradicionales, ya sean por hardware o por software, no responden a la dinámica exigente de los entornos críticos altamente volátiles y cambiantes y las empresas no pueden permitirse el lujo de parar su producción por un cambio de localidad o por una copia de seguridad.
Se necesitan alternativas capaces de respaldar sistemas completos online y ponerlos en funcionamiento en fracciones de segundos, sin interrupción en los procesos o uso de Raid o Discos de Reserva (Raid)... Y para matar todos estos pájaros de un solo tiro, o más bien estos mosquitos con un cañón, la solución perfecta es la Clonación Virtual.
Clonación Virtual
La Clonación Virtual es un procedimiento similar a la Clonación Incremental de máquinas físicas P2P (Physical-to-Physical) pero usando la virtualización P2V (Physical-to-Virtual), con sincronizado en tiempo real y/o programable, para luego revertir el proceso a V2P (Virtual-to-Physical) o mantener varios duplicados de los sistemas virtuales V2V (Virtual-toVirtual)
En otras palabras, en lugar de realizar una típica imagen de disco duro y luego guardarla, con actualización tradicional o incremental, la Clonación Virtual nos permite involucrar una serie de técnicas que nos permiten clonar nuestro sistema completo (laptop, PC, servidor, tablet, smarthphone, etc) en un disco virtual y guardarlo en un dispositivo usb (pendrive) para poderlo llevar a donde quiera y usarlo al momento que queramos con nuestro hipervisor de preferencia. Y para mantenerlo actualizado con el sistema físico, simplemente usamos un programa de sincronizado, el cual, en sitio o remotamente (sync remoto, la nube, vnc, etc), puede mantenerlos sincronizados en tiempo real y autoprogramable, con la posibilidad de clonar una laptop, PC, servidor, tablet, smarthphone, etc, cuantas veces se requiera con fines de backup o especialmente para incrementar el rendimiento del sistema físico a través del balanceo de carga. Para lograrlo, bastan unos simples pasos y el uso de algunas herramientas que describiremos a continuación.
La Clonación Virtual es un procedimiento similar a la Clonación Incremental de máquinas físicas P2P (Physical-to-Physical) pero usando la virtualización P2V (Physical-to-Virtual), con sincronizado en tiempo real y/o programable, para luego revertir el proceso a V2P (Virtual-to-Physical) o mantener varios duplicados de los sistemas virtuales V2V (Virtual-toVirtual)
En otras palabras, en lugar de realizar una típica imagen de disco duro y luego guardarla, con actualización tradicional o incremental, la Clonación Virtual nos permite involucrar una serie de técnicas que nos permiten clonar nuestro sistema completo (laptop, PC, servidor, tablet, smarthphone, etc) en un disco virtual y guardarlo en un dispositivo usb (pendrive) para poderlo llevar a donde quiera y usarlo al momento que queramos con nuestro hipervisor de preferencia. Y para mantenerlo actualizado con el sistema físico, simplemente usamos un programa de sincronizado, el cual, en sitio o remotamente (sync remoto, la nube, vnc, etc), puede mantenerlos sincronizados en tiempo real y autoprogramable, con la posibilidad de clonar una laptop, PC, servidor, tablet, smarthphone, etc, cuantas veces se requiera con fines de backup o especialmente para incrementar el rendimiento del sistema físico a través del balanceo de carga. Para lograrlo, bastan unos simples pasos y el uso de algunas herramientas que describiremos a continuación.
Backup virtual de un sistema físico
Consiste en convertir un sistema físico (disco duro de un PC o servidor), en frío o en caliente, en un disco duro virtual, para luego ponerlo en funcionamiento con un Hipervisor como VirtualBox, o exportarlo a sistemas de virtualización ya conocidos, como VMWare, VirtualPc o Hyper-V.
Existen muchas app que pueden convertir una máquina física en virtual y viceversa, tales como Acronis True Image Echo, Symantec System Recovery Server Edition, Platespin , VMWare Converter ( Tutorial), XenConvert de Citrix, EaseUS Todo Backup Server, Partition Assistant, R-Drive Image, entre otras, sin embargo hoy usaremos Disk2vhd de Sysinternal, que es una herramienta mucho más sencilla de usar, liviana y gratis.
Existen muchas app que pueden convertir una máquina física en virtual y viceversa, tales como Acronis True Image Echo, Symantec System Recovery Server Edition, Platespin , VMWare Converter ( Tutorial), XenConvert de Citrix, EaseUS Todo Backup Server, Partition Assistant, R-Drive Image, entre otras, sin embargo hoy usaremos Disk2vhd de Sysinternal, que es una herramienta mucho más sencilla de usar, liviana y gratis.
Paso 1: Creando disco virtual VM de sistema físico
Disk2VHD convierte un sistema completo (windows o linux) en un solo archivo con extensión . VHD, que es un formato admitido por VirtualBox y Microsoft Virtual Machine.
Durante el procedimiento se hace un volcado del HDD virtual (.VHD) a un dispositivo diferente al disco del sistema físico.
Disk2vhd está diseñada para Windows, por tanto puede realizar este procedimiento en caliente en un PC o servidor con Windows. Para Linux puede ejecutar como root el comando "dd" en el terminal. Primero identificamos el disco a clonar (dev)
Y luego ejecutamos
Disk2vhd está diseñada para Windows, por tanto puede realizar este procedimiento en caliente en un PC o servidor con Windows. Para Linux puede ejecutar como root el comando "dd" en el terminal. Primero identificamos el disco a clonar (dev)
dd if=/dev/sda1 of=/ruta/diskbak.raw
Aquí volcamos el disco duro de nuestro sistema a una imagen de disco en formato .RAW, donde /dev/sda1 representa el disco origen (sistema), /ruta/
diskbak.raw la ruta a donde enviaremos el disco duro resultante. (Vea más opciones del comando "dd" AQUI, AQUI y AQUI)
También puede usar pv (apt-get install pv) para mostrar el progreso
También puede usar pv (apt-get install pv) para mostrar el progreso
dd if=/dev/sda1 | pv | dd of=/ruta/diskbak.rawLuego con Oracle VirtualBox convertiremos la imagen RAW en VDI (que es el formato que maneja VirtualBox por defecto). Para esto ejecutamos en consola:
VBoxManage convertfromraw diskbak.raw --format vdi diskbak.vdi
Si al finalizar la conversión, la image n vdi resultante queda muy grande, para reducirla ejecute :
Nota: Es importante señalar que desde Windows 7, se ofrece soporte nativo para VHD.
Otra alternativa es volcar la imagen a formato .img
Y si no queremos virtualizar (omitir el Paso 2), sino migrar de un disco origen a otro destino directamente, tal cual, primero identificamos las particiones con fdisk -l, y asumiendo que origen sea /dev/sda1 y destino un disco usb externo /dev/sdb, entonces ejecutamos:
Donde if es el parámetro que indica el origen; of el destino y con bs forzamos que la copia se haga en bloques de 1 megabyte y que se escriba de igual manera. Esta forma de trabajar nos permite no sobrecargar el sistema en el proceso y seguir trabajando mientras se realiza la copia. Y finalmente sincronizamos con el Paso 3 para mantener nuestro disco actualizado .
Y si usamos entorno gráfico y tenemos poca experiencia en el manejo del terminal, afortunadamente existe una versión gráfica de este comando llamada gDiskDump, la cual hace las mismas operaciones pero con la interface GUI, como el clonado de disco, creación de imagen, etc.
VBoxManage modifyhd --compact diskbak.vdiDonde diskbak.vdi es el nombre de la imagen virtual creada (pueden elegir el que quieran)
Nota: Es importante señalar que desde Windows 7, se ofrece soporte nativo para VHD.
Otra alternativa es volcar la imagen a formato .img
dd if=/dev/sda1 of=/ruta/diskbak.imgY utilizar la herramienta VHD Tool para hacer la conversión, sin embargo ya está descontinuada, por lo que pueden reemplazarla por VHDxTool y después de la conversión, renombrar la extensión .img por .vhd
Y si no queremos virtualizar (omitir el Paso 2), sino migrar de un disco origen a otro destino directamente, tal cual, primero identificamos las particiones con fdisk -l, y asumiendo que origen sea /dev/sda1 y destino un disco usb externo /dev/sdb, entonces ejecutamos:
fdisk -l # para conocer las particiones dd if=/dev/sda1 of=/dev/sdb1 bs=1M 77853+1 registros de entrada 77853+1 registros de salida 81964312612 bytes (82GB) copiados, 6740,82 segundos, 12,0 MB/s
Y si usamos entorno gráfico y tenemos poca experiencia en el manejo del terminal, afortunadamente existe una versión gráfica de este comando llamada gDiskDump, la cual hace las mismas operaciones pero con la interface GUI, como el clonado de disco, creación de imagen, etc.
wget https://launchpad.net/gdiskdump/trunk/0.8/+download/gdiskdump_0.8-1_all.deb dpkg -i gdiskdump_0.8-1_all.debPaso 2: Montando el disco virtual (VHD)
Instalamos VirtualBox (se recomienda usar siempre la última versión) y creamos una VM con características lo más similares posibles al sistema generado en el disco virtual en formato .VHD (cantidad de memoria ram y de video, cantidad de tarjetas de red, No. de procesadores, etc) y en el paso que VirtualBox le pide "crear unidad de disco duro", seleccione el formato VHD (ver imagen del encabezado del post) y seleccione el disco virtual VHD que guardó en su dispositivo externo.
También podemos crear una VM con un disco virtual nuevo o reutilizar una VM anteriormente creada y, en ambos casos, reemplazarlo el disco virtual existente por el que acabamos de crear. En este caso saldrá error de UUID (para mayor información consulte el manual VBox).
En linux, esto se corrige con el siguiente comando, que debe ser ejecutado como root en la ubicación exacta del .vdi:
O corregir el registro de VirtualBox
Conversiones
Aunque VirtualBox soporta el formato VHD, si quiere convertirlo su disco virtual a VDI en lo que se conoce como V2V (Virtual to Virtual), use el siguiente comando
Descargue los scripts y guárdelos en cualquier lugar de su PC. Para mayor comodidad cree un enlace en "Enviar A" (Send to Menu) que contenga los dos scripts.
( %APPDATA%MicrosoftWindowsSendTo)
También podemos crear una VM con un disco virtual nuevo o reutilizar una VM anteriormente creada y, en ambos casos, reemplazarlo el disco virtual existente por el que acabamos de crear. En este caso saldrá error de UUID (para mayor información consulte el manual VBox).
En linux, esto se corrige con el siguiente comando, que debe ser ejecutado como root en la ubicación exacta del .vdi:
VBoxManage internalcommands sethduuid /pathcompleto/disco-a-cambiar-uuid.vdi # ejemplo VBoxManage internalcommands sethduuid /home/user/vm/win7.vdiY arrojará el nuevo UUID. Ejemplo:
UUID changed to: 4r2b9733-fab1-4315-9e89-324775ea7980Y en Windows es similar en dependencia donde se encuentre el .vdi. En el siguiente ejemplo ubicamos el .vdi en la unidad c, o en una carpeta:
C:\Program Files\Oracle\VirtualBox\VBoxManage.exe internalcommands sethduuid "c: \VirtualBox VMs\SERVIDOR\SERVIDOR disco-a-cambiar-uuid.vdi"o
C:\Program Files\Oracle\VirtualBox>VBoxManage.exe internalcommands sethduuid "C:\disco-a-cambiar-uuid.vdi" UUID changed to: 4r2b9733-fab1-4315-9e89-324775ea7980Si quiere conocer más sobre el cambio de UUID y de directorios de VirtualBox consulte el manual de usuario de VBox
O corregir el registro de VirtualBox
nano /home/usuario/.VirtualBox/VirtualBox.xml o nano /home/usuario/.config/VirtualBox/VirtualBox.xmlY eliminar la línea "src" de MachineRegistry correspondiente al disco anterior, para evitar el conflicto UUID. Ejemplo:
MachineEntry uuid="{a14763d0-8135-4ed8-a794-4555aa307a9d}" src="/home/user/VirtualBox VMs/7/7.vbox"/
MachineEntry uuid="{2b56dc7b-03a1-4e23-b670-217f4edb1c7a}" src="/home/user/VirtualBox VMs/android/android.vbox"/
Finalmente arranque la VM y es todo. Su sistema ya está virtualizado y funcionando. Conversiones
Aunque VirtualBox soporta el formato VHD, si quiere convertirlo su disco virtual a VDI en lo que se conoce como V2V (Virtual to Virtual), use el siguiente comando
VBoxManage clonehd --format VDI Disco.vhd Disco.vdiO utilizar el comando clonevdi, que realiza una imagen exacta de nuestro disco virtual en VDI nativo, pero con su propio UUID (también tiene versión GUI).
VBoxManage clonevdi disco_origen.vdi disco_destino.vdiOtra alternativa es tener acceso al disco duro VHD sin virtualizarlo, propuesta por el portal HowToGreek. Con esta opción podemos mantener actualizado (Paso 3) el disco virtual con los últimos cambios del sistema físico, sin necesidad de que esté corriendo en un Hipervisor, lo cual, en el caso de servidores, es muy práctico ya que agiliza la sincronización.
Descargue los scripts y guárdelos en cualquier lugar de su PC. Para mayor comodidad cree un enlace en "Enviar A" (Send to Menu) que contenga los dos scripts.
( %APPDATA%MicrosoftWindowsSendTo)
Luego nos situamos sobre el disco virtual, botón derecho y ejecutamos el script para montar o desmontar el disco duro y ya tenemos acceso a nuestro disco duro virtual desde el Explorador de Windows. y para montar o desmontar el disco virtual hay que arrastrar y soltar la imagen de disco VHD sobre el script que corresponda a lo que queremos.
PD: También puede cambiarle la extensión a estos scripts de .BAT a .CMD
Pero, si no nos gusta trabajar con scripts, siempre existe la alternativa gráfica, por ejemplo puede utilizar la herramienta Simple VHD Manager que es sencilla de usar y tiene mucho más opciones.
Paso 3: Sincronización
PD: También puede cambiarle la extensión a estos scripts de .BAT a .CMD
Pero, si no nos gusta trabajar con scripts, siempre existe la alternativa gráfica, por ejemplo puede utilizar la herramienta Simple VHD Manager que es sencilla de usar y tiene mucho más opciones.
Paso 3: Sincronización
Tener una copia de nuestro DD físico en un disco virtual no significa que sea exacta al original, ya que este se modifica constantemente. Para mantener actualizado nuestro disco físico con el virtual es necesario sincronizarlos. Existen dos app que pueden encargarse de estas labores de una manera muy efectiva.
Retrospect, es una app de backup, que a pesar de ser pago, genera scripts automatizados que comparan byte a byte origen y destino, creando copias muy fiables "en caliente". Si desea utilizarlo, puede instalarlo en un PC con Windows y creamos un script automatizado para que copie el contenido de origen y lo envíe a nuestro disco duro virtual (ya sea al disco VHD montado como una unidad de Windows o virtualizado con VirtualBox).
Para poder hacer este proceso, en el caso de sistemas Windows, hay que instalar el cliente de Retrospect en el equipo objetivo, para poderlo incluir en el script.
Desafortunadamente a la fecha Retrospect no tiene versión para Linux (Vea sección Download Restrospect) y solo cuenta con un cliente para Red Hat. Esto es una limitante si tenemos en cuenta que más del 70% de los servidores a nivel mundial trabajan con sistemas operativos GNU/Linux, Free BSD, SunOS y derivados de Unix.
La segunda alternativa es FreeFileSync; un software de sincronización multiplataforma (cross-platform file synchronization software) compatible con Linux, MAC y Windows, que sincroniza el sistema primario con el disco virtual de respaldo.
La modalidad " Sincronizar Espejo", es muy buena ya que compara y reemplaza todas las modificaciones realizadas en su sistema principal hacia el disco virtual de backup. Pero si mantiene ambos sistemas activos, se recomienda usar la opción "Bidireccional".
También puede utilizar app de sincronización "en la nube", como dropbox, copy, etc, o app tipo vnc, para mantener sincronizado el disco físico con el virtual. Recomendadas sobre todo si ambos se encuentran en ubicaciones geográficas distantes.
También puede usar el script propuesto por Jose Manuel Rojas, que usa una combinación de rsync con sshpass para respaldos remotos sincronizados con autenticación.
Paso 4: Revertir el proceso (V2P)
Para revertir el proceso, o sea convertir una máquina virtual en física (Virtual to Physical V2P), lea el Cap 8 de VirtualBox. Si usa VMWare, lea el siguiente tutorial. Para el caso de discos vmdk de vmWare a vhd de Hyper-V y viceversa puede usar la herramienta Starwind V2V converter o WinImage. También puede convertir su VM en ISO, o usar el comando de VirtualBox:
Alternativas
Con Clonezilla Live puede realizar la creación inicial del DD virtual (lea el procedimiento propuesto por IBM), o usar el comando dd bajo Linux y Unix para volcar la imagen de disco a formato .iso o .bin
El Futuro
Muchos dirán: "ya se usan los sistemas operativos y app virtualizados en la nube, por tanto no es necesario virtualizar un servidor en una memoria usb cuando lo podemos tener en producción online en internet".
Este planteamiento es acertado. De hecho hay servicios, como OpenQRM, que unifican este tipo de soluciones, sin embargo los recientes escándalos de espionaje (que no son nuevos y muchos países lo hacen) ponen en entredicho este esquema. No es que sea malo usar "la nube", sino que concentrar toda nuestra información, app y operatividad en estos "Datacenters online", es correr el riesgo de centralizar todo en manos de terceros. En la actualidad algunos bancos ya realizan transacciones entre sus clientes privilegiados usando dispositivos portables encriptados que un correo humano transporta de origen a destino, "lento pero seguro". Lo mismo sucede con empresas importantes. Ya nadie quiere usar los correos tipo hotmail, yahoo, etc, fuertemente cuestionados por estar involucrados en estos escándalos de invasión a la privacidad. Esto nos da una idea hacia donde puede dirigirse la tendencia. Consideramos que ambos sistemas coexistirán.
Recomendaciones finales:
1. Configure los parámetros de red para que se pueda ejecutar la sincronización
2. Para sistemas Windows se recomienda desfragmentar los discos duros antes de ejecutar la primera vez la generación del backup en DD virtual VHD o VDI, así como cerrar la mayor cantidad de procesos abiertos. Esto no es necesario en el Paso No 3 Sincronización.
3. Lea las recomendaciones de cómo usar Disk2vhd incluidas en el archivo help de esta utilidad, sobre la compatibilidad con sistemas operativos.
4. Tenga presente las limitaciones de migrar sistemas físicos Windows a máquinas virtuales. Para Windows Server 2008r2 y superior, se presentan problemas con SID. Lea cómo solucionarlo.
5. Si usted usa VMWare como hipervisor, puede utilizar la herramienta VDI2VMDK para exportar el disco virtual VDI a VMWare .VMDK. O viseversa VMDK2VDI
6. Puede consultar otros métodos con VirtualBox y VMWare Converter y usando Acronis con Universal Restore y True Image Echo.
7. Si va a revertir el proceso (virtual a físico) consulte los problemas comunes y tenga en cuenta que Virtual Guest Additions puede generar problemas a la hora de revertir el proces. V2P depende de muchos factores, por tanto el porcentaje de éxito depende de lo que se pretenda convertir en físico.
8. Recuerde que si usa Virtual PC como hipervisor, el tamaño máximo de disco virtual que permite es de 127 GB
9. Si su sistema virtual no inicia en su Hipervisor, verifique la opción Enable or disable IO APIC y PAE/NX. Verifique los logs de su Hipervisor. Establezca en su sistema físico la modalidad más compatible (SATA/IDE/RAID, etc) y establezcala tambien en la configuración de su hipervisor (enable IO APIC, enable 1/multiple CPU's y disable PAE/NX features (Lea el Cap 5 de VirtualBox). También verifique la configuración:
sc config processor start= disabled
sc config intelppm start= disabled
sc config p3 start= disabled
10. Para el caso de una Clonación Virtual de un servidor (P2V) que tiene corriendo en su sistema operativo una o más virtualizaciones, al convertirlo P2V, se corre el riesgo de que las virtualizaciones no arranquen. Ejecutar una virtualización dentro de otra depende de muchos factores. En teoría es posible siempre y cuando la virtualización sea bajo las mismas condiciones, arquitectura y soporte de hardware (que proporcione la máquina anfitriona versus virtual) y las extensiones vt-x tengan los privilegios y compatibilidad. Esto se debe a que los requerimientos del hardware cambian y eso afecta la nueva capa. Sin embargo existen algunos escenarios específicos en que es posible correrlas, de acuerdo a los portales MSDN y Bujarra,
Nuestra recomendación es que si lo que se pretende es hacer un P2V para luego ejecutar las virtualizaciones dentro del sistema convertido, no es recomendable por la cantidad de incompatibilidades que se pueden presentar, al punto que puede afectar la integridad de las maquinas virtuales. Aquí lo más razonable es sacar las virtualizaciones del disco (antes de hacer el P2V) y correrlas en un anfitrión físico.
Si son virtualizaciones que trabajaban dentro de una red local y el sistema convertido P2V era un servidor que las controlaba, en el nuevo anfitrión físico se pueden correr todas las VMs y redireccionar las peticiones con iptables o cualquier otro firewall.
Post Complementarios:
Sincronización Espejo
VMs FATAL: No bootable medium found! System halted
Redimensionar discos duros VM
Para poder hacer este proceso, en el caso de sistemas Windows, hay que instalar el cliente de Retrospect en el equipo objetivo, para poderlo incluir en el script.
Desafortunadamente a la fecha Retrospect no tiene versión para Linux (Vea sección Download Restrospect) y solo cuenta con un cliente para Red Hat. Esto es una limitante si tenemos en cuenta que más del 70% de los servidores a nivel mundial trabajan con sistemas operativos GNU/Linux, Free BSD, SunOS y derivados de Unix.
La segunda alternativa es FreeFileSync; un software de sincronización multiplataforma (cross-platform file synchronization software) compatible con Linux, MAC y Windows, que sincroniza el sistema primario con el disco virtual de respaldo.
La modalidad " Sincronizar Espejo", es muy buena ya que compara y reemplaza todas las modificaciones realizadas en su sistema principal hacia el disco virtual de backup. Pero si mantiene ambos sistemas activos, se recomienda usar la opción "Bidireccional".
También puede usar el script propuesto por Jose Manuel Rojas, que usa una combinación de rsync con sshpass para respaldos remotos sincronizados con autenticación.
Paso 4: Revertir el proceso (V2P)
Para revertir el proceso, o sea convertir una máquina virtual en física (Virtual to Physical V2P), lea el Cap 8 de VirtualBox. Si usa VMWare, lea el siguiente tutorial. Para el caso de discos vmdk de vmWare a vhd de Hyper-V y viceversa puede usar la herramienta Starwind V2V converter o WinImage. También puede convertir su VM en ISO, o usar el comando de VirtualBox:
VBoxManage clonehd disk.vdi output.img --format RAWOtros comandos de VirtualBox
VDI2ISO: VBoxManage clonehd –format RAW input.vdi output.iso o VBoxManage clonehd input.vdi output.iso --format RAW VDI2IMG: VBoxManage clonehd –format RAW input.vdi output.img ISO2VDI: VBoxManage convertfromraw –format VDI input.iso output.vdi IMG2VDI: VBoxManage convertfromraw –format VDI input.img output.vdi VMDK2VDI VBoxManage clonehd --format VDI input.vmdk output.vdi VDI2VMDK VBoxManage clonehd --format VMDK input.vdi output.vmdkGracias a la Clonación Virtual podemos tener dos sistemas completos (uno real y otro virtual) con el MBR incluido, y actualizándose permanentemente con sincronizado programado (remoto o en sitio). De esta manera si falla el sistema primario podemos arrancar el virtual VM, sin interrupción en los servicios... Y lo mejor de todo; ya podemos cargar nuestro servidor, PC, laptop, smarthphone, tablets o lo que sea, en una simple memoria usb pendrive, y arrancarlo en cualquier lugar del mundo. (De hecho ya podemos virtualizar Windows en una tablet con android. (Ver video y howto)) y muy pronto tener una simcard virtual; y en un futuro no lejano, prácticamente todo podrá ser virtualizado.
Alternativas
Con Clonezilla Live puede realizar la creación inicial del DD virtual (lea el procedimiento propuesto por IBM), o usar el comando dd bajo Linux y Unix para volcar la imagen de disco a formato .iso o .bin
El Futuro
Muchos dirán: "ya se usan los sistemas operativos y app virtualizados en la nube, por tanto no es necesario virtualizar un servidor en una memoria usb cuando lo podemos tener en producción online en internet".
Este planteamiento es acertado. De hecho hay servicios, como OpenQRM, que unifican este tipo de soluciones, sin embargo los recientes escándalos de espionaje (que no son nuevos y muchos países lo hacen) ponen en entredicho este esquema. No es que sea malo usar "la nube", sino que concentrar toda nuestra información, app y operatividad en estos "Datacenters online", es correr el riesgo de centralizar todo en manos de terceros. En la actualidad algunos bancos ya realizan transacciones entre sus clientes privilegiados usando dispositivos portables encriptados que un correo humano transporta de origen a destino, "lento pero seguro". Lo mismo sucede con empresas importantes. Ya nadie quiere usar los correos tipo hotmail, yahoo, etc, fuertemente cuestionados por estar involucrados en estos escándalos de invasión a la privacidad. Esto nos da una idea hacia donde puede dirigirse la tendencia. Consideramos que ambos sistemas coexistirán.
Recomendaciones finales:
1. Configure los parámetros de red para que se pueda ejecutar la sincronización
2. Para sistemas Windows se recomienda desfragmentar los discos duros antes de ejecutar la primera vez la generación del backup en DD virtual VHD o VDI, así como cerrar la mayor cantidad de procesos abiertos. Esto no es necesario en el Paso No 3 Sincronización.
3. Lea las recomendaciones de cómo usar Disk2vhd incluidas en el archivo help de esta utilidad, sobre la compatibilidad con sistemas operativos.
4. Tenga presente las limitaciones de migrar sistemas físicos Windows a máquinas virtuales. Para Windows Server 2008r2 y superior, se presentan problemas con SID. Lea cómo solucionarlo.
5. Si usted usa VMWare como hipervisor, puede utilizar la herramienta VDI2VMDK para exportar el disco virtual VDI a VMWare .VMDK. O viseversa VMDK2VDI
6. Puede consultar otros métodos con VirtualBox y VMWare Converter y usando Acronis con Universal Restore y True Image Echo.
7. Si va a revertir el proceso (virtual a físico) consulte los problemas comunes y tenga en cuenta que Virtual Guest Additions puede generar problemas a la hora de revertir el proces. V2P depende de muchos factores, por tanto el porcentaje de éxito depende de lo que se pretenda convertir en físico.
8. Recuerde que si usa Virtual PC como hipervisor, el tamaño máximo de disco virtual que permite es de 127 GB
9. Si su sistema virtual no inicia en su Hipervisor, verifique la opción Enable or disable IO APIC y PAE/NX. Verifique los logs de su Hipervisor. Establezca en su sistema físico la modalidad más compatible (SATA/IDE/RAID, etc) y establezcala tambien en la configuración de su hipervisor (enable IO APIC, enable 1/multiple CPU's y disable PAE/NX features (Lea el Cap 5 de VirtualBox). También verifique la configuración:
sc config processor start= disabled
sc config intelppm start= disabled
sc config p3 start= disabled
10. Para el caso de una Clonación Virtual de un servidor (P2V) que tiene corriendo en su sistema operativo una o más virtualizaciones, al convertirlo P2V, se corre el riesgo de que las virtualizaciones no arranquen. Ejecutar una virtualización dentro de otra depende de muchos factores. En teoría es posible siempre y cuando la virtualización sea bajo las mismas condiciones, arquitectura y soporte de hardware (que proporcione la máquina anfitriona versus virtual) y las extensiones vt-x tengan los privilegios y compatibilidad. Esto se debe a que los requerimientos del hardware cambian y eso afecta la nueva capa. Sin embargo existen algunos escenarios específicos en que es posible correrlas, de acuerdo a los portales MSDN y Bujarra,
Nuestra recomendación es que si lo que se pretende es hacer un P2V para luego ejecutar las virtualizaciones dentro del sistema convertido, no es recomendable por la cantidad de incompatibilidades que se pueden presentar, al punto que puede afectar la integridad de las maquinas virtuales. Aquí lo más razonable es sacar las virtualizaciones del disco (antes de hacer el P2V) y correrlas en un anfitrión físico.
Si son virtualizaciones que trabajaban dentro de una red local y el sistema convertido P2V era un servidor que las controlaba, en el nuevo anfitrión físico se pueden correr todas las VMs y redireccionar las peticiones con iptables o cualquier otro firewall.
Post Complementarios:
Sincronización Espejo
VMs FATAL: No bootable medium found! System halted
Redimensionar discos duros VM
Post a Comment