Inicio

Microsoft, su tecnología y yo

Distribuir contenido
El Blog de David Cervigón (Microsoft)
URL: http://blogs.technet.com/b/davidcervigon/
Actualizado: hace 1 hora 41 mins

Información sobre funcionalidades de Windows Server 8

Mar, 13/12/2011 - 10:42

Hola

La cantidad de novedades y funcionalidades que se van a introducir en Windows Server 8 hacen complicado resumirlas en un solo post. Para aquellos de vosotros que estéis interesados, os recomiendo empezar por el Whitepaper o por los posts que se publican en los blogs de los grupos de producto y ampliar información en las presentaciones y videos del evento Build que se hizo en Septiembre:

Como veis hay sustanciales mejoras y novedades en las capas de almacenamiento y red, diseñadas obviamente para facilitar la introducción de nuevas funcionalidades en las capas de gestión y virtualización y alta disponibilidad. Algunas de ellas ya están presentes en los binarios de la Preview, disponible para subscriptores a MSDN

Saludos

David Cervigón

Categorías: Virtualización

E-Book gratuito: Understanding Microsoft Virtualization Solutions, Second Edition

Dom, 20/11/2011 - 20:24

Hola

Me entero por este post de Miguel que se ha actualizado este e-book a las versiones correspondientes a Windows Server 2008 R2, y que se puede descargar gratuitamente desde aquí:

Echándole un vistazo por encima se me ha ocurrido coger los capítulos del índice, y enlazarlos con algunos contenidos de la TechNet Library, TechCenters y “landing pages”, siempre más completos y actualizados:

 

Saludos

David Cervigón

Categorías: Virtualización

Exportar e Importar solamente la configuración de una máquina virtual

Sáb, 19/11/2011 - 21:21

Hola

El proceso de exportación de una máquina virtual consiste en el “empaquetado” de todos los ficheros que conforman una máquina virtual y su copia a un cierto path dentro del host en el que se lleva a cabo la acción. El proceso, que debe llevarse a cabo con la máquina detenida, no la modifica ni la destruye, y tiene por objeto el poder trasladar la máquina, manual o automatizadamente, a otro host para recuperarla posteriormente en caso de, por ejemplo, haber querido prescindir de ella o ante la necesidad de reinstalar un host. Este mecanismo de exportación/importación que podemos llevar a cabo en el Hyper-V Manager está detrás de algunas acciones que están disponibles en System Center Virtual Machine Manager, como llevarnos la máquina virtual a la librería o mover máquinas entre hosts stand-alone (no clusterizados). En ellos, la máquina virtual se exporta, se copia a una carpeta compartida de la librería o al host destino donde se importará, y por último se borra la máquina virtual en el origen.

En la primera versión de Hyper-V existía una casilla para exportar únicamente la configuración de la máquina virtual. La idea era poder importar la VM posteriormente, asumiendo que los discos virtuales, snapshots y ficheros de estado no se han visto alterados en el almacenamiento. Esta es la alternativa purista y soportada a registrar a mano en Hyper-V una máquina virtual a partir de su fichero de configuración, y lo que debería estar detrás de cualquier estrategia de recuperación de desastres que emprendamos en base a replicas del almacenamiento (técnicas de backup/restore aparte, o mejor dicho, además)

En Hyper-V R2 e Hyper-V R2 SP1 esa opción desapareció de la interfaz gráfica, quedándonos como alternativa el hacerlo desde programación o scripting. Aquí tenéis la información más relevante al respecto:

Las APIs

Aunque esto está bastante bien explicado en los enlaces segundo y último de los mencionados arriba, vamos a hacer un pequeño resumen. Los métodos de exportación e importación están definidos en la clase Msvm_VirtualSystemManagementService como ExportVirtualSystemEx e ImportVirtualSystemEx respectivamente. ExportVirtualSystemEx utiliza como parámetro una instancia de la clase Msvm_VirtualSystemExportSettingData para representar a la máquina virtual que se quiere exportar, mientras que ImportVirtualSystemEx utiliza como parámetro una instancia de la clase Msvm_VirtualSystemImportSettingData, que se obtiene mediante una llamada al método GetVirtualSystemImportSettingData. Si miramos la definición de las clases, observaremos que la correspondiente a la importación es más rica en posibilidades de la de exportación:

