Software para Conversión de Máquinas virtuales

En esta ocasión voy a hablar también de tecnologías de virtualización, pero  enfocándome en aquellos programas que nos facilitan un poco la vida cuando queremos migrar un entorno VMWare a otro Hyper-V. En concreto voy a tratar dos que he empleado no hace mucho: Microsoft Virtual Machine Converter y  StardWind V2V Converter.

Cuando realizamos procesos de conversión de máquinas virtuales debemos tener en cuenta que las arquitecturas de origen (VMWare) y destino (Hyper-V) van a ser diferentes y por ello,  tanto los ficheros de configuración y los checkpoint no se podrán migrar. Lo que podremos convertir son los discos duros (por ejemplo los ficheros vmdk y flat.vmdk en el caso de VMWare). La información sobre la configuración de la máquina virtual VMWare la podremos obtener del fichero con extensión vmsd.

Dicho todo esto voy a comenzar por el software Microsoft Virtual Machine Converter en su versión 3.0. Este software nos va a permitir convertir máquinas tanto de físico a virtual, como de virtual a virtual. Esta aplicación dispone de un asistente para convertir máquinas de físico a virtual y también de VMWare a Hyper-V. En esta segunda opción la conversión de máquinas virtuales las hace conectándose a un servidor ESX, y o bien importarlas en Azure o a un servidor de Hyper-V.

También disponde una línea de comandos, que nos va a ser útil si no lo hacemos conectándonos a un servidor VMWare.Para poder emplear la línea de comandos, abrimos powershell y cargamos el módulo que viene en la carpeta de instalación, tal y como figura en la imagen, ejecutando el comando Import-Module “C:Program FilesMicrosoft Virtual Machine ConverterMvmcCmdlet.psd1”

MVMCcommand01

Este módulo permite cargar todos los comandos de conversión del programa. Como lo que vamos a hacer es convertir un disco duro emplearemos el comando  ConvertTo-MvmcVirtualHardDisk

image

La sintaxis del comando es la siguiente:

CovertTo-MvmcVirtualHardDisk –SourceLiteralPath “ruta-origen” –DestinationLiteralPath “ruta-destino” –VhdType DynamicHardDisk | FixedHardDisk –VhdFormat Vhd | Vhdx

Cabe comentar, que hay algunos parámetros que se pueden omitir, así, para el origen y destino podremos emplear símplemente la ruta; y si omitimos el tipo de disco o el formato tomará por defecto que el disco duro es dinámico, o si no le hemos indicado el formato, entenderá que es vhdx.

MVMCcommand03

Otro software que nos puede ayudar en la  conversión entre formatos virtuales es StardWind V2V Conveter. Este software, a diferencia del anterior nos va a permitir convertir desde VMWare y  desde Hyper-V. El programa consta de un asistente  que nos guiará paso a paso en todo el proceso.

StardWind01

Nos permite seleccionar el disco de origen, dando información sobre el archivo cargado en la parte inferior.

StardWind02

A diferencia del software anterior nos permite convertir desde VMWare a Hyper-V y viceversa, aunque de Hyper-V solo reconoce discos vhd.

StardWind04

Una vez elegido el formato nos pide que seleccionemos la ruta de destino.

StardWind05

Y por último comienza el proceso de conversión.

StardWind06

Cabe destacar que aunque ambos software pueden realizar la misma tarea debemos ver cuál se adecúa a cada caso, ya que cada uno tiene sus ventajas e inconvenientes.

¡Hasta la próxima!

PowerShell utilities series: ls / Get-ChildItem a color

No se puede entender el día a día de un administrador de sistemas sin scripting y línea de comandos, bien sea en bash desde UNIX y derivados o PowerShell para sistemas Windows; algo que ya nos es muy familiar en Plain Concepts. Con esta entrada inicio una serie de artículos dedicados a contar curiosidades y pequeñas utilidades de PowerShell, que tienen como finalidad hacer nuestra vida más fácil incrementando la experiencia de usuario con ella.

