Vmware Vcenter Migración VSCA 5.5 a VSCA 6

1. Por si acaso, preparamos la vuelta atrás.

Restauración a nivel de máquina

Creamos un clon del servidor y apuntamos el host ESXi en el que está ejecutando.
Paramos los servicios de DRS para prevenir que las máquinas se muevan de host y poder restaurar en poco tiempo.

Restauración a nivel de datos

Creamos una copia del inventario en powershell con inventory snapshot. Aunque no se copian ni host profiles ni custom specifications, al menos nos da un punto de restauración a nivel de inventario de máquinas bastante potente.

2.Comenzando la migración.

Elegimos una máquina windows donde se hará la migración. Esta máquina tendrá que tener visibilidad directa con los hosts ESXi y con el vsphere vcenter 5.X que vamos a migrar. A nivel de seguridad, debe tener los mismos puertos abiertos que el vcenter 5.X.

En la página de vmware, se puede descargar la imagen de vsca vSphere 6.0

En un cliente windows virtual asignamos la ISO de vsca.

Este cliente, recomendamos que tenga visibilidad directa tanto con hosts esxi, como con el servidor vcenter que se va a migrar.

En nuestro caso, hemos puesto 2 interfaces de red.

– Interfaz de red 1 de gestión, en la misma subred que el antiguo servidor vcenter VSCA 5.5

– Interfaz de red 2 (sin puerta de enlace) en la misma subred que el servidor ESXi al que vamos a encargar la migración.

Instalamos Vmware-ClienIntegrationPlugin-6.0.0 en el cliente windows que usaremos para actualizar vsca.

Abrimos un navegador a la siguiente dirección: file:///D:/vcsa-setup.html

Pinchamos sobre upgrade y configuramos nuestro host vmware en el que vamos a instalar la imagen.

Si sale el error de Platform services controller, es necesario cambiar el tipo de servidor:

Existing Appliance Type → Embedded Platform Services Controller.

https://pubs.vmware.com/vsphere-60/index.jsp#com.vmware.vsphere.upgrade.doc/GUID-6A5C596D-103E-4024-9353-5569263EB427.html

Pasado este punto, el asistente sigue. Tarda aproximadamente 40 minutos, migrando todo el inventario, profiles, custom specifications y datos de rendimiento.

Cuando termina, apaga el antiguo vcenter, se queda el mismo con la IP del antiguo vcenter y la migración está completada.

Have fun!

Debian 8: Compilar nspluginwrapper

Compilar nspluginwrapper en debian 8, ha sido todo un reto. No suelo compilar paquetes, por lo que me faltaban casi todas las librerías de desarrollo.

Descarga del paquete nsplugin wrapper. La última versión es del año 2011, lo que inquieta un poco, la verdad.

En el equipo ideal, esto funciona a la primera.

$ ./configure
$ make
# make install

Estos son los errores sucesivos que he ido encontrando yo en ,/configure:

Glibc environment not found

GTK+ environment not found

cURL environment not found

X11/Xt environment not found

apt-get install libglib2.0-dev
apt-get install  libgtk2.0-dev libcurl4-gnutls-dev libxt-dev

Resueltos los errores de paquetes, comenzamos con los errores de compilación:

/usr/include/features.h:374:25: fatal error: sys/cdefs.h: No existe el fichero o el directorio

Seguimos instalando

apt-get install libc6-dev-amd64

Y otro

/usr/include/c++/4.9/new:39:28: fatal error: bits/c++config.h: No existe el fichero o el directorio

En este caso, el fichero está en n copias a lo largo del sistema

find /usr -name c++config.h
 
/usr/share/gccxml-0.9/GCC/4.8/bits/c++config.h
/usr/share/gccxml-0.9/GCC/4.7/bits/c++config.h
/usr/share/gccxml-0.9/GCC/4.6/bits/c++config.h
/usr/share/gccxml-0.9/GCC/4.4/bits/c++config.h
/usr/share/gccxml-0.9/GCC/4.9/bits/c++config.h
/usr/include/x86_64-linux-gnu/c++/4.9/bits/c++config.h

Tenemos G++ en versión 4.9

g++ --version
g++ (Debian 4.9.2-10) 4.9.2

Añadimos la ruta a la variable de entorno de G++

export CPLUS_INCLUDE_PATH=$CPLUS_INCLUDE_PATH:/usr/include/x86_64-linux-gnu/c++/4.9/