class Msvm_VirtualSystemExportSettingData : CIM_SettingData
{
  string  Description;
  string  Caption;
  string  InstanceID;
  string  ElementName;
  boolean CopyVmStorage;
  boolean CopyVmRuntimeInformation;
  boolean CreateVmExportSubdirectory;
  uint8   CopySnapshotConfiguration;
  string  SnapshotVirtualSystem;
};

Es decir, que al exportar podemos decir si queremos copiar los VHDs, si queremos crear una subcarpeta en el path indicado para la exportación con el nombre de la VM, si queremos guardar su estado de ejecución y si queremos almacenar también la información de snapshots. Poniendo estos valores a True o False podemos controlar que parte de la VM queremos llevarnos al directorio de exportación. Exportar solo la configuración de la VM supone, de entrada, poner a CopyVmStorage = False

Sin embargo, lo anterior tiene un efecto colateral. Al generar el .exp, y pese a que almacenamos los paths originales de los VHDs, no los seguimos considerando como válidos, ya que no tenemos la certeza de que al importar sigan en el mismo sitio. Lo mismo sucede con las snapshots y con los las conexiones a los switches virtuales. Manejaremos esa situación en la clase que gobierna el proceso de importación:

class Msvm_VirtualSystemImportSettingData : CIM_SettingData
{
  string  Description;
  string  Caption;
  string  InstanceID;
  string  ElementName;
  boolean GenerateNewId;
  boolean CreateCopy;
  string  Name;
  string  SourceVmDataRoot;
  string  SourceSnapshotDataRoot;
  string  SourceVhdDataRoot;
  string  TargetVmDataRoot;
  string  TargetSnapshotDataRoot;
  string  TargetVhdDataRoot;
  string  SecurityScope;
  string  CurrentResourcePaths[];
  string  SourceResourcePaths[];
  string  TargetResourcePaths[];
  string  SourceNetworkConnections[];
  string  TargetNetworkConnections[];
};

La clave esta en manejar los parámetros CreateCopy, Current*, Source* y Target* en función del significado que tienen cada uno, que podéis encontrar en los enlaces de arriba. Como vemos, algunos de ellos son arrays, donde se almacenan todos los paths de todos los VHDs que puede tener la máquina virtual. en función de la situación a manejar y de nuestras intenciones deberemos de manejarlos de manera acorde. Pero de entrada, pensemos que los paths que dejamos en el .exp al exportar sin copiar los VHDs se encuentran almacenados en SourceResourcePaths

Hasta aquí un resumen de la teoría. Deberíamos de haber dejado claro que exportar es fácil, e importar tiene sus consideraciones, sobre todo si las letras de unidad/paths de los VHDs y los nombres de los switches van a cambiar. Aquí reside la dificultad, pero también abre un buen abanico de posibilidades

Script para Exportar solo la configuración de la máquina virtual en Powershell

Para evitar que mi compañero Ben me acuse de plagio, y porque dado que todo System Center maneja mejor Powershell que vbscript, vamos a ver un ejemplo para exportar solamente la configuración de una máquina virtual en powershell. Simplemente usamos como parámetros el nombre de la máquina virtual y el path donde crearemos una subcarpeta con dicho nombre para almacenar la información de exportación, sin los VHDs. En amarillo lo importante:

# ExportVMConfig.ps1
# Usage: ./ExportVMConfig.ps1 <VMName> <Path to store export dir>
# Example: ./ExportVMConfig.ps1 "Test" "d:\vmexports"

param([parameter(Mandatory=$TRUE,ValueFromPipeline=$TRUE)] $VMName, [parameter(Mandatory=$TRUE,ValueFromPipeline=$TRUE)] $expDir)
 
# Get VM, VMMS  & Export Settings Objects

$ns = 'root\virtualization'
$vmms = gwmi -n $ns Msvm_VirtualSystemManagementService
$vm = gwmi -n $ns Msvm_ComputerSystem | ?{$_.ElementName -eq $VMName}
$exp = @($vm.GetRelated('Msvm_VirtualSystemExportSettingData'))[0]
 
# Don't Export VHDs & saved state data. Create a folder for VM's export data
 
$exp.CopyVmStorage = $false
$exp.CopyVmRuntimeInformation = $false
$exp.CreateVmExportSubdirectory = $true

#Perform Export
 
$out = $vmms.ExportVirtualSystemEx($vm.Path.Path, $expDir, $exp.GetText(1))
 