No es ningún secreto que muchos de los potenciales administradores de sistemas Windows vienen o tiene relación también con UNIX, por lo que Microsoft se ha preocupado de facilitar la transición de un sistema a otro. Para ello, PowerShell dispone de alias de muchas de sus funciones que permiten que los cmdlets se presenten en forma de formato UNIX, por ejemplo:

Alias utilizable en PowerShell Cmdlet que en realidad ejecuta
ls Get-ChildItem
cat Get-Content
grep Select-String
wc Measure-Object
time Measure-Command
find Find-ChildItem
man Get-Help
cp Copy-Item
mv Move-Item
rm Remove-Item
cls Clear-Host
echo Write-Output

Sin embargo, una de las cosas que más echo de menos de una consola UNIX es su capacidad de mostrar los archivos de un directorio por colores en función de su tipo, a través de la orden ls –color.  Esto se puede ver en esta salida de ejemplo:

image

En cambio el resultado estándar de imprimir los contenidos de un directorio en PowerShell es el siguiente:

image

¿Verdad que sería estupendo si pudiéramos hacer que la PowerShell también tuviera su propio ls –color? Esto es justo lo que vamos a hacer ahora.

Consiguiendo el LS a color

Indagando por Internet di con un excelente script en GitHub firmado por un tal Tojo2000. Podéis ver y descargar el script desde aquí. El script daba buen resultado, pero había un par de cosas que echaba en falta frente al ls –color  de UNIX:

  • Los colores de los tipos de archivo no coincidían.
  • Los enlaces simbólicos y enlaces duros del sistema de archivos NTFS no se mostraban en el clásico color celeste.

Lo bueno del scripting de PowerShell es que por definicion es Open Source, así que me lancé a hacer unas pequeñas modificaciones para que cumpliera con mis premisas. El resultado lo podéis ver a continuación:

El funcionamiento del script no entraña ningún misterio, aunque debo decir que es ingenioso. Básicamente utiliza expresiones regulares para identificar las extensiones de archivo de los elementos listados, para después llamar a Get-ChildItem cuya salida se procesa a través de un pipe donde se evalúa línea a línea de qué color debe pintarse en pantalla.

Básicamente podéis ver como se han cambiado los colores a la vez que se han agregado nuevas extensiones de archivo y además tenemos la siguiente diferencia:

Este if  nos indicará si el archivo a listar es un ReparsePoint, que nos viene a decir si es un enlace en el sistema de archivos NTFS.

Una vez generado el script sólo tenemos que llamarlo para disponer de la orden Get-ChildItemColor. Sin embargo, eso no bastará para sustituir al ls y además, es engorro tener que estar cargando continuamente el archivo al cargar la consola. Por ello nos vamos a construir un sencillo instalador.

Los Profile de PowerShell

Un Profile de PowerShell no es más que un script que se ejecuta automáticamente cada vez que se arranca la línea de comandos. En función del ámbito de aplicación de dicho script (usuario actual, toda la máquina, etc…) este se puede ubicar en múltiples lugares. Por ejemplo: el $profile de All Users se ejecutará independientemente de quien sea el usuario que ha iniciado la consola de PowerShell.

Hay nada más y nada menos que 6 profile distintos de PowerShell:

Aplicación Ruta
Current User, Current Host – console $Home[My ]DocumentsWindowsPowerShellProfile.ps1
Current User, All Hosts $Home[My ]DocumentsProfile.ps1
All Users, Current Host – console $PsHomeMicrosoft.PowerShell_profile.ps1
All Users, All Hosts $PsHomeProfile.ps1
Current user, Current Host – ISE $Home[My ]DocumentsWindowsPowerShellMicrosoft.P owerShellISE_profile.ps1
All users, Current Host – ISE $PsHomeMicrosoft.PowerShellISE_profile.ps1

Nosotros vamos a trabajar con el perfil de Current User. Hay mucha más información sobre los profiles en este post del blog de Hey, Scripting Guy!

El instalador de scripts de PowerShell