Tampoco se puede encontrar lsupc++

/usr/bin/ld: no se puede encontrar -lsupc++

Instalamos las librerías standard de C para nuestra versión de g++

apt-get install lib32stdc++-4.9-dev

Fallo al enlazar con nppplayer:

/usr/bin/ld: npplayer-npw-player.o: referencia sin definir al símbolo 'g_thread_init'

Se añade en Makefile el flag para lgthread-2.0

npplayer_LIBS    += $(libpthread_LIBS) $(libsocket_LIBS) -ldl -lgthread-2.0

¡Por fin pasamos el make!

Último paso, y ya tenemos ndiswrapper disponible en nuestro sistema.

make install

Powercli: Clonar lista de máquinas eligiendo como destino el datastore que tiene mayor capacidad

Para agilizar las clonaciones de listas de máquinas, es necesario usar un powercli, que, además, elija como destino el datastore que tenga mayor espacio disponible.

Para ordenar los resultados de datastore en función del espacio disponible:

     $datastorelist = Get-Datastore -Location $DatastoreCluster | sort -descending FreeSpaceMB

En nuestro caso, tenemos los datastore configurados como un datastorecluster, pero,en el caso de no tener, podríamos usar como Location directamente el nombre del cluster o del datacenter donde queremos seleccionar el datastore.

El script completo, está disponible en github.

 
foreach ($clonename in $new_vm)		
	{
    #Select datastore with more space:
    # $datastorelist = Get-Datastore -Location $Datacenter | sort -descending FreeSpaceMB
    # Use in case there are datastore clusters
    $datastorelist = Get-Datastore -Location $DatastoreCluster | sort -descending FreeSpaceMB
    $datastore = $datastorelist[0].Name
    "Clone $clonename in $datastore"

	if (New-VM -Name $clonename -ResourcePool $respool -VM $sourceVM -Location $folder -Datastore $datastore -DiskStorageFormat Thick )
		{"DONE $clonename"}
	else
		{"Something wrong with cloning"}
}

Powercli: Configurar máquinas virtuales para que instalen tools en el inicio

A raíz del artículo de Brian Graf y de LucD sobre cambios de especificaciones de máquinas virtuales, hemos hecho un pequeño script configure_vmtools_power_cycle.ps1 capaz de marcar en las máquinas virtuales el atributo “tools upgrade”

Se invoca desde powercli

.\configure_vmtools_power_cycle.ps1

Requiere configuración para definir en qué contenedor (Location) va a aplicar el cambio de políticas.

Para evitar que queden vmware tools montadas en los linux, sólo aplica el cambio sobre máquinas definidas como Windows y encendidas.

En la versión de powercli 5.5 que estamos trabajando, sólo está relleno el cambio vm.Guest.OsFullname si la máquina está encendida. En el caso de máquinas apagadas, no podemos discriminar por sistema operativo. Por ello, se ha puesto también la opción en la función de forzar la aplicación.

 
Function configure_vmtools_power_cycle ( $vm, [bool] $force )
{
       

   
    # Comment if you want to upgrade non windows vm
    if ((($vm.Guest.State -eq "PoweredOn") -and  ($vm.Guest.OSFullName.Contains("Windows")) -or ($force)))
        
       {
    
        write-host "Configure vmtools check and upgrade in every powercycle: " $vm.Name $vm.Guest.OSFullName

        # This line creates the object that encapsulates the settings for reconfiguring the VM
        $vmConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec
        # This line creates the object we will be modifying
        $vmConfigSpec.Tools = New-Object VMware.Vim.ToolsConfigInfo
        # This line sets the Tools upgrades policy checkbox
        $vmConfigSpec.Tools.ToolsUpgradePolicy = "UpgradeAtPowerCycle"
        # This line commits the change to each virtual machine
        # Get-View -ViewType VirtualMachine | %{    $_.ReconfigVM($vmConfigSpec)}
    
        # Reconfigure vm
        $vm | Get-View | %{ $_.ReconfigVM($vmConfigSpec)}
        
        
   }
 }

Autenticación en máquinas linux mediante kerberos

https://wiki.debian.org/AuthenticatingLinuxWithActiveDirectory

Instalación y configuración de libpam-krb5

[logging]
        Default = FILE:/var/log/krb5.log
