Etiqueta: location

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”vmware.vmtools.upgrade.power.cycle

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)}
        
        
   }
 }

 

Power cli: script para mover máquinas virtuales de datastore

VMWare ESXi
VMWare ESXi

Utilizando powershell, podemos hacer un pequeño script que nos libere un datastore completo, moviendo las máquinas virtuales que residen en él a una nueva ubicación.

Además,  desmontamos las vmware tools, si están montadas, como indican en las communities de vmware.

Function migrate_ds  ([string] $old_ds, [string] $new_ds)
{            $vms = Get-VM -Datastore $old_ds
            foreach ($vm in $vms) {  
                    # unmount tools and clean cd drive 
                    $vm | Get-CDDrive | where { $_.IsoPath -or $_.HostDevice -or $_.RemoteDevice } | Set-CDDrive -NoMedia -Confirm:$false
                    $vm  | move-VM -Datastore $new_ds
            
            }
}

migrate_ds my_old_ds my_new_ds

Powercli – Clonar varias máquinas a la vez

Queremos clonar de forma automática un número de máquinas, con un patrón concreto. Para ello, hemos usado de powershell:

  • -Match
  • -notmatch

La autentación contra vcenter está fuera del script. Debe hacerse antes de llamarlo.

Al no tener resource pools configurados, la nueva máquina, debe dejarse en el resourcepool “Resources”. Con get-resourcepool podemos consultar cuáles tenemos disponibles en nuestra arquitectura.

# Basado en http://vmwaremine.com/2013/05/28/powercli-clone-vm/
#
# Ester Niclos Ferreras
# Last updated: 29/2/14

# PRe: connect-viserver vc

#
# SourceVM:
#
$vmlist= get-vm pattern* | WHERE   { $_.Name -notMatch “no_pattern” }

$datastore = Get-Datastore “my_datastore”
$folder = get-folder “my_folder” -Location “my_datacenter”
$respool = get-ResourcePool Resources -Location “manvmecluster”

foreach ( $sourceVM in $vmlist) {
$cloneName = $sourceVM.Name +’-clone’

#write-host $sourceVM $cloneName $datastore  $folder

if (New-VM -Name $cloneName -ResourcePool $respool -VM $sourceVM -Location $folder -Datastore $datastore -DiskStorageFormat Thin )
{“DONE”}
else
{“Something wrong with cloning”}
}

 

Citrix XenApp: Visión general

Básicamente, el objetivo de Xen APP 5 es publicar aplicaciones en el cliente, cómo si fueran parte de su sistema.

Para ello, necesitamos una infraestructura capaz de autenticar a nuestro usuario, ver qué aplicaciones tiene disponibles en el sistema y mantener la conexión para enviar la ventana de aplicación a su sistema.

Arquitectura básica Xen APP 5

  •  gestor para la granja de Citrix, donde se instalará, entre otros “Citrix delivery services console”.
  • servidores de licencia
  • Servidores de Citrix XenAPP (granja).

Configuración básica de servidores

En el gestor  “Citrix delivery services console”, se organizan los servidores en granjas.

Cada Granja tiene:

  • Administradores
  • Servidores: máquinas con Citrix XenAPP
  • Aplicaciones: los ejecutables que se van a publicar a través de citrix.

Una aplicación, a su vez, tiene entre sus propiedades:

  • Location: El ejecutable que invoca realmente en las máquinas citrix.
  • Servers: Servidores donde, debe estar el ejecutable, y donde se redirigirán los ejecutables.
  • Users: Usuarios que pueden acceder a la aplicación con citrix

Citrix secure gateway

Es el componente encargado de gestionar una comunicación segura entre XenAPP y los usuarios finales. Se coloca en la DMZ de la organización y encripta las conexiones con los servidores de la granja citrix.

Puede ponerse dentro o fuera de las máquinas con Citrix XenAPP.

Desde winadmins.wordpress.com explican fenomenal cómo es una arquitectura básica de Citrix.

Configuración de clientes.

Los clientes, acceden a la plataforma vía web, y necesitan un cliente citrix (aka icaclient) para poder abrir las conexiones.

En el caso de Debian de 64bits, os recomendamos esta guía para el cliente citrix.