Para que el uso de nuestro nuevo ls a color sea transparente, podemos hacernos un pequeño instalador en la propia PowerShell que nos lo instale en nuestro Profile personal y se autoejecute cada vez que abramos una sesión. El instalador consta de los siguientes archivos:

  • Get-ChildItemColor.ps1. El archivo que contiene el script en cuestión.
  • Get-ChildItemColor_profile.ps1. Contiene el pequeño script que agregaremos a nuestro perfil personal.
  • Install-ChildItemColor.ps1. El script que se encarga de copiar los archivos e iniciar la instalación.

Veamos los dedicados a temas de instalación:

Este script no tiene ningún misterio. En primer lugar hacemos dot sourcing del script en cuestión para que este cargue y después hacermos override de los alias por defecto de ls y la que están incluidos por defecto en PowerShell.

Vayamos al siguiente script:

Este script:

  1. Identifica cuál debería ser la ruta donde se encuentra el profile de CurrentUser, y en caso de no encontrarla creará la carpeta por nosotros.
  2. Copia el archivo Get-ChildItemColor a la carpeta del profile.
  3. Agrega el contenido de Get-ChildItemColor_profile.ps1 a Microsoft.PowerShell_profile.ps1.

Con esto dejamos el script listo para ejecutarse automáticamente cada vez que abramos nuestra PowerShell y el resultado será el siguiente:

image

Os dejo agregados a este post un paquete con los 3 archivos para que lo podáis instalar con sólo ejecutar Install-Get-ChildItemColor.ps1.

Happy scripting!

Descarga: Get-ChildItemColor.zip

Interferencias Wifi

El ritmo de trabajo y vida actual ha enfatizado el uso de tecnologías que nos permiten realizar nuestro trabajo o disfrutar de nuestro ocio con más libertad y comodidad. Todo esto ha sido gracias al desarrollo de las tecnologías inlámbricas. Pero, debido al uso indiscriminado de estas tecnologías en todo tipo de aparatos y al ancho del espectro empleado (que es limitado) podemos encontrarnos con diversos problemas.  Este es el caso de las redes Wifi. Entendamos un poco el asunto. El especto radioelectrico compone un amplio abanico de frecuencias, pero de ellas solamente empleamos para las comunicaciones Wifi la banda de los 2,4GHz (rango de microondas) y desde hace unos años (debido a a que esa frecuencia se liberalizó) la banda de los 5 GHz.  Todo esto se encuentra englobado dentro de la especificación 802.11n.

La banda de los 2,4 GHz es la que normalmente utilizan nuestros aparatos, ya que hay muchos que no soportan otra banda y es la empleada en muchas de las especificaciones anteriores (salvo la 802.11a).  Esta banda, a su vez se subdivide en distintos canales, normalmente 14 (en España).  Cada canal tiene un ancho de 22 Mhz, y entre cada canal hay una separación de 5 MHz; pero claro está para que no interfieran uno con otro debe haber una separación mayor al ancho de banda. Esto hace que para que no interfieran entre sí, tenga que haber una separación de 5 canales. De ahí que los canales empleados normalmente sean el 1, el 6 y el 11. En cuanto a la otra banda la de los 5 GHz presenta ciertas limitaciones ya que tanto la potencia como algunos de sus canles deben estar regulados para no provocar interferencias con las comunicaciones rádar y satélite. 

Veámoslo con un ejemplo práctico: Hemos empleado la red infraestructura de Plain Concepts como ejemplo. Como podéis observar en la imagen inferior, nuestra red se encuentra en el canal 11; en dicho canal se encuentran operando muchas otras redes, Este efecto de compartición del mismo canal se suele llamar interferencia co-canal y se da cuando hay una coexistencia de redes operando en el mismo canal, nuestro caso 8, al compartir el canal la velocidad de transmisión se ve reducida ya quese tienen que establecer turnos para emplearlo.

plain11-pub