#Perform Job handling if necessary
 
if ($out.ReturnValue -eq 4096){
    $task = [Wmi]$out.Job;
    while($task.JobState -eq 3 -or $task.JobState -eq 4){
        $task.Get();
        sleep 1;
        }
    if ($task.JobState -ne 7){
        "Error exporting VM " + $task.ErrorDescription;
        }            
    else {
        "Export completed successfully..."
        }
    }
elseif ($out.ReturnValue -ne 0) {
    "Export failed with error : " + $out.ReturnValue;
    }
else {
    "Export completed successfully..."
    }

Si estamos haciendo esto como parte de una estrategia de recuperación ante desastres, ni que decir tiene que lo siguiente es poner ese path de exportación a buen recaudo, tal y como estaremos haciendo con los datastores que almacenan los VHDs. Generalmente esto se hace en base a alguna tecnología de replicación de almacenamiento, porque para copiar los contenidos de la VM a través e la red, lo mejor será usar la vía de la copia de seguridad en base a la tecnología VSS.

Script para Importar solo la configuración de la máquina virtual en Powershell

Para importar la máquina virtual, debemos especificar lógicamente el path donde reside el fichero con la información, es decir. el .exp. Es muy importante darse cuenta de que, si no se usa el parámetro CreateCopy, y en este caso no lo podemos utilizar ya que no tenemos VHDs que copiar, la máquina virtual pasa a residir en ese mismo path, y además el .exp desaparece en favor del .xml resultante. Esto tiene dos efectos. Que no podemos volver a usar la información exportada, y que la máquina virtual se queda en un path que seguramente nosotros considerábamos temporal. La idea es copiar la información de exportación “cerca” de donde residan los VHDs, de manera que todos los componentes de la máquina virtual queden lo mas ordenados posibles

Así es que lo que vamos a usar como parámetros va a ser el nombre de la VM, el path a donde residen los ficheros de exportación y el path a donde queremos copiarlos. La importación se realizará realmente desde este último, que debería de coincidir con el path original que tenía la máquina virtual exportada. Cualquier cambio en esta lógica no debería ser un gran problema, como tampoco una manipulación más personalizada de los paths. Esto quizás merecería el desarrollo de una interfaz gráfica con un explorador de ficheros. Ahí dejo la idea)

# ImportMConfig.ps1
# Usage: ./ImportVMConfig.ps1 <VMName> <Path to export dir> <path to place VM Configuration Files>
# Example: ./ImportVMConfig.ps1 "Test" "d:\vmexports" "D:\VirtualMachines"

param([parameter(Mandatory=$TRUE,ValueFromPipeline=$TRUE)] $VMName, [parameter(Mandatory=$TRUE,ValueFromPipeline=$TRUE)] $expDir, [parameter(Mandatory=$TRUE,ValueFromPipeline=$TRUE)] $VMdestdir)

# Copy export data from export dir to the path where VM's files will reside, and perform the import from there

Copy-Item $expdir"\"$VMName -Destination $VMdestdir -recurse -ea "silentlycontinue"
 
# Get VM, VMMS  & Export Settings Objects

