La entrada 5 razones por las que todavía utilizar el cliente windows de VMware vSphere aparece primero en Maquinas Virtuales.

Virtual Machine Component Protection en clusters de VMware vSphere 6

Una nueva funcionalidad de vSphere 6 y que me parece muy interesante, es lo que VMware ha denominado Virtual Machine Component Protection y que consiste, de forma resumida, en la detección automática de eventos del tipo All Paths Down (APD) y Permanent Device Loss (PDL) de forma que ante perdidas de conectividad de un servidor host con el almacenamiento, las máquinas virtuales afectadas puedan reiniciarse de forma automática en otro servidor del mismo cluster que si tenga acceso al almacenamiento.

No hay que confundir esta funcionalidad con Virtual Machine Monitoring, que se encarga de comprobar el estado de las máquinas virtuales de forma individual y reiniciarlas si es necesario.

Vamos ver un ejemplo básico de como funciona Virtual Machine Component Protection y cual es la diferencia respecto a versiones anteriores de vSphere.

Vamos a ver cual es el comportamiento de las máquinas virtuales en el caso de pérdida de conexión de uno de los servidores host con el almacenamiento iSCSI en dos situaciones:

• Con un cluster HA con vSphere 5.5
• Con un cluster HA con vSphere 6 y VMCP ( Virtual Machine Component Protection)

Ejemplo con cluster HA con vSphere 5.5

• En el primer ejemplo vamos a seguir la evolución de los eventos que ocurren cuando un host del cluster pierde la conexión con el almacenamiento:
  • Cluster02
    • 2 servidores ESXi con almacenamiento iSCSI
    • 1 máquina virtual de nombre DSL02 que se está ejecutando en el servidor 10.0.9.52 y se encuentra ubicada en el datastore FREENAS01-ISCSI-03

• HA configurado con las siguientes opciones

• Partimos de la situación en la máquina se está arrancada y respondiendo con normalidad

• Ahora forzamos la caída del almacenamiento simulando la pérdida de conectividad entre el host y el almacenamiento ISCSI (el resto de componentes de red siguen funcionando, tanto el interfaz de administración del host, como el de las máquinas virtuales)
• Vamos a ver los eventos que ocurren a partir de este momento
• Se detecta la caía del interfaz de red en el servidor host

• Se detecta el estado APD del almacenamiento

• Cambian de estado las alarmas

• Después de pasar 140 segundos se declara “oficialmente” el estado APD

• Y no ocurre nada más. La máquina seguirá en ejecución en el mismo servidor pero sin tener acceso al almacenamiento su estado no es consistente.

• No podremos realizar operaciones sobre la máquina virtual hasta que no hayamos recuperado el almacenamiento.

Ejemplo con cluster HA con vSphere 6 y VMCP

Ahora vamos a ver una situación similar en un cluster con vSphere 6 y VMCP configurado

• Habilitamos VMware HA y marcamos Host Hardware Monitoring – VM Componente Protection  (Importante: esta configuración sólo está disponible en el interfaz web)

• Y las siguientes opciones
  • Response fot Datastore with Permanent Device Loss (PDL): Power off and restart VMs
  • Response for Datastore with All Paths Down (APD): Power off and restart VMs (conservative)
  • Delay for VM failover for APD: 3 minutes
  • Response for APD recovery after APD timeout (Disabled)

• Vamos a seguir la evolución de los eventos en la máquina virtual DSL01 que se encuentra en esta situación:
  • Se está ejecutando en el servidor 10.0.9.1, dentro del Cluster01
  • Está utilizando el datastore FREENAS01-ISCSI-01

• En la misma página de Summary de la máquina podemos ver la información de su estado y configuración de HA

• La máquina se está ejecutando y respondiendo a la red
• Ahora forzamos la caída del almacenamiento simulando la perdida de conectividad entre el host y el almacenamiento ISCSI (el resto de componentes de red siguen funcionando, tanto el interfaz de administración del host, como el de las máquinas virtuales)
• Vamos a ver los eventos que ocurren a partir de este momento
• Se detecta la caída del interfaz de red en el servidor host

• Se detecta el estado APD del almacenamiento

• Se indica el error de conexión con el almacenamiento

• Cambian de estado las alarmas y se realizan las acciones correspondientes (envió SNMP, correo…)

• Después de pasar 140 segundos se declara “oficialmente” el estado APD y se comprueban las máquinas virtuales afectadas

• En la máquina virtual se genera el evento correspondiente

• Se apaga la máquina virtual

• Se generan las alarmas correspondientes a la máquina virtual

• Se reinicia la máquina virtual

• Una vez arrancada, la máquina virtual se enciende en otro de los host del cluster que si tiene conectividad al almacenamiento

Con este sencillo ejemplo vemos la potencia y la importancia de  Virtual Machine Component Protection como un paso más a la hora de ofrecer mayor y mejor disponibilidad de las máquinas virtuales dentro de un cluster con VMware vSphere 6.

La entrada Virtual Machine Component Protection en clusters de VMware vSphere 6 aparece primero en Maquinas Virtuales.