Veamos qué pasa si cambiamos nuestro punto de acceso al canal 4. En este caso vemos que se produce un efecto algo distinto, si bien no hay ninguna señal que esté emitiendo exactamente en el mismo canal, podemos apreciar que se produce un “solapamiento” con otras señales, en concreto hay en total 12 que tanto por la parte superior como inferior están interfiriendo. Al contrario que pasa con el caso anterior, en el cual se establecían turnos y no había ruido como tal, este caso provoca colisiones y que los datos no se reciban correctamente.  Por todo ello, es preferible que haya interferencia cocanal a un solapamiento en las frecuencias de transmisión,  así a la hora de elegir un canal será preferible que nuestro AP elija los estándar (1, 6, 11).

channel4-2-public

Otro dato a tener en cuenta a la hora de establecer la configururación de nuestro punto de acceso es la posibilidad de cambiar de canal. Así, en algunas configuraciones de  AP ofrecen la posiblidad de cambiar automáticamente el canal a otro menos saturado, que bien parece una buena idea esto va a provocar que los clientes wifi se tengan que desasociar y volver a asociar, lo que puede provocar cortes del servicio.

Como apunte final,  quería indicar que el fenómeno de las interferencias muchas veces no es posible evitarlo, pero se pueden minimizar eligiendo canales estándar que estén menos saturados y en la medida de lo posible emplear la frecuencia de 5GHz  para aquellos dispositivos que lo soporten.

Aging y Scavenging en DNS

Los equipos con Windows permiten actualizar dinámicamente su registro A en el servidor DNS local al que consultan, permitiendo que los administradores tengamos una visión y control de los equipos que están conectados a nuestra red, así como tener resolución DNS de los equipos cliente de manera automática. Sin embargo, si el registro no se elimina correctamente cuando los equipos salen de la red, se quedan como registros obsoletos, lo que puede darnos varios quebraderos de cabeza:

  • Si un número elevado de registros obsoletos permanece en las zonas, pueden ocupar espacio en disco del servidor y provocar transferencias de zona innecesariamente largas.
  • Los servidores DNS que cargan zonas que contienen registros obsoletos pueden usar información no actualizada para responder consultas de clientes, lo que puede hacer que los clientes experimenten problemas de resolución de nombres en la red.
  • La acumulación de registros obsoletos en el servidor DNS puede reducir su rendimiento y capacidad de respuesta.
  • En algunos casos, la presencia de un registro obsoleto en una zona puede evitar que otro equipo o dispositivo use un nombre de dominio DNS.

Es por eso que los servidores DNS de Microsoft cuentan con varios mecanismos que permitan el borrado de estos registros obsoletos. Al final todo gira en torno a 3 conceptos: marca de tiempo en los registros (timestamp), envejecimiento (aging) y borrado de los considerados obsoletos (scavenging).

Cuando te pones a jugar con estos valores y con el miedo a que se borren registros que realmente no están obsoletos, con el paso del tiempo hemos visto muchas dudas que pretendemos resolver con este “Preguntas y respuestas frecuentes”:

1. El valor de TimeStamp (Marca de Tiempo) ¿indica la hora y la fecha en la cual el registro fue creado?