$ns = 'root\virtualization'
$vmms = gwmi -n $ns Msvm_VirtualSystemManagementService
$SettingData = $vmms.GetVirtualSystemImportSettingData($VMdestdir+"\"+$VMName).ImportSettingData

# Do not try to copy de VHDs, as we didn't exported them

$SettingData.CreateCopy = $False

# Copy CurrentResourcePaths to SourceResourcePaths, as we assume paths has not changed

$SettingData.SourceResourcePaths = $SettingData.CurrentResourcePaths

# Do the Import VM config Only

$out=$vmms.importVirtualSystemEx($VMdestdir+"\"+$VMName, $SettingData.PSBase.GetText("CimDtd20") )

#Perform Job handling if necessary
 
if ($out.ReturnValue -eq 4096){
    $task = [Wmi]$out.Job;
    while($task.JobState -eq 3 -or $task.JobState -eq 4){
        $task.Get();
        sleep 1;
        }
    if ($task.JobState -ne 7){
        "Error Importing VM " + $task.ErrorDescription;
        }            
    else {
        "Import completed successfully..."
        }
    }
elseif ($out.ReturnValue -ne 0) {
    "Import failed with error : " + $out.ReturnValue;
    }
else {
    "Import completed successfully..."
    }

No me meto en el jardín de llevar a cabo estas tareas sobre sistemas remotos. Digamos que en ambos scripts simplemente tendríamos que agregar el parámetro correspondiente al nombre del host remoto y agregarlo como valor del parámetro –computer en las llamadas a Get-WMIObject (p.e. gwmi –computername $hostremoto…).

DISCLAIMER: Los presentes scripts solamente han sido probados por mi, en un entorno de pruebas, y por tanto su correcto funcionamiento en cualquier situación no está garantizado. Aunque he intentado capturar gran parte de las posibles excepciones, estoy seguro de que puede haber situaciones que no estén contempladas. Si planteáis incluir estos scripts en vuestro maletín de herramientas, por favor, probadlos bien, y enviad cualquier problema o mejora que consideréis pertinente.

NOTA 1: Ardo en deseos de ver lo que es capaz de hacer con esto mi compañero Daniel Matey en base a workflows de DR de Opalis/System Cenyter Orchestrator

NOTA 2: Algo similar a esto es lo que está detrás a soluciones del tipo Snapshot+Remotecopy a nivel de almacenamiento como SnapMirror de NetApp (OnCommand Plug-in for Microsoft)

Saludos

David Cervigón

Categorías: Virtualización

Registrar en Hyper-V máquinas virtuales que no hayan sido exportadas

Vie, 18/11/2011 - 21:49

Hola

En este post vamos a tratar un procedimiento, que deberíamos intentar evitar tener que llevar a cabo en la medida de lo posible, pero que en ocasiones puede llegar a ser el último recurso que nos quede para recuperar el estado de una máquina virtual sin tener que volverla a montar de nuevo a partir de los discos virtuales. En abril de 2008 ya tratamos este tema para la primera versión de Hyper-V, y aunque la esencia sigue siendo la misma, aquel procedimiento ya no resulta válido para ni para Hyper-V 2008 R2 ni para Hyper-V 2008 R2 SP1. Este es el enlace al post original, y ya en los comentarios alguno de vosotros proponíais soluciones para las versiones actuales.

Anatomía de una máquina virtual

A grandes rasgos, una máquina virtual en Hyper-V se compone de:

  • Un fichero donde se almacena la configuración de la máquina virtual. Es un XML con un cierto esquema, que tiene por nombre un GUID. Como veremos más adelante, este GUID tiene implicaciones importantes.
  • Almacenamiento: Discos VHD (fijos, dinámicos o diferenciales) o discos pass-through que se conectan a las controladoras IDE o SCSI definidas en la máquina virtual.
  • Snapshots. Cada vez que se crea una snapshot, se genera un XML de configuración para esa Snapshot, con su propio GUID. Además se generan ficheros .AVHD para cada disco virtual, que en el fondo no son otra cosa que discos diferenciales.
  • Ficheros de estado. Los .vsv que almacenan el estado de memoria y procesador de la máquina virtual, tanto en su punto de ejecución actual como para cada una de las snapshots. Se guardan en carpetas que tienen por nombre el mismo GUID que los ficheros .xml de la máquina virtual y de sus snapshots.

Problema: la configuración por defecto de Hyper-V tiende a desligar los ficheros de configuración de los discos virtuales almacenándolos en diferentes carpetas, y además lo hace por intrincadas ramas del árbol de directorios de C:\. (C:\ProgramData\Microsoft\Windows\Hyper-V y C:\Users\Public\Documents\Hyper-V\Virtual Hard Disks). A mi personalmente me suele gustar cambiar esto en el Hyper-V Manager para que toda máquina virtual que se cree por defecto en base al asistente lo haga en un punto que esta bajo control, si es posible en otra unidad que no sea la de sistema. Es decir cambiar de:

a:

Si utilizas System Center Virtual Machine Manager, o el proceso de Export/Import que veremos en el próximo post, las máquinas virtuales quedan perfectamente ordenaditas en una cierta carpeta. Algo a lo que deberíamos tender cuando las creamos con el asistente del Hyper-V Managera. Para ello basta con marcar esta casilla, que genera una subcarpeta con el nombre de la máquina virtual dentro del path especificado, y donde luego tendemos también la precaución de colocar los VHDs:

Para cerrar este capítulo, y aunque no venga mucho al caso, este asistente gasta otra pequeña broma, que a la larga seguramente pueda llegar a causar problemas. Los VHDs que se crean por defecto son dinámicos y de 127 Gb. Cuando nos damos cuenta de que los discos dinámicos penalizan el rendimiento y lo queremos pasar a fijo, se nos solicitan 127 GB de espacio libre en el datastore donde resida la máquina.

Enlaces simbólicos y permisos

Cuando se genera una máquina virtual, o cuando se llevan a cabo snapshots, sucede lo siguiente:

  • Se crean enlaces simbólicos a los ficheros XML de configuración de las máquinas virtuales y de las snapshots en:
    •  %Allusersprofile%\Application Data\microsoft\Windows\Hyper-V\Virtual Machines
    • %Allusersprofile%\Application Data\microsoft\Windows\Hyper-V\Snapshots (cuando se borra una snapshot, se elimina el enlace y sus ficheros, y en el siguiente reinicio de la máquina virtual se fusionan los AVHDs con sus VHDs correspondientes)
  • Se securizan dichos enlaces simbólicos y todos los ficheros que componen la máquina virtual agregando la propiedad y el control total al usuario NT Virtual Machine\GUID. Dicho usuario es generado por el servicio VMMS de Hyper-V con el GUID que se genera al crear la máquina virtual. En versiones localizadas de Hyper-V, la cadena “NT Virtual Machine” está localizada (traducida)

Todo esto es fácilmente comprobable en cualquier máquina virtual que tengáis creada sobre Hyper-V. El Hyper-V Manager, o mejor dicho el servicio de gestión de máquinas virtuales que corre en la partición padre, solo considera máquinas las máquinas virtuales que tengan dichos enlaces simbólicos creados y los ficheros sobre los cuales tenga permisos. Si algo de esto se rompe, la VM desaparece de la consola, o no puede arrancar al intentar acceder a algún rincón de la configuración.

NOTA: Para probar esto y lo que viene a continuación, obviamente sobre una máquina virtual de prueba, no hay que borrarla del Hyper-V Manager, ya que esto eliminaría los ficheros de configuración. Bastará con borrar los hardlinks, y si se quiere probar del todo eliminar de los permisos el SID que quedará huérfano.

Recuperación de una máquina virtual que nunca fue exportada

Nos encontraremos en esta situación cuando hayamos perdido el host por alguna clase de fatalidad, o cuando nos encontremos ante la necesidad de usar una máquina virtual cuyos ficheros tenemos en su totalidad disponibles en el almacenamiento (p.e, un amigo te pasa un USB lleno de máquinas virtuales que tiene en uso en su entrono y que por tanto no se ha preocupado en exportar). En un escenario de Disaster Recovery habremos perdido todos los hosts pero contaremos con una réplica del almacenamiento. Esto debería de estar planificado de otra manera (existen los clusteres, las copias de seguridad…) , pero como último recurso, y antes de ponernos a crear todas las máquinas virtuales desde cero y reconectarlas a sus discos, podemos probar algo así. El script que proponemos a continuación asume que los paths donde se almacenan las máquinas virtuales no cambian. De ser así, tendríamos que, manual o automatizadamente, cambiarlos el contenido de los ficheros XML previamente al uso del script, o modificarlo para que nos vaya preguntando el nuevo path:

# RegisterVM.ps1  - Registers a Hyper-V’s VM that was not previously exported
# Usage: ./RegisterVM.ps1 <path to VM's xml file>
# Example: ./RegisterVM.ps1 "D:\VirtualMachines\test\Virtual Machines\D73AF4BF-3F52-4DE0-85BA-ADB457E31C37.xml"

param([parameter(Mandatory=$TRUE,ValueFromPipeline=$TRUE)] $VMXMLPath)

# Adding MKLINK function as CreateSymbolicLink

$signature = @"
using System;
using System.Runtime.InteropServices;

namespace System
{
public class MkLink
{
  [DllImport("kernel32.dll")]
  public static extern bool CreateSymbolicLink(string lpSymlinkFileName, string lpTargetFileName, int dwFlags);
}
}
"@

Add-Type -TypeDefinition $Signature

# Hard-coded default Virtual Machines and Snapshots paths in Hyper-V Host

$VMsLNKS = "C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines"
$SnapshotsLNKS = "C:\ProgramData\Microsoft\Windows\Hyper-V\Snapshots"

# Read VM's configuration file

Trap [System.Management.Automation.ErrorRecord] {write-host("File not found, or it is invalid") -Foregroundcolor Yellow; Break}
[xml]$VMCONFIG = get-content $VMXMLPath -EA Stop

# Get VM's XML file name and Service ID from VM's configuration file name. If you are using a localized version of Windows you must translate this string

$VMFile =  [io.path]::GetFileName($VMXMLPath)
$VMPath =  [io.path]::GetDirectoryName($VMXMLPath)
$ServiceID = "NT VIRTUAL MACHINE\"+$VMFile.Replace(".xml", "")


# Get VM's Name. If the attribute does not exist, we assume this is not a VM's XML Configuration file

if ($vmconfig.configuration.properties.name -eq "properties"){
    write-host("The file does not look like a VM's XML file") -Foregroundcolor Yellow
    Throw ("Now exiting")
    }

$VMname = $vmconfig.Configuration.properties.name.Get_InnerText()

# Read available VM's storage

$Disks = $vmconfig.configuration.GetElementsByTagName("pathname")

# Create VM's Hard Link and set ACLs

write-host ("Rebuilding Hardlink") -Foregroundcolor Yellow

$hardlink=[system.MkLink]::CreateSymbolicLink($VMsLNKS+"\"+$VMFile,$VMXMLPath,0)
IF (!$hardlink){
    write-host("Failed to create the hard link") -Foregroundcolor Yellow
    }

# Wait 10 seconds until VMMS Service creates de NT VIRTUALMACHINE\VM ID user.


write-host ("Waiting for Service ID") -Foregroundcolor Yellow
Start-Sleep 10

write-host ("Securing Hard Link and VM's State files") -Foregroundcolor Yellow
   
icacls $VMsLNKS"\"$VMFile /grant $ServiceID":(F)" /L
icacls $VMPath /grant $ServiceID":(F)" /T

# Check whether Snapshots exists or not, and read them. Create their Hard Links and set ACLs

Trap [System.Management.Automation.RuntimeException] {write-host("Snapshots directory is not set in VM's XML configuration file") -Foregroundcolor Yellow ; Continue}
If ($vmconfig.configuration.global_settings.snapshots.list.size.Get_InnerText() -ne "0"){
    write-host ("Rebuilding Snapshots") -Foregroundcolor Yellow
    $Snapshotspath = $vmconfig.configuration.global_settings.snapshots.data_root.Get_InnerText()
    $Snapshots = $vmconfig.configuration.GetElementsByTagName("guid")
    foreach ($_ in $snapshots) {
        if ($_.Get_InnerText()){
            $snap = $_.Get_InnerText()+".xml"
            [system.MkLink]::CreateSymbolicLink($SnapshotsLNKS+"\"+$snap,$Snapshotspath+"\Snapshots\"+$_.Get_InnerText()+".xml",0)
            icacls $SnapshotsLNKS"\"$snap /grant $ServiceID":(F)" /L
            icalcs $Snapshotspath /grant $ServiceID":(F)" /T
            }
        }
    }

# Set ACLs for every VHD (not pass-through Disks)

write-host ("Rebuilding VHD Permissions") -Foregroundcolor Yellow

foreach ($_ in $Disks) {
    if ($_.Get_InnerText().ToLower().Contains("vhd")){
    $Disk = $_.Get_InnerText()
    icacls $disk /grant $ServiceID":(F)"
    }
}

write-host ("Done: Check Hyper-V Manager for the virtual machine") -Foregroundcolor Yellow

El script simplemente necesita como parámetro el path completo al fichero de configuración de la máquina virtual. A partir de aquí:

  • Obtiene el GUID y el path relativo
  • Lee el contenido del XML en busca de las snapshots y el almacenamiento
  • Genera los enlaces simbólicos a los XMLs de máquina virtual y snapshots
  • Aplica permisos a los enlaces simbólicos, a los discos, y a los contenidos de las carpetas donde se almacenan los estados

DISCLAIMER: El presente script solamente ha sido probado por mi, en un entorno de pruebas, y por tanto su correcto funcionamiento en cualquier situación no está garantizado. Aunque he intentado capturar gran parte de las posibles excepciones, estoy seguro de que puede haber situaciones que no estén contempladas. Si llegáis aquí desesperados por haber perdido alguna máquina importante, espero que os ayude a recuperarla o que la información del port os ayude a realizar los pasos manualmente. Si por el contrario os planteáis incluir este script en  vuestro maletín de herramientas, por favor, probadlo bien, y enviad cualquier problema o mejora que consideréis pertinente.

Saludos

David Cervigón

Categorías: Virtualización

La familia de System Center empieza a renovarse

Vie, 18/11/2011 - 18:26

Hola

Durante las ultimas semanas se han puesto a disponibles para descarga las ultimas Release Candidates y Betas de todos los productos de la familia de System Center, que saldrán con la denominación común de System Center 2012

Release Candidates:

  • System Center Virtual Machine Manager 2012
  • System Center Operations Manager 2012
  • System Center Configuration Manager 2012
  • Sustem Center Endpoint Protection 2012
  • System Center Orchestrator 2012

Betas:

  • System Center Data Protection Manager 2012
  • System Center Service Manager 2012
  • System Center Application Controller 2012

Los tres enlaces principales a tener en cuenta son:

Con esto hay como para encerrarse varias semanas en el laboratorio, y salir como nuevo.

Saludos

David Cervigón

Categorías: Virtualización

Integración de SCVMM 2012 con HP ILO para Out of Band Management

Mié, 19/10/2011 - 16:20

Hola

Una de las nuevas funcionalidades que nos traerá SCVMM 2012 es la integración con los siguientes protocolos BMC (Basemother Management Controller), para hacer lo que se denomina Out-Of-Band Management:

  • Intelligent Platform Management Interface (IPMI) en sus versiones1.5 o 2.0
  • Data Center Management Interface (DCMI) versión 1.0
  • System Management Architecture for Server Hardware (SMASH) versión 1.0 sobre WS-Management (WS-Man)

Con ello podemos conseguir controlar el arranque y apagado del servidor desde sus herramientas nativas de gestión integradas en el hardware, en lugar de hacerlo desde el sistema operativo. Esto nos abre la posibilidad de hacer cosas como el despliegue bare-metal del servidor, levantar servidores apagados desde la misma consola de gestión del entorno virtual, o definir políticas de encendido y apagado programado de los hosts para optimizar el rendimiento y el consumo de energía de la solución.

Para la Beta se desarrollo un provider específico para las ILO de HP, pero sin embargo parece que la solución que verá finalmente la luz para el mundo de los servidores HP es el de usar el provider de IPMI, ya que las ILO lo soportan nativamente. Se configura aquí:

  • ILO2 (versión de firmware 2.07)

  • ILO3

Vamos a ver un par de ejemplos de como usarlo desde SCVMM 2012, una vez tenemos configuradas estas opciones en las ILO. Todo lo que necesitaremos saber será:

  • Las direcciones IP o FQDNs de las ILO con las que vamos a trabajar. Es conveniente tenerlas bien identificadas o le estaremos rebotando el servidor a otro, y se volverá loco para averiguar por qué se le cae
  • Las credenciales de un usuario válido a nivel de ILO. Lo más cómodo será crear “Run as Accounts” en SCVMM para almacenarlas

Ejemplo de proceso de Bare-Metal Deployment (ver How to Discover Physical Computers and Deploy as Hyper-V Hosts)

Lanzamos el proceso de agregar nuevo host, especificamos que se trata de máquinas físicas que se van a aprovisionar desde cero, seleccionamos el rango de IPs o IPs individuales donde sabemos que escuchan, en este caso, nuestras ILO, seleccionamos protocolo BMC y puerto acorde a lo configurado arriba y se nos descubren los servidores. El resto es seleccionar la imagen que se utilizará (almacenada en un Host Profile), y parametrizarla para cada servidor en particular. Ni que decir tiene que es en esta parte donde hay que dedicar la mayor parte de los esfuerzos.

              

Ejemplo de integración con la BMC del host en su perfil de SCVMM 2012

Simplemente, nos vamos al perfil de hardware del host y rellenamos el apartado de “BMC Settings”

Con lo que ya tenemos las opciones de encendido, apagado, etc. disponibles. Esta es la diferencia entre haber realizado la integración o no (las opciones aparecen en gris, “dimmed”, en la imagen de la derecha). “Restart” se manejan a nivel de Sistema Operativo (es decir Shutdown /r a la máquina remota)

       

Con esto, además de la gestión manual, también podemos confiar en las políticas de optimización del consumo energético, que serán capaces de apagar y encender completamente los servidores. Por ejemplo:

Saludos

David Cervigón

Categorías: Virtualización