En las versiones anteriores de la versión VCSA de vCenter, teniamos el interfaz VAMI (https://vcenter:5480) para, además de poder realizar ciertos cambios en la configuración del appliance, actualiza la versión del sistema.

Con la versión 6 de vSphere, ya no disponemos del interfaz VAMI por lo que tenemos que utilizar el comando software-packages para instalar las actualizaciones que queremos aplicar a nuestro sistema vCenter (o PSC si tiene este servicio)

Descarga de las actualizaciones

El primer paso es obtener el archivo desde el que descargar las actualizaciones. Para ello seguimos estos pasos:

• Accedemos a https://my.vmware.com/group/vmware/patch
• Seleccionamos el producto VC

• Podemos establecer otros filtros como la severidad o categoría
• Obtenemos el listado de actualizaciones disponibles

• A fecha de hoy, y como se ve en la imagen, tenemos dos actualizaciones disponibles para la versión appliance VCSA (y 1 para la versión Windows)
• Descargamos los archivos .ISO de las actualizaciones a aplicar

Montar la imagen ISO

El siguiente paso es montar la imagen ISO de la actualización descargada. Para ello seguimos los pasos como si fuese cualquier otra máquina virtual

Conexión al servidor VCSA

Tenemos dos opciones para conectarnos al servidor

• SSH: utilizamos nuestra herramienta de conexión preferida y nos conectamos en remoto utilizando el usuario root

• En local: si no queremos utilizar SSH, podemos conectarnos desde la consola de la máquina virtual. Para ello, seguimos estos pasos
  • Accedemos al interfaz DCUI con el usuario root
  • Pulsamos Alt+F1 y entramos con el usuario root

Uso del comando software-packages

Como he comentado al inicio, vamos a utilizar el comando software-packages para instalar las actualizaciones en el appliance VCSA.

• Podemos ver la ayuda del comando

Command> software-packages -h
usage: software-packages [-h] {stage,unstage,install,list} ...

optional arguments:
  -h, --help            show this help message and exit

sub-commands:
  {stage,unstage,install,list}
    stage               Stage software update packages
    unstage             Purge staged software update packages
    install             Install software update packages
    list                List details of software update packages

• Lo primero que vamos a hacer es listar los paquetes instalados, mostrándonos en detalle las versiones y fechas de instalación.

Command> software-packages list
 [2015-04-26T12:58:11.116] :
'Name'                         'Version'      'release'           'Install Date'
pth                            2.0.7                102.22              2015-02-17
libopenssl1_0_1                1.0.1j               1.vmw.2433429       2015-02-17
iputils                        ss021109             292.28.1            2015-02-17
sysfsutils                     2.1.0                102.25.1            2015-02-17
perl-HTML-Tagset               3.20                 1.22                2015-02-17
vmware-vws                     1.5.0                1                   2015-04-07
libreadline5                   5.2                  147.22.1.7399.0.PTF.8988802015-02-17
gd                             2.0.36.RC1           52.18               2015-02-17
rsyslog                        5.10.1               0.11.1              2015-02-17
gdbm                           1.8.3                371.83              2015-02-17
libtiff3                       3.8.2                141.154.1           2015-02-17
vmware-tools-vmci-kmp-default  9.7.1.0_3.0.76_0.11  5.sles11            2015-02-17
unzip                          6.00                 11.9.1              2015-02-17
pyxml                          0.8.4                194.23.38           2015-02-17
...

• Podemos ver un historial de las actualizaciones instaladas con

Command> software-packages list --history
 [2015-04-26T13:00:49.116] :
'Name'                                  'Install Date'

• En este caso vemos que no tenemos ninguna

Sabiendo cual es la situación de la que partimos, en cuanto a paquetes instalados y que no tenemos ninguna actualización, vamos a proceder con la instalación de las ya publicadas por VMware. Para ello tenemos dos opciones

• Hacer un stage o descargar la imagen al sistema e instalarla. En este caso sólo tenemos un paso.
• Hacer un stage o descargar la imagen para instalarla más adelante. En este caso realizamos la instalación en dos pasos.

Vamos a ver como haríamos la instalación en las dos situaciones.

• Para hacerlo en un solo paso (–acceptEulas es opcional)

software-packages install --iso --acceptEulas

• Y esperamos a que termine el proceso

Command> software-packages unstage
 [2015-04-26T13:11:21.116] : ISO unmounted successfully
 [2015-04-26T13:11:21.116] :  Unstage operation completed successfully
Command> software-packages install --iso --acceptEula
 [2015-04-26T13:11:41.116] : Staging software update packages from ISO
 [2015-04-26T13:11:41.116] : ISO mounted successfully
 [2015-04-26 13:11:41,142] : Running pre-stage script.....
 [2015-04-26T13:11:42.116] : Verifying staging area
 [2015-04-26T13:11:42.116] : Validating software update payload
 [2015-04-26T13:11:42.116] : Validation successful
 [2015-04-26 13:11:42,462] : Processing software packages in update payload 5/5
 [2015-04-26T13:11:44.116] : ISO unmounted successfully
 [2015-04-26T13:11:44.116] : (3) packages staged successfully
 [2015-04-26 13:11:44,697] : Running test transaction ....
 [2015-04-26 13:11:45,702] : Running pre-install script.....
 [2015-04-26T13:13:02.116] : Services stopped.
 [2015-04-26 13:13:02,847] : Upgrading software packages ....
 [2015-04-26 13:13:18,875] : Running post-install script.....
 [2015-04-26T13:13:19.116] : Packages upgraded successfully, Reboot is required to complete the installation.

• Tras la instalación podemos comprobar que ahora si tenemos actualizaciones al listarlas con el comando software-packages

Command> software-packages list --history
 [2015-04-26T13:15:28.116] :
'Name'                                  'Install Date'
VC-6.0.0a-Appliance-TP                  2015-04-26 13:13:18

• Y si listamos los paquetes instalados, podemos ver los cambios que ha realizado la actualización. Por ejemplo: la actualización de este KB ha actualizado estos 3 paquetes
  • vmware-jre
  • vmware-studio-init
  • vmware-studio-appliance-config

vmware-jre          1.7.0_72           fcs         2015-02-17
vmware-jre          1.7.0_76           fcs         2015-04-26


vmware-studio-init      2.6.0.7        150216165134        2015-02-17
vmware-studio-init      2.6.0.7        150317230426        2015-04-26


vmware-studio-appliance-config    2.6.0.7    150216165134        2015-02-17
vmware-studio-appliance-config    2.6.0.7    150317230426        2015-04-26

• Tras la instalación, reiniciamos el sistema

Command> shutdown reboot -r "Instalación de actualización"
Command>
Broadcast message from root (pts/0) (Sun Apr 26 13:24:55 2015):

Instalación de actualización
The system is going down for reboot NOW!

• Si lo vamos a realizar en dos pasos, ejecutamos estos comandos (–acceptEulas es opcional)

Command> software-packages stage --iso --acceptEulas
 [2015-04-26T13:34:54.116] : Staging software update packages from ISO
 [2015-04-26T13:34:54.116] : ISO mounted successfully
 [2015-04-26 13:34:54,267] : Running pre-stage script.....
 [2015-04-26T13:34:55.116] : Verifying staging area
 [2015-04-26T13:34:55.116] : Validating software update payload
 [2015-04-26T13:34:55.116] : Validation successful
 [2015-04-26 13:34:55,582] : Processing software packages in update payload 36/36
 [2015-04-26T13:36:13.116] : ISO unmounted successfully
 [2015-04-26T13:36:14.116] : (31) packages staged successfully
 [2015-04-26T13:36:14.116] : Staging process completed successfully

• Podemos ver las actualizaciones que tenemos descargadas en el sistema y listas para instalar

Command> software-packages list --staged
 [2015-04-26T13:37:48.116] :
        category: security
        kb: http://kb.vmware.com/kb/2111640
        vendor: VMware, Inc.
        name: VC-6.0.0a-Appliance-FP
        tags: [u'']
        productname: VMware-vCenter-Server-Appliance
        releasedate: April 9, 2015
        version: 6.0.0.5110
        buildnumber: 2656759
        rebootrequired: True
        summary: Patch for VMware vCenter Server Appliance 6.0
        severity: critical

• Instalamos las actualizaciones

Command> software-packages install --staged --acceptEulas
 [2015-04-26 13:46:02,021] : Running test transaction ....
 [2015-04-26 13:46:07,077] : Running pre-install script.....
 [2015-04-26T13:48:54.116] : Services stopped.
 [2015-04-26 13:48:54,754] : Upgrading software packages ....
 [2015-04-26 13:52:17,055] : Running post-install script.....
 [2015-04-26T13:52:18.116] : Packages upgraded successfully, Reboot is required to complete the installation.

• Reiniciamos el sistema

• Tras el reinicio comprobamos las actualizaciones instaladas

Command> software-packages list --history
 [2015-04-26T07:58:39.116] :
'Name'                                  'Install Date'
VC-6.0.0a-Appliance-TP                  2015-04-26 13:13:18
VC-6.0.0a-Appliance-FP                  2015-04-26 13:52:17

• Y podemos ver también el listado completo de paquetes actualizados, viendo que esta actualización si que actualiza más paquetes que la anterior actualización que hemos visto en esta entrada

Command> software-packages list
 [2015-04-26T13:59:04.116] :
'Name'                  'Version'	'release'	'Install Date'
VMware-syslog           1.0.0           2656749         26/04/2015
vmware-afd              6.0.0.2335      2602313         26/04/2015
VMware-mbcs             6.0.0           2656749         26/04/2015
vmware-jre              1.7.0_76        fcs             26/04/2015
vmware-eam              6.0.0           2656761         26/04/2015
VMware-vc-support       6.0.0           2656761         26/04/2015
VMware-vpxd-agents-eesx	6.0.0           2656761         26/04/2015
vmware-ic-deploy        6.0.0.1555      2640983         26/04/2015
VMware-cloudvm-vimtop   6.0.0           2656761         26/04/2015
VMware-OpenSSL          6.0.0           2656761         26/04/2015
VMware-visl-integration	6.0.0		2656761         26/04/2015
vmware-cm               6.0.0           2656749         26/04/2015
VMware-vpxd             6.0.0           2656761         26/04/2015
vmware-directory-client	6.0.0.4250      2600600         26/04/2015

Así como en versiones anteriores era posible comprobar las versiones con un repositorio en Internet, si que creo que puede ser interesante el poder consultar o incluso descargar, las actualizaciones disponibles, sin tener que trabajar con archivos ISO. Puede que esta opción esté disponible en una futura versión.

La entrada Instalación de actualizaciones en VMware vSphere 6 – VCSA aparece primero en Maquinas Virtuales.

Instalación XPenology vmdk

Estos días ando con algún que otro problema de capacidad en mi Nas Synology DS213j, y he pensado incluso en renovarlo. Pero quería encontrar alternativas libres a través de la instalación de discos adicionales en uno de mis HP Proliant Microserver G8.

Podéis ver que existen diferentes proyectos, como Openfiler o Freenas, pero ninguno, aunque muy potentes, se acercan al software que trae consigo Synology en su hardware.

Así que me puse a investigar si existía forma de portar ese software, y la hay. Existe un proyecto llamado XPenology, que migra dicho software a hardware diferente y no del fabricante.

Hoy os quiero mostrar como montar el VMDK de XPenology en vuestra infraestructura VMware, a través del cliente web.

Lo primero de todo bajamos el vmdk desde este enlace: http://download.xpenology.fr/

Desde la vista del Storage creamos una carpeta para el vmdk:

Y le damos nombre:

Pulsamos Uploads:

Subimos el VMDK:

Una vez cargado creamos una máquina virtual:

New Virtual Machine:

Seguimos los pasos creando una nueva máquina:

Colocamos un nombre significativo:

Elegimos host:

Datastore:

Versión esxi:

El sistema es un Debian 7 de 64 bits:

Dejamos todo por defecto:

Ahora editamos la máquina virtual añadiendo un disco existente(yo he borrado el que se ha generado para colocar el tamaño que yo quiero):

Elegimos el VMDK de XPENOBOOT:

Modificaremos luego todo esto, pero sirve para arrancar:

Y arrancamos la máquina virtual vmware:

Mostraremos como configurarlo en próximas entradas.

La entrada Instalación Nas XPenology vmdk aparece primero en Maquinas Virtuales.

Estos días estoy reinstalando el laboratorio casero que tengo y como voy a tener varias máquinas virtuales con VMware ESXi, voy a describir todos los pasos para crear una imagen de VMware ESXi y que podamos reutilizarla de forma sencilla para replicar varios servidores.

Comprobar capacidades del servidor físico

Vamos a empezar por lo básico. ¿El servidor físico que tengo soporta el uso de maquinas virtuales con ESXi? Tras instalar VMware ESXi accedemos a la URL https://SERVIDOR/mob/?moid=ha-host&doPath=capability y comprobamos que el campo nestedHVSupported tiene el valor true

Instalar ESXi Mac Learning dvFilter

Por defecto, un servidor ESXi sabe que direcciones MAC de las máquinas virtuales están asociadas a cada puerto de los vSwitch. En el caso de que una máquina virtual sea también un ESXi complica su funcionamiento. Para que la red siga funcionando en las máquinas virtuales que se ejecutan en el servidor ESXi virtual, tenemos dos opciones:

• Habilitar el modo promiscuo en el vSwitch del servidor físico. Esto genera una gran cantidad de tráfico de red
• Utilizar el paquete ESXi Mac Learning dvFilter. Este paquete ha sido desarrollado por William Lam (virtuallyGheto) y permite que el servidor ESXi tenga la capacidad de aprender las MAC de cada uno de los puertos de vSwitch. Se puede descargar desde el blog de William o desde el enlace al fling.

Para instalar el paquete en los servidores físicos realizamos los siguientes pasos:

• Nos conectamos por SSH o por la Shell local al servidor
• Ejecutamos el siguiente comando

esxcli software vib install -v http://download3.vmware.com/software/vmw-tools/esxi-mac-learning-dvfilter/vmware-esx-dvfilter-maclearn-1.0.vib -f

• Si no tenemos acceso a internet desde el servidor ESXi, podemos descargar previamente el archivo .vib y ubicarlo en una de las carpetas de los datastores del servidor y ejecutar la instalación con el comando esxcli desde esa carpeta local.
• Para comprobar que está funcionando, sin reiniciar el equipo, ejecutamos

/sbin/summarize-dvfilter

Una vez instalado en el equipo físico, tendremos que habilitar la opción por cada máquina virtual que tenga un servidor ESXi, añadiendo la configuración (por cada interfaz de red):

ethernet0.filter4.name=dvfilter-maclearn
ethernet0.filter4.onFailure=failOpen

Crear la máquina virtual

Creamos la máquina virtual con las siguientes opciones:

• Versión de Hardware: vmx-10
• CPU: al menos 2
• Memoria RAM: al menos 4096 MB
• Interfaces de red: al menos 6 interfaces E1000e
• Disco duro: con un disco de 4GB es suficiente (puede ser en modo Thin)
• Sistema Operativo: Other
• Video Card: Auto-Detect Settings
• Eliminamos otros dispositivos como puedan ser disqueteras, dispositivos USB…

Instalar VMware ESXi 5.5

Arrancamos con la ISO de instalación y realizamos la instalación de VMware ESXi

Configuración inicial VMware ESXi 5.5

• Configuración de red
• Servidor NTP
• Habilitamos SSH por defecto

Instalar VMware Tools

Una vez arrancado instalamos las VMware Tools, en este caso instalamos las tools específicas para servidores ESXi nested

Ejecutamos:

esxcli software vib install -v http://download3.vmware.com/software/vmw-tools/esxi_tools_for_guests/esx-tools-for-esxi-9.7.0-0.0.00000.i386.vib -f

Preparara para la clonación

Antes de poder clonar la máquina tenemos que realizar otras configuraciones para siguiendo los pasos, una vez más, de William Lam en virtuallyGhetto

•  En la confiugración del servidor ESXi hay una asociación entre el VMKernel y la MAC de la tarjeta asociada. Para eviar problemas al cambiar la MAC de la tarjeta de red ejecutamos el comando:

esxcli system settings advanced set -o /Net/FollowHardwareMac -i 1

• Para asegurarnos que se genere un ESXi System UUID único para cada servidor, editamos el archivo /etc/vmware/esx.conf y borramos la línea que hace referencia al System UUID

• Para que los cambios sean persistentes ejecutamos

/sbin/auto-backup.sh

Exportar la imagen

Una vez que hemos terminado de configurar la máquina virtual, la apagamos y la exportamos en formato OVF

De esta forma cuando queramos volver a crear un servidor ESXi Neste únicamente tendremos que desplegar la plantilla y tendremos todas las configuraciones hechas.

Tareas posteriores

Tras importar una plantilla y crear una nueva máquina tenemos que realizar algunos pasos más.

Antes de arrancar la máquina virtual vamos a hacer algunos cambios de configuración. Estos cambios los tenemos que hacer porque al importar la plantilla OVF algunos de los parámetros se pierden, por lo que aunque los hubiésemos incluido en la plantilla los hubiésemos tenido que configurar en cada máquina.

• Habilitar VHV (Virtual Hardware-Assisted Virtualization): añadimos la opción:

vhv.enable = "true"

• Habilitar ESXi MAC Learning: añadimos las entradas para cada uno de los interfaces de red, por ejemplo, si tenemos 6 interfaces de red

ethernet0.filter4.name=dvfilter-maclearn
ethernet0.filter4.onFailure=failOpen
ethernet1.filter4.name=dvfilter-maclearn
ethernet1.filter4.onFailure=failOpen
ethernet2.filter4.name=dvfilter-maclearn
ethernet2.filter4.onFailure=failOpen
ethernet3.filter4.name=dvfilter-maclearn
ethernet3.filter4.onFailure=failOpen
ethernet4.filter4.name=dvfilter-maclearn
ethernet4.filter4.onFailure=failOpen
ethernet5.filter4.name=dvfilter-maclearn
ethernet5.filter4.onFailure=failOpen

• Arrancamos la máquina y entramos en la BIOS. Me suele gustar deshabilitar las opciones de Disqueteras, puertos serie…

En el caso de que guardemos la plantilla con un datastore ya creado, si vamos a añadirlo posteriormente a un servidor vCenter, tenemos que refirmar los datastores.

esxcli storage vmfs snapshot resignature -l [VMFS-VOLUME]

La entrada Creación de una imagen de VMware ESXi para laboratorio aparece primero en Maquinas Virtuales.

La entrada Preparando la certificación VMware VCAP5-DCA aparece primero en Maquinas Virtuales.

La entrada Puesta en marcha de servidor HP Microserver Gen8 aparece primero en Maquinas Virtuales.

La entrada IOS 8.1 y Mac OS X Yosemite Review aparece primero en Maquinas Virtuales.

Configurar Vshield Manager

vShield Manager

console to VM

username: admin

password: default

type “enable”

password: default

type “setup” then configure IP settings

http://IPorDNS

La entrada Configurar Vshield Manager aparece primero en Maquinas Virtuales.

http://www.kendrickcoleman.com/index.php/Tech-Blog/list-of-vmware-default-usernames-and-passwords.html

La entrada Listado de usuarios y passwords por defecto en productos VMware aparece primero en Maquinas Virtuales.

Android 5 y certificado raíz de la FNMT

Llevo varios días utilizando Android 5 en mi móvil, y aunque tenían pensado escribir una entrada compartiendo las sensaciones que tengo, voy a escribir antes sobre un “problema” que he detectado.

Con Android 5, a diferencia de versiones anteriores (por lo menos la versión 4.4) no se incluye por defecto el certificado de la FNMT en los certificados de confianza del sistema.

Podemos verlo comparando los certificados de confianza en un sistema con la versión 4.4 y en un sistema con la versión 5.

Este problema puede hacer que algunos servicios o aplicaciones que utilizan certificados de la FNMT dejen de funcionar.

Para solucionar el problema tenemos que añadir el certificado siguiendo estos pasos:

• Acceder a la página web de la FNMT para descargar el certificado raiz

https://www.sede.fnmt.gob.es/descargas/certificados-raiz-de-la-fnmt

• Guardar el archivo FNMTClase2CA.cer en el almacenamiento local del móvil
• Acceder a Ajustes -> Seguridad -> Instalar desde almacenamiento

• Seleccionamos el archivo FNMTClase2CA.cer

• Asignarle un nombre

• Comprobamos que ahora aparece en los certificados de confianza de Usuario

La entrada Android 5 y certificado raíz de la FNMT aparece primero en Maquinas Virtuales.

We hire people who want to make the best things in the world. -Steve Jobs

She must have hidden the plans in the escape pod. Send a detachment down to retrieve them, and see to it personally, Commander. There’ll be no one to stop us this time! You’re all clear, kid. Let’s blow this thing and go home! Partially, but it also obeys your commands.

• Dantooine. They’re on Dantooine.
• He is here.
• Don’t underestimate the Force.

I care. So, what do you think of her, Han? A tremor in the Force. The last time I felt it was in the presence of my old master. But with the blast shield down, I can’t even see! How am I supposed to fight? Obi-Wan is here. The Force is with him. But with the blast shield down, I can’t even see! How am I supposed to fight? You are a part of the Rebel Alliance and a traitor! Take her away!

You’re all clear, kid. Let’s blow this thing and go home! But with the blast shield down, I can’t even see! How am I supposed to fight? Alderaan? I’m not going to Alderaan. I’ve got to go home. It’s late, I’m in for it as it is.

La entrada iPhone 6 Plus review aparece primero en Maquinas Virtuales.

VMware vSphere 6 – ¿Qué novedades nos esperan?

En esta entrada voy a comentar algunas de las novedades que nos traerá la nueva versión de VMware vSphere 6 y que se han ido conociendo en los últimos meses, a la espera de que VMware la publique de forma definitiva en los próximos meses (o semanas? jeje).

VMware Fault Tolerance

A partir de la versión 6, FT podrá soportar máquinas con multiprocesador (hasta un máximo de 4) Desde que se publicó esta funcionalidad, había tenido la limitación de estar únicamente disponible para máquinas con un único procesador.  Y no sólo se quedan ahí los cambios en cuanto a Fault Tolerance

• Se ha sustituido “vLockstep” por “FT SMP Protocol” para realizar la comunicación entre la máquina activa y la máquina de respaldo.
• Cada máquina tendrá discos duros independientes, por lo que dejará de ser compartido entre las dos.
• Se requiere una red de 10Gbps

VMotion Anywhere

Hasta ahora existían varias limitaciones a la hora de utilizar VMotion de una máquina virtual, que con la versión 6 dejan de existir

• Podremos mover una máquina entre dos Datacenter de un mismo vCenter (hasta ahora solo podiamos mover entre entre dos clusters)
• Podremos mover una máquina entre dos vCenter. Será necesario conectividad de red de nivel 3.
• Podremos mover una máquina virtual entre vSwitch
• Podremos mover máquinas en redes con latencia de hasta 100ms de RTT. Hasta ahora el límite estaba en 10ms (5ms si no teniamos Metro vMotion)

Mayor escalabilidad

Como es casi común en todas las versiones, se aumentan los límites máximos de las máquinas virtuales, pero también otros límites:

• Máquinas virtuales con hasta 128 vCPUs y 4TB de RAM (64 vCPUs y 1TB actualmente). Incluye nueva versión de hardwware: vmx-11
• Clusters con hasta 64 hosts (de los 32 actuales) y hasta 6000 maquinas (4000 actualmente)
• Hosts con 480 CPUs y 12 TB de RAM (320 CPUs y 4TB actualmente)
• Se pasa de 512 a 1000 máquinas por host

Almacenamiento

Hay varias novedades en lo que al almacenamiento se refiere

• VVol: es un cambio en la integración con el almacenamiento. En resumen, este cambio lo que significa es que el almacenamiento es capaz de trabajar directamente con las máquinas virtuales y no tenemos Volumenes/LUNs (¿ya no tendremos más datastores o VMFS?
• Soporte de NFS v4.1 además de soportar también Kerberos como característica de NFS v4.1
• Evolución y mejoras de VMware VSAN.

Cliente

• Mejoras en el rendimiento del cliente web, incluyendo mejoras en la carga de páginas, inicio de sesión, menús… (creo que este lo dicen en todas las versiones)
• vSphere Host Client: si, se mantiene el cliente Windows y podrá editar máquinas con versión de hardware de la 8 a la 11

Virtual Datacenter

Hasta ahora, un Datacenter en la infraestructura vSphere, no tenía más funcionalidad que la de una carpeta que servía para organizar los hosts, clusters… Con la versión 6, podremos crear un “Virtual Datacenter”, de forma que podremos gestionar los recursos de los clusters con un nivel superior. Por simplificar, si hasta ahora un cluster era el nivel más alto a la hora de tener un pool de recursos, ahora tenemos una capa por encima que será el Virtual Datacenter.

Content Library

Es un repositorio especial que nos sirve de biblioteca para almacenar distintos elementos reutilizables como pueden ser las plantillas de máquinas virtuales, archivos ISO, vApps… Además estas liberías podrán estar sincronizadas entre distintos vCenter

Hasta aquí algunas de las novedades, de momento no hay fecha para la publicación de la versión vSphere 6 (¿alguna vez dice VMware una fecha de publicación de una versión? jeje), así que continuamos a la espera.

Para poder evaluar estas y otras funcionalidades, se puede hacer desde la Beta pública de vSphere 6

La entrada VMware vSphere 6 – ¿Qué novedades nos esperan? aparece primero en Maquinas Virtuales.

Monitorizar tráfico de red en VMware vSphere

El tener una infraestructura de virtualización nos aporta muchas posibilidades a la hora de trabajar con servidores virtuales, y una de ellas es facilitar el poder monitorizar el tráfico de red de los mismos, pero es importante conocer el funcionamiento de la red, así como las opciones de configuración que existen en los servidores VMware ESXi y en sus switch virtuales (ya sean standard o distribuidos).

Vamos a ver algunos ejemplos de configuración en los que capturar el tráfico existente en máquinas virtuales de la infraestructura.

Para estos ejemplos voy a utilizar algunas máquinas básicas con los siguientes datos:

• Máquinas virtuales con las que generar el tráfico
  • SRV01
    • Dirección IP: 10.0.6.1
    • MAC: 00:50:56:8e:6c:31
  • SRV02
    • Dirección IP: 10.0.6.1
    • MAC: 00:50:56:8e:0f:24
  • SRV03
    • Dirección IP: 10.0.6.1
    • MAC: 00:50:56:8e:97:d6
  • SRV05
    • Dirección IP: 10.0.6.1
    • MAC: 00:50:56:8e:ec:e5
• Sniffer con el que capturar el tráfico
  • SNIFFER01: es una máquina con Windows2012 y Wireshark
• Router
  • HALON01

Partimos de una situación muy sencilla, en la que tenemos 2 máquinas virtuales y queremos ver el tráfico existente entre ellas, con los siguientes puntos a tener en cuenta:

• Las dos máquinas virtuales se ejecutan en el mismo host ESXi
• Las dos máquinas virtuales tienen un interfaz de red conectado al mismo grupo de puertos (en este caso PG-INTERNA02)
• El grupo de puertos no tiene configuración de VLAN (y si la tiene utilizamos el modo VST – Virtual Switch Tagging)
• La configuración del vSwitch y del grupo de puertos es la configuración por defecto.
• El tráfico generado es tráfico ICMP (ping entre SRV01 y SRV03)

La imagen que veríamos en la configuración del vSwitch sería la siguiente:

En la máquina SRV01 ejecutamos un ping para generar el tráfico

Si vamos al sniffer y vemos el tráfico que estamos capturando vemos lo siguiente:

Efectivamente, no vemos ningún tráfico ICMP. Esto es así porque estamos utilizando la configuración por defecto del vSwitch y del grupo de puertos, así que vamos a explicar que es lo que está pasando.

Tanto el vSwitch como el grupo de puertos tienen 3 opciones de configuración relacionadas con la seguridad del tráfico de red, que son las siguientes (con su valor por defecto):

• Promiscuous mode: Reject
• MAC address change: Accept
• Forget transmits: Accept

En este caso, la opción que nos interesa es la primera, Promiscuous mode.

Este Promiscuous mode, deriva del modo en el que se configura una tarjeta de red para que procese todo el tráfico que recibe no sólo el que es para la máquina en la que se encuentra. Normalmente, este modo de configuración de la tarjeta de red, es el utilizado en las máquinas que capturan tráfico.

Así pues, podemos establecer la configuración Promiscuous mode en 3 elementos:

• Tarjeta de red a nivel de sistema operativo de la máquina virtual
• Grupo de Puertos
• vSwitch

En la tarjeta de red, el modo Promiscuous ya está habilitado pero no recibimos ningún tráfico, vamos a ver por qué.

En la configuración por defecto, esto es, con Promiscuous mode en Reject, la tarjeta de red de una máquina virtual sólo recibe el tráfico que es para esa máquina virtual, por así decirlo el vSwitch se comporta como un switch clásico, y por esto, nuestra máquina sniffer no es capaz de capturar ningún tráfico.

¿Qué pasa si cambiamos la configuración y ponemos Promiscuos mode en Accept?

Si hacemos el cambio y ponemos la configuración del grupo de puertos en modo Accept (sobreescribiendo la configuración por defecto del vSwitch)

Ahora vamos al sniffer y vemos que si comienza a capturar tráfico

Esto es así, ya que al habilitar el modo Promiscuous en el grupo de puertos, ahora el vSwitch entrega cada paquete que va a una máquina de ese grupo de puertos, a todas las tarjetas conectadas al mismo.

El habilitar el modo Promiscuous a nivel de grupo de puertos o a nivel de vSwitch, no cambia el comportamiento, la única diferencia, es la granularidad de la configuración, si hacemos un cambio a nivel de vSwitch, lo podemos aplicar a todos los grupos de puertos de una forma muy rápida. El hacerlo a nivel de grupo de puertos, permite tener un mayor control de que configuración se aplica a cada uno de ellos.

Así pues los pasos serían:

• Cambiar el modo Promiscuous en el grupo de puertos en el que se encuentran las máquinas virtuales
• Ubicar un interfaz de red de captura del sniffer en ese grupo de puertos

La entrada Monitorizar tráfico de red en VMware vSphere aparece primero en Maquinas Virtuales.

En la entrada anterior vimos una forma sencilla para monitorizar el tráfico entre dos máquinas virtuales, pero no es una solución óptima, así que vamos a ver como mejorarlo.

Por el funcionamiento de un vSwitch, cuando recibe un paquete, este comprueba la etiqueta de VLAN (si la tiene) y lo envía al grupo de puertos (o grupos, ya que pueden ser varios con la misma configuración)  que tienen esa configuración de VLAN.

Conociendo esto, y partiendo de nuestra configuración de máquinas, vamos a crear un nuevo grupo de puertos, específico para la monitorización de la red con nuestro sniffer, y para ver un ejemplo un poco más completo, las dos máquinas virtuales ahora están en distintos grupos de puertos (aunque en la misma red lógica)

En este caso, tanto el vSwitch, como todos los grupos de puertos tienen Promiscuous mode en Reject.

Todos los paquetes de la comunicación entre las máquinas SRV01 y SRV03, también son enviadas para ser procesadas al grupo de puertos PG-SNIFFER, pero como  la configuración de Promiscuous mode es Reject, no vemos ningún paquete.

Para poder ver los paquetes, lo único que tenemos que cambiar es la configuración del grupo de puertos PG-SNIFFER

Y ahora si volvemos a ver el tráfico

De esta forma, ya puedo monitorizar TODO el tráfico de una misma red, independientemente de la configuración del grupo de puertos con sólo hacer estos pasos:

• Crear un grupo de puertos y habilitar el modo Promiscuous
• Ubicar un interfaz de red de captura del sniffer en ese grupo de puertos

De esta forma no tenemos que cambiar la configuración de todos los grupos de puertos, ni nos restringimos a uno específicamente para poder monitorizarlo.

Hemos mejorado, pero, ¿que pasa si queremos monitorizar varias redes? ¿tenemos que crear un grupo de puertos para cada una de las redes y tener un interfaz del sniffer en cada uno? Pues vamos a ver como hacerlo, con un ejemplo similar.

Ahora vamos a utilizar una nueva máquina (SRV05) que se encuentra ubicada en otra red diferente (Grupo de puertos: PG-INTERNA03, VLAN 103)

En este caso, tenemos otra máquina más (HALON01) que se encarga de enrutar el tráfico entre las dos redes (red con VLAN 103 y red sin VLAN).

Así pues ahora el tráfico hace el siguiente camino:

• SRV01 -> HALON01 -> SRV05
• SRV05 -> HALON01 -> SRV01

Si mantenemos esta configuración y el grupo de puertos PG-SNIFFER sigue en modo Promiscuous, al monitorizar el tráfico vemos los siguientes paquetes

Si accedemos al detalle de cada paquete, vemos los paquetes Request y Reply, pero solo vemos los que se generan en la red sin VLAN, esto es el tráfico entre SRV01 y HALON01 (el router). No vemos el tráfico entre el router y SRV05. Esto es así porque el grupo de puertos donde se encuentra el interfaz de captura del sniffer pertenece a la red sin VLAN.

Para poder ver todo el tráfico tenemos que cambiar la configuración del grupo de puertos del sniffer y utilizar la VLAN 4095. Esta VLAN está reservada y permite indicar que el grupo de puertos está conectado a TODAS las VLANs

De esta forma nuestro sniffer recibe el tráfico de TODAS las VLANs y al estar en modo Promiscuous, recibe el tráfico de TODAS las máquinas virtuales del host ESXi. Si comprobamos la captura:

Vemos que ahora si vemos todos los paquetes de las dos redes involucradas.

Así pues la configuración final para poder monitorizar tráfico de red en un servidor ESXi sería:

• Crear un grupo de puertos específico para la monitorización con la siguiente configuración
  • VLAN 4095
  • Promiscuous mode: Accept
• Ubicar un interfaz de captura de la máquina virtual sniffer en este grupo de puertos

Esto sería válido para cada vSwitch que tengamos. Si tenemos varios vSwitch con máquinas virtuales a monitorizar, tendríamos que crear un grupo de puertos por cada vSwitch.

La entrada Monitorizar tráfico de red en VMware vSphere (II) aparece primero en Maquinas Virtuales.

En las dos entradas anteriores (parte I y parte II) hemos visto como monitorizar el tráfico de red si tenemos vSwitch standard, pero ¿qué pasa si tenemos vSwitch distribuidos?

A la hora de crear un grupo de puertos en un dvSwitch, tenemos varias opciones para configurar el tipo de VLAN

• VLAN
• VLAN trunking
• Private VLAN

En este caso tenemos, si queremos monitorizar todas las redes desde un mismo punto, tenemos que elegir la opción VLAN trunking e indicar el valor 0 – 4094

En el caso de los dvSwitch, tenemos un nivel más en el que configurar el modo Promiscuous, ya que además de a nivel de grupo de puertos, lo podemos configurar a nivel de puerto, esto es, a nivel de la conexión de cada máquina virtual.

De esta forma, podemos afinar un poco más, y habilitar el modo Promiscuous sólo en el interfaz de captura que utiliza el sniffer, no a nivel de grupo de puertos.

Hemos visto lo que sería una solución similar a cuando tenemos vSwitch estandar, pero en lo que es la monitorización de la red cuando tenemos dvSwitch, tenemos opciones que se han implementado específicamente para este objetivo.

Port Mirroring

Con Port Mirroring básicamente lo que se hace es copiar los paquetes de un puerto a otro puerto del dvSwitch. Esto nos permite centrar la monitorización en una (o varias) máquinas en concreto, de forma que podamos “copiar” todo el tráfico que recibe y envía esa máquina virtual para procesarlo con la herramienta correspondiente.

Tenemos el concepto de máquina o puerto origen y máquina o puerto destino.

Para poder utilizar Port Mirroring seguimos los siguientes pasos

• Creamos una nueva sesión

• Seleccionamos el tipo Distributed Port Mirroring

• Indicamos el nombre y las opciones básicas (podemos dejarlas por defecto)

• Seleccionamos la máquina o máquinas origen.

• Tras añadir la máquina origen, podemos seleccionar el tipo de tráfico, tráfico entrante (Ingress), tráfico saliente (Egress) o ambos (Ingress/Egress)

• Seleccionamos la máquina de destino, en nuestro caso el SNIFFER01

• Finalizamos el asistente

• Vemos la seisión creada.

Tras crear la configuración de Port Mirroring, podemos comprobar que funciona correctamente capturando el tráfico en el sniffer.

Pese a que se utiliza dvSwitch, con Port Mirroring, si nuestra herramienta de monitorización es virtual, seguimos estando limitados a poder monitorizar únicamente el tráfico de un único host, de forma que  tendremos que crear una regla DRS para que la máquina origen y destino se ejecuten siempre en el mismo host ESXi.

Con Port Mirroring también podemos “copiar” el tráfico entre otros orígenes y destinos, no solo entre máquinas virtuales

• Remote Mirroring Source: el destino es un uplink al que enviar el tráfico
• Remote Mirrofing Destination: permite seleccionar una VLAN (o varias) como origen del tráfico
• Encapsulated Remote Mirroring (L3) Source: permite enviar el tráfico a un destino a través de una dirección IP

NetFlow

Es un protocolo de red que permite enviar el tráfico que está gestionando un dvSwitch a un analizador (collector) donde se reciben los datos y se procesan para su posterior estudio.

La configuración es muy sencilla y se debe realizar por dvSwitch.

Indicamos la dirección IP del recolector, el puerto, y la IP que se le va a asignar al dvSwitch para que el recolector pueda obtener el tráfico generado.

Y habilitamos el grupo de puertos o grupo de puertos para los que queremos habilitar Netflow

Una vez configurado el dvSwitch, vamos al analizador de tráfico compatible con Netflow, y configuramos el dispositivo para obtener el tráfico, por ejemplo PRTG

Nota: para ver de forma completa como configurar PRTG podemos ver un ejemplo de Jorge de la Cruz en esta dirección: http://www.paessler.com/blog/2014/08/15/monitoring-knowledge/netflow-configuration-and-monitoring-via-prtg-on-vmware-vsphere

Referencias:

kb.vmware.com/kb/1002934

kb.vmware.com/kb/1004099

http://en.wikipedia.org/wiki/Promiscuous_mode

http://blogs.vmware.com/vsphere/2013/01/vsphere-5-1-vds-feature-enhancements-port-mirroring-part-1.html

http://blogs.vmware.com/vsphere/2011/08/vsphere-5-new-networking-features-netflow.html

La entrada Monitorizar tráfico de red en VMware vSphere (III) aparece primero en Maquinas Virtuales.

Tras ver en las anteriores entradas información sobre como monitorizar tráfico de red en una infraestructura VMware vSphere, vamos a ver a modo de resumen, cuales son las opciones que hemos visto:

• Si tenemos vSwitch standard
  • Crear un grupo de puertos específico para monitorización
  • Habilitar en ese grupo de puertos Promiscuous mode
  • Indicar la VLAN 4095 para poder monitorizar todas las redes
  • Añadir a este grupo de puertos el interfaz de captura de la máquina que vamos a utilizar para obtener el tráfico
  • Sólo podemos monitorizar el tráfico de las máquinas que se encuentran en el mismo host ESXi que la máquina que captura el tráfico.
  • Obtenemos el tráfico de toda la red, en el analizador tendremos que filtrar el tráfico de la máquina que nos interesa

• Si tenemos dvSwitch
  • Grupo de puertos de monitorización (similar al caso de vSwitch)
    • Crear un grupo de puertos específico para monitorización
    • Habilitar en ese grupo de puertos Promiscuous mode
    • Indicar el tipo VLAN Trunk con el valor 0-4094 para poder monitorizar todas las redes
    • Añadir a este grupo de puertos el interfaz de captura de la máquina que vamos a utilizar para obtener el tráfico
    • Sólo podemos monitorizar el tráfico de las máquinas que se encuentran en el mismo host ESXi que la máquina que captura el tráfico
    • Obtenemos el tráfico de toda la red, en el analizador tendremos que filtrar el tráfico de la máquina que nos interesa
  • Port Mirroring, cuando queramos monitorizar una máquina concreta.
    • Crear una sesión con:
      • Origen la máquina o máquinas que queremos monitorizar
      • Destino la máquina que va a realizar el análisis
    • Podemos también enviar al tráfico a elementos externos, de forma que el analizador no tiene por que ser virtual.
    • Seguimos teniendo la limitación de solo poder monitorizar el tráfico de las máquinas que se encuentran en el mismo host ESXi que la máquina que captura el tráfico
  • NetFlow: cuando queremos enviar TODO el tráfico a un recolector externo

Monitorizar tráfico de red en VMware vSphere

Monitorizar tráfico de red en VMware vSphere (II)

Monitorizar tráfico de red en VMware vSphere (III)

La entrada Monitorizar tráfico de red en VMware vSphere (IV y final) aparece primero en Maquinas Virtuales.

Como administradores de sistemas es común el utilizar herramientas que nos faciliten el poder trabajar con múltiples servidores, realizar distintos tipos de conexiones (RDP, SSH…)  comprobar conexiones… y una de mis herramientas favoritas es Remote Desktop Manager.

Para comenzar, indicaré algunas de las características de Remote Desktop Manager:

• Conexiones remotas de distintos tipos: RDP, SSH, VNC, Dameware, Citrix…
• Repositorio de credenciales que nos permiten guardar usuarios y contraseñas y utilizarlos en las distintas conexiones
• Permite realizar conexiones VPN
• Múltiples Add-ons que permiten ampliar la funcionalidad y utilizar e integrar herramientas de terceros
• Permite importar sesiones de otras herramientas
• Integración con distintos navegadores (IE, Chrome, Firefox)
• Permite conectarse a infraestructuras de virtualización (VMware, Hyper-V…)
• Gestión de documentos

En este enlace se pueden ver el listado completo de las caractéristicas de Remote Desktop Manager.

En resumen, una aplicación muy potente. Para poder probarla podemos descargarla e instalarla y probarla durante 30 días. El problema de esta prueba, es que visto todo lo que puedes hacer con ella, cuando termine ese periodo no podrás vivir sin ella, y tendrás que comprar la licencia. Como alternativa, puedes utilizar la versión gratuita, eso sí, con características limitadas.

Aquí podemos ver una comparativa de las ediciones Free Edition y Enterprise.

Os dejo con unas capturas de pantalla de la versión gratuita.

La entrada Remote Desktop Manager aparece primero en Maquinas Virtuales.

Si utilizamos Windows 2012 R2 como sistema operativo servidor (esta entrada también es aplicable a Windows 2008, Windows 7, Windows 8), conforme pasan los días, instalamos componentes, actualizamos parches… vemos que el tamaño de la unidad C, va creciendo y vamos acumulando gigas y gigas de archivos.

Hoy vamos a ver algunas formas de reducir el tamaño de la carpeta WinSxS, que es uno de los principales responsables de este aumento de tamaño, así que vamos a responder primero a unas sencillas preguntas:

¿Qué contiene el directorio WinSxS?

El directorio WinSxS (Windows Side-by-Side o Component Store) contiene archivos utilizados por Windows en distintas ocasiones:

• Contiene los archivos de instalación de los distintos componentes y roles de windows de forma que ante una instalación no sea necesario disponer del DVD de instalación o el instalador obtenga los archivos de esta carpeta.
• Se utiliza como backup cuando se instalan actualizaciones con Windows Update de forma que si es necesario, podamos desinstalarlas y volver a utilizar las versiones anteriores de los archivos utilizados.
• Utiliza estos archivos en caso de tener que reparar algún archivo del sistema corrupto

¿Dónde se encuentra?

En la carpeta de instalación de Windows, generalmente C:\Windows\WinSxS

¿Puedo borrar el directorio WinSxS?

No

¿Puedo reducir el tamaño de WinSxS?

Si, básicamente de dos formas:

• Eliminando los archivos de instalación de roles y características
• Eliminando archivos de backup de actualizaciones de Windows

Eliminar archivos de instalación de roles y características

Cuando queremos añadir un nuevo rol o característica de Windows, se utilizan los archivos de instalación que se encuentran en la carpeta WinSxS.

Si ejecutamos el comando Get-WindowsFeature (en una sesión PowerShell) vemos el listado de características de Windows y su estado.

En el estado de las características vemos 3 estados principalmente:

• Installed: la característica está instalada
• Available: la característica no está instalada pero los archivos están disponibles para su instalación
• Removed: la característica no está instalada y los archivos no están disponibles para su instalación

Para eliminar los archivos de las características que no necesitamos, podemos hacerlo una a una o de forma general para todas las disponibles, por ejemplo con el comando:

Get-WindowsFeature | Where-Object InstallState Available | Uninstall-WindowsFeature -Remove

Después de ejecutar el comando podemos ver que el estado de las características ha cambiado

Con este comando ahorramos aproximadamente 1GB de espacio en el disco.

Tras ejecutar este comando, cuando queramos instalar una nueva característica a nuestro servidor tendremos que proporcionar los archivos de una de las siguientes formas:

• Con el DVD de instalación
• Indicando en la instalación la ruta a una carpeta con el archivo install.wim
• Indicar el archivo install.wim en una GPO
• Utilizar Windows Update

Eliminar archivos de backup de actualizaciones de Windows

Cuando instalamos Windows 2012 R2 y aplicamos los parches y actualizaciones, vemos que podemos tener hasta casi 100 actualizaciones (a diciembre de 2014) y prácticamente 2GB de tamaño de descarga.

Para poder analizar el tamaño de la carpeta WinSxS y ver su evolución con la instalacíon de las actualizaciones, utilizamos el comando

dism /Online /Cleanup-Image /AnalyzeComponentStore

Podemos comparar el antes de la instalación de las actualizaciones

Y el después

Vemos que se ha aumentado en casi 6GB.

Para reducir este tamaño podemos eliminar las versiones anteriores de los archivos actualizados ejecutando

dism /Online /Cleanup-Image /StartComponentCleanup

Tras la ejecución de este comando, vemos que hemos reducido en prácticamente 4GB el espacio ocupado por la carpeta WinSxS

Y si queremos ir un paso más, y estamos seguro que nuestra imagen de Windows es correcta, podemos ejecutar el comando

dism /Online /Cleanup-Image /StartComponentCleanup /ResetBase

De esta forma ya no podremos desinstalar las actualizciones

A modo de resumen una tabla con los distintos tamaños tras ejecutar distintos comandos de “limpieza”

La entrada Tamaño de WinSxS en Windows 2012 R2 aparece primero en Maquinas Virtuales.

Error “El administrador de sistema limitó el número de equipos en los que puede iniciar una sesión”

El otro día me encontré con un problema al limitar a unos usuarios su acceso a ciertos equipos a través de directorio activo en Windows 2012 R2.

Las pruebas habían sido correctas desde un cliente RDP en MAC, pero no había probado con un cliente WINDOWS, dando por hecho que iba a funcionar igualmente.

Se generaba el error que da nombre al post:

Os cuento el esquema de conexión. Los clientes se conectan a un cloud por OPENVPN, se loguean perfectamente.

Tienen acceso como administradores locales a dos servidores concretos, impidiéndoles el resto de accesos. Pero al hacer RDP nos encontrábamos con el error.

Encontré una solución para resolver este problema…

Abrimos la aplicación de escritorio remoto:

Luego guardamos un fichero RDP con la conexión que queramos lanzar:

Editamos el fichero con Notepad++:

Y simplemente añadimos en la última línea el parámetro “enablecredsspsupport:i:0“:

Con esta solución resolvemos el problema de una forma rápida.

La entrada Error “El administrador de sistema limitó el número de equipos en los que puede iniciar una sesión” aparece primero en VMware Blog.