Cuando una máquina cliente utiliza actualizaciones dinámicas para registrar su entrada en DNS, el timestamp se crea/modifica en los siguientes casos:

  1. Cuando el registro es creado por primera vez por un cliente que no existía en la zona, se considera una “Actualización, y el timestamp es establecido con la fecha y la hora del sistema en ese momento.

  2. Si el cliente tiene un registro ya creado en DNS y cambia su dirección IP, se considera una “Actualización, y se actualiza el timestamp con la fecha y la hora del sistema en ese momento.

  3. Si el cliente tiene un registro ya creado en DNS y mantiene la misma dirección IP, se considera un “Refresco”, y la actualización del timestamp dependerá de la configuración de la zona (lo veremos más adelante).

  4. Si el DHCP es el propietario de los registros, y está configurado dentro del grupo DnsProxyUpdate para la creación de los registros en DNS, la actualización de los timestamp los llevará a cabo cuando renueve una concesión IP.

    Una vez el timestamp se ha establecido para un registro, este valor es replicado a todos los servidores que mantienen la zona DNS donde se encuentra dicho registro. Para ello el Aging/Scavenging debe estar habilitado en la zona.

    2. Si se configura el Scavenging con un valor de 7 días y no se reinicia el cliente en 7 días, ¿el registro correspondiente es borrado?

    Creo que lo mejor para entender la respuesta a esta pregunta es resumir como funciona el proceso de Aging y Scavenging y los tiempos que se manejan en cada caso.

    Antes de que un servidor DNS vaya a comprobar si un registro es susceptible de ser eliminado, deberemos habilitar Aging/Scavenging en la zona donde se encuentre el mismo.

    Para acceder a la configuración de Aging/Scavenging para una zona deberemos hacer click derecho sobre la misma, seleccionar “Propiedades”, pestaña “General” y pulsamos en el botón “Aging”.

    image

    Cuando estableces por primera vez Aging/Scavenging para una zona, la fecha y la hora que vemos en la parte inferior de la imagen se establece con la fecha y hora actual del sistema (la hora se redondea hacia abajo) + el valor de refresco “Refresh interval”.

    Ese valor indica el primer momento en el que la zona es susceptible de poder ejecutar el servicio de Scavenging (borrado de registros obsoletos).

    Una vez que se ejecute el servicio, comprobará los registros para ver cuales son susceptibles de borrado, esto es, los que hayan pasado sin actualizarse durante su intervalo de No-Refresco + Refresco.

    Refresh and No-Refresh intervals

    Estos valores son los que indican los tiempos de espera hasta que el servicio de Scavenging pueda actuar. Ambos deben expirar antes de que un registro pueda ser borrado.

    El valor de No-Refresco es un periodo de tiempo durante el cual un registro DNS no puede ser “refrescado”. Como vimos antes, consideramos un “refresco” a una actualización dinámica donde no existe un cambio de IP para el registro, sino que simplemente se actualiza el Timestamp. Si un cliente cambia su IP, es  considerada una “actualización”, la cual está exenta del tiempo de No-Refresco, y su entrada será actualizada siempre.

    Este intervalo de No-Refresco tiene como propósito reducir el tráfico de replicación entre los servidores DNS en los casos en los que el cliente no ha cambiado su configuración. Un cambio en un registro es un cambio que sí que debe ser replicado.

    Una vez que el Timestamp del registro + el intervalo de No-Refresco acaban, entramos en el Intervalo de Refresco. Este intervalo es en el cual están permitidos los “refrescos”, es decir, cuando se permite que un registro actualice su Timestamp.

    Durante este intervalo es cuando los clientes deben actualizar su Timestamp para “demostrar” que siguen activos. Una vez se actualice, será replicado al resto de servidores DNS que mantienen la zona, y ese registro volverá a entrar en el intervalo de No-Refresco.

    Si por cualquier razón, un cliente no consigue actualizar dinámicamente su Timestamp durante el intervalo de refresco, pasa a ser elegible de ser eliminado por el Scavenging.

    Nota: Debemos establecer los valores para los intervalos de No-Refresco y de Refresco de manera que estemos seguros de que les estamos dando tiempo suficiente a los clientes a realizar varios intentos de registro o actualización durante el intervalo de Refresco.

    Opciones de Scavenging en el Servidor

    Ahora mismo ya tenemos tanto los registros (con el Timestamp) como la zona (con lo que hemos hecho en el paso anterior) preparadas para poder ser ejecutado el proceso de Scavenging.

    La configuración del servicio de Scavenging a nivel de Servidor se establece haciendo clic derecho en el servidor dentro de la consola DNS, seleccionando Propiedades, pestaña Avanzada y habilitando “Enable automatic scavenging of stale records”.

    image

    El periodo que establecemos aquí, es el intervalo que va a esperar el servicio de Scavenging para ejecutarse en cada ciclo. Cuando este servicio se ejecuta, va a registrar un Evento 2501 que indica cuantos registros van a ser eliminados. Un Evento 2502 va a ser registrado cuando no haya ningún registro que eliminar.

    Sólo es necesario tener configurado Scavenging en un servidor, dado que los datos de la zona DNS serán replicados a todos los servidores que mantienen dicha zona.

    Aunque podríamos establecer el servicio de Scavenging en cualquier servidor que mantenga la zona, mi recomendación es hacerlo sólo en uno. La razón es que si el servidor falla al realizar el Scavenging, el problema no es demasiado grave, y además tendremos un único sitio donde comprobar qué es lo que ha fallado.

    Podemos saber cuando el servidor va a realizar el próximo proceso de Scavenging, observando los últimos eventos 2501 o 2502 y añadiendo el periodo de Scavenging que hayamos establecido en el paso anterior.

    Podemos también forzar manualmente la ejecución del servicio de Scavenging haciendo clic derecho en el servidor y seleccionando la opción “Scavenge Stale Resource Records”.

    Una vez tengamos todos los parámetros configurados (Actualizaciones dinámicas habilitadas en la zona, Aging/Scavenging en la zona, Scavenging en el servidor, etc), el servicio de Scavenging, que se ejecutará con una periodicidad que hemos establecido en el paso anterior, comprobará el Timestamp de cada registro en las zonas que tengan habilitado Aging/Scavenging y comparará si la fecha/hora actual es superior al valor del Timestamp + No-Refresh + Refresh, y si es así, eliminará el registro.

    image

    3. ¿Es necesario reiniciar el cliente cada 7 días para que actualice su registro en DNS?

    No, por defecto, los clientes Windows intentarán realizar una actualización dinámica de su registro DNS cada 24 horas.

    4. Si se añade un registro en DNS de manera manual, cual es el valor del Timestamp y cuál es el comportamiento del Scavenging en este caso?

    Cuando un registro en DNS es añadido de manera manual, el Timestamp se establece como “estático” lo que supone un valor de 0. En este caso el servicio de Scavenging ignorará estos registros y no los eliminará.

    5. Buenas prácticas

    Fase de configuración:

    1. Debemos asegurarnos de que el servicio de Scavenging está deshabilitado a nivel de servidor en todos los DNS.

    2. Habilitamos Aging/Scavenging en las zonas en las que queramos tener esta funcionalidad. Estableceremos los intervalos de No-Refresco y Refresco como vienen por defecto (7 días). La recomendación es que estos valores sean inferiores al tiempo de concesión del DHCP (en nuestro caso de 8 días) para evitar resultados inconsistentes.

    3. Sumamos la fecha actual más el intervalo de No-Refresco más el intervalo de Refresco, y volvemos en esa fecha a revisar si los Timestamp de los clientes han sido actualizados correctamente.

    Fase de saneamiento:

    Comprobamos si existe algún registro que tenga su Timestamp anterior a los tiempos de No-Refresco+Refresco (no se ha actualizado durante el tiempo que hemos esperado). Si existe alguno, tenemos que revisar si se trata de un cliente activo ya que puede haber fallado la actualización dinámica y debemos corregirlo antes de continuar. Aunque sea costoso, es importante realizar una comprobación exhaustiva en este momento.

    No debemos continuar a menos que podamos explicar los registros obsoletos, ya que serán eliminados en la siguiente fase.

    Fase de activación:

    El paso final es habilitar Scavenging a nivel de servidor. Como vimos antes es recomendable hacerlo únicamente en un servidor DNS.

    6. Podemos encontrar mucha más información en los siguientes artículos:

    Using DNS Aging and Scavenging

    http://technet.microsoft.com/en-us/library/cc757041(WS.10).aspx

    Don’t be afraid of DNS Scavenging. Just be patient.

    http://blogs.technet.com/b/networking/archive/2008/03/19/don-t-be-afraid-of-dns-scavenging-just-be-patient.aspx

    Using DNS servers with DHCP

    http://technet.microsoft.com/en-us/library/cc787034(WS.10).aspx

    Integrating DNS with DHCP

    http://technet.microsoft.com/es-es/library/cc757867(WS.10).aspx

    Espero que os sea de utilidad.

    ¡Hasta la próxima!