[libdefaults]
        default_realm =  DOMINIO.COM
        krb4_config = /etc/krb.conf
        krb4_realms = /etc/krb.realms
        kdc_timesync = 1
        ccache_type = 4
        forwardable = true
        proxiable = true
        v4_instance_resolve = false
        v4_name_convert = {
                host = {
                        rcmd = host
                        ftp = ftp
                }
                plain = {
                        something = something-else
                }
        }
        fcc-mit-ticketflags = true
[realms]
        DOMINIO.COM = {
                kdc = server1.dominio.com
                kdc = server2.dominio.com
                admin_server = server1.dominio.com:88
                default_domain = dominio.com
        }
[domain_realm]
        .DOMINIO.COM = DOMINIO.COM
        DOMINIO.COM = DOMINIO.COM
[login]
        krb4_convert = true
        krb4_get_tickets = false

Prueba con kinit

Probamos nuestro usuario de pruebas contra el dominio:

kinit  usuario@dominio.com

Revisión de archivos de PAM

Por defecto, se crean las líneas de pam para aceptar krb5:

http://www.debian-administration.org/article/570/MIT_Kerberos_installation_on_Debian#PAM_configuration

Prueba con login

login usuario

en el log se debe ver algo como

tail -f /var/log/auth.log
Mar 17 13:15:14 puppettest login[20778]: pam_krb5(login:auth): user usuario authenticated as usuario@dominio.com

Pasos a seguir

Crear localmente los usuarios que van a usar su autenticación mediante kerberos.

Puppet: Argumentos erroneos, error en ruby

El agente de puppet no hace gestión de argumentos de entrada. En el caso de ser erróneo, da el siguiente error:

root@puppettest1:~# puppet agent ..server myserver  ..no-daemonize ..verbose ..waitforcert=60
dnsdomainname: Name or service not known
/usr/lib/ruby/vendor_ruby/puppet/application/agent.rb:54:in `handle_serve': uninitialized constant Puppet::Network::Handler (NameError)
        from /usr/lib/ruby/vendor_ruby/puppet/application.rb:363:in `send'
        from /usr/lib/ruby/vendor_ruby/puppet/application.rb:363:in `parse_options'
        from /usr/lib/ruby/1.8/optparse.rb:1298:in `call'
        from /usr/lib/ruby/1.8/optparse.rb:1298:in `parse_in_order'
        from /usr/lib/ruby/1.8/optparse.rb:1254:in `catch'
        from /usr/lib/ruby/1.8/optparse.rb:1254:in `parse_in_order'
        from /usr/lib/ruby/1.8/optparse.rb:1248:in `order!'
        from /usr/lib/ruby/1.8/optparse.rb:1339:in `permute!'
        from /usr/lib/ruby/1.8/optparse.rb:1360:in `parse!'
        from /usr/lib/ruby/vendor_ruby/puppet/application.rb:370:in `parse_options'
        from /usr/lib/ruby/vendor_ruby/puppet/application.rb:305:in `run'
        from /usr/lib/ruby/vendor_ruby/puppet/application.rb:416:in `hook'
        from /usr/lib/ruby/vendor_ruby/puppet/application.rb:305:in `run'
        from /usr/lib/ruby/vendor_ruby/puppet/application.rb:407:in `exit_on_fail'
        from /usr/lib/ruby/vendor_ruby/puppet/application.rb:305:in `run'
        from /usr/lib/ruby/vendor_ruby/puppet/util/command_line.rb:69:in `execute'
        from /usr/bin/puppet:4

En versiones anteriores como 2.6, se requería añadir a mano en lib/puppet/application/agent.rb la línea

 require 'puppet/network/handler'

Para saber qué versión de puppet se está ejecutando

puppet agent --version

En version 2.7, hay que revisar los argumentos de entrada. En nuestro caso, al cortar y pegar, se habían sustituido los — por ..

Vmware: Virtual distributed switch

Para evitar la configuración de red en cada uno de los hosts, vamos a configurar en forma de virtual distributed switch (VDS), frente a los virutal standard switch (VSS).

http://www.vmware.com/files/pdf/virtual_networking_concepts.pdf

Un VDS se configura a nivel de datacenter.

En el momento de la creación, hay que definir el número de uplinks que vamos a utilizar. Aunque se pueden definir a posteriori, es mejor crear el número definitivo de uplinks, y añadir los interfaces físicos (vmnic) al uplink definitivo.

Consideraciones pre-migración

Hemos verificamos que los hosts mantienen la configuración de red, a pesar de tener una desconexión en el vcenter.
Si, en estado de desconexión del vcenter, se hacen cambios sobre VDS, hay problemas al conectarlo de nuevo.
La configuración de VDS se hace a nivel de datacenter. Eso significa que para hosts en distintos clusters, tenemos disponibles VDS’s con vlan’s que no tienen visibilidad. El control para evitar tráfico de red indeseado (tráfico de extranet o dmz, en zona interna) recae directemente sobre la electrónica de red.
A la hora de dimensionar el número de VDS, requerimos uno por cada canal físico o agregado (trunk) de red.
Borrar uplinks es extremadamente difícil. Es mejor hacer el diseño con el número de uplinks desde el comienzo de la definición del VDS.

Hosts y VDS

En un VDS, se pueden añadir o quitar hosts físicos.

Networking > VDS > Manage > Settings

Añadir interfaces físicos a VDS y a uplink groups

Configuración vlan: virtual port group

Dentro de un VDS, se configuran virtual portgroup, que tienen la información de vlan, nic teaming y security igual que un portgroup tradicional.

Además, se les puede configura portmirroring.

Los virtual portgroup, se asignan en las máquinas virtuales igual que los tradicionales.

Powercli

Para gestionar virtual distributed switches, es necesario instalar el paquete de VDSPowerCli , disponible en flings de vmware.

Cada vez que se vayan a invocar cmd-lets de VDS, es necesario cargar el módulo:

Add-PSSnapin VMware.VimAutomation.VdsComponent

Para ver todos los cmd-let disponibles

Get-Command –Module VMware.VimAutomation.VdsComponent

Vmware: host profiles con arranque desde SAN

Los host-profiles permiten tener una plantilla de configuración de host que asegura que todos los esxi de un cluster son iguales.

Hacen extraordinariamente cómodo la configuración de nuevos servidores.

Se almacenan los datos de:

red
almacenamiento
ntp
servicios, firewall…

El problema viene, cuando parte de los servidores tienen arranque desde SAN.

El perfil, ve el disco de arranque igual que un datastore. El perfil da error de multimapping y psa invariablemente, al aplicar el perfil sobre otros servidores.

Hemos probado a deshabilitar entero la seccción de storage configuration.

Al no tener nada de información metida en los vmware, al respecto de los discos, entra en funcionamiento el mismo mecanismo que si no huebiera host profile en absoluto: Lo que los Hosts ESX vean a través de la fibra se considera datastore.

El perfil por tanto:

Se puede aplicar sobre cualquier host.
Configura correctamente red, ntp, dns, etc.
Ignora todos los settings de almacenamiento sin dar error.

Vmware: Subir compatibilidad de forma automática con los reinicios

Estamos subiendo la compatibilidad de todas nuestras máquinas virtuales a vmx-10 que son las compatibles con ESXi 5.5 or higher.

Requiere reinicio, y aún tenemos muchas máquinas en versiones vmx-07 y vmx-08, que provienen de las versiones esxi 4.1 y 4.5 respectivamente.

Por ello, hemos optado por programarlo de forma automática, de forma que sean los usuarios en el reinicio los que suban de versión:

https://communities.vmware.com/message/2249221#2249221

Hemos tenido que hacer un cambio en la línea 65 para que actúe sobre las máquinas que están en versión menor a 10:

if ($vmversion -ne "vmx-10") {

y que la versión que instale sea vmx-10, en la linea 72

$spec.ScheduledHardwareUpgradeInfo.versionKey = 'vmx-10'

Crear y probar nuestros modulos de puppet

Crear la arquitectura de nuestro modulo

La arquitectura de nuestro nuevo módulo, siempre va a tener una distribución de archivos parecida a:

manifests
--- init.pp
README.mdtemplates
 --- template.erb
tests
 --- test1.pp
files

Escribir el init.pp y tests

Para escribir los módulos, proponemos Gepetto sobre Eclipse.

Para verificar la sintáxis de las clases, se puede usar puppet-lint

gem install puppet-lint
 puppet-lint manifests/init.pp

Al escribir los tests, se pueden asociar al nodo default para mantenerlos sencillos

 node default {
 include mymoduleclass
}

Probar en un nodo con puppet instalado en local

Configuramos en puppet.conf de donde se van a leer los módulos

[main]

(..)
 puppetmodulepath=/etc/puppet/modules:/usr/share/puppet/modules

Para verificar la clase:

puppet apply --noop tests/test1.pp

Para aplicar cambios

puppet apply tests/test1.pp