Archivo de la categoría: VMWare

NFSv4 y ESXi, de verdad de la buena

NFSv4
Currently, there are three versions of NFS. NFS version 2 (NFSv2) is older and is widely supported. NFS version 3 (NFSv3) supports safe asynchronous writes and a more robust error handling than NFSv2; it also supports 64-bit file sizes and offsets, allowing clients to access more than 2Gb of file data.

NFS version 4 (NFSv4) works through firewalls and on the Internet, no longer requires an rpcbind service, supports ACLs, and utilizes stateful operations. Red Hat Enterprise Linux 6 supports NFSv2, NFSv3, and NFSv4 clients. When mounting a file system via NFS, Red Hat Enterprise Linux uses NFSv4 by default, if the server supports it.

All versions of NFS can use Transmission Control Protocol (TCP) running over an IP network, with NFSv4 requiring it. NFSv2 and NFSv3 can use the User Datagram Protocol (UDP) running over an IP network to provide a stateless network connection between the client and server.

When using NFSv2 or NFSv3 with UDP, the stateless UDP connection (under normal conditions) has less protocol overhead than TCP. This can translate into better performance on very clean, non-congested networks. However, because UDP is stateless, if the server goes down unexpectedly, UDP clients continue to saturate the network with requests for the server. In addition, when a frame is lost with UDP, the entire RPC request must be retransmitted; with TCP, only the lost frame needs to be resent. For these reasons, TCP is the preferred protocol when connecting to an NFS server.

The mounting and locking protocols have been incorporated into the NFSv4 protocol. The server also listens on the well-known TCP port 2049. As such, NFSv4 does not need to interact with rpcbind[2], lockd, and rpc.statd daemons. The rpc.mountd daemon is still required on the NFS server to set up the exports, but is not involved in any over-the-wire operations.

Fuente: http://forums.nas4free.org/viewtopic.php?t=259
NAS4Free soporta NFSv4, pero se ha de activar usando el checkbox. Sólo se podrán conectar los ESXi 6.0 o superiores.
Cómo activar NFSv4 en FreeBSD 9.1:
http://plone.lucidsolutions.co.nz/storage/network/nas4free/enable-nfs-v4-on-nas4free-v9.1/view

 

NFSv4 y ESXi

ESXi 5.5 no soporta NFSv4. Sólo NFSv3, el cual va por UDP.

ESX 6.0 sí soporta NFSv4.1:
If you are using NFS storage for VMs (either on a hardware NAS box or hosted on a VM) with your ESXi hosts then you might be interested in the new support for NFS version 4.1. Version 4.1 has superior new features (state management, improved locking, Kerberos authentication) and can be much more efficient and performant than 3.0 (which was exclusively supported with ESXi 5.x), but that depends very much on the client implementation. Time and the performance tests to come will tell how much you can gain from it with ESXi.

NAS4Free soporta NFSv4, pero se ha de activar usando el checkbox. Sólo se podrán conectar los ESXi 6.0 o superiores.

Guías de buenas práctica spara conectar ESXi a NFS:

NFS Best Practices – Part 1: Networking

NFS Best Practices – Part 2: Advanced Settings

Con ESXi 6.0 y NFSv4 ya se puede hacer un balanceo de carga accediendo al NFS por varias IPs. Antes todo el datastore NFS se comunicaba por una única conexión TCP/IP. En el NAS4Free podríamos usar LAACP para que pueda ser accedido por dos ips distintas: https://www.youtube.com/watch?v=4d_-JZyvdgw

Multipathing and Load-balancing:
Now onto the improvements. NFS v4.1 introduces better performance and availability through load balancing and multipathing. Note that this is not pNFS (parallel NFS). pNFS support is not in vSphere 6.0.
Setup NFSv4.1 datastoreIn the server(s) field, add a comma separate list of IP addresses for the server if you wish to use load-balancing and multipathing.

Fuente: http://cormachogan.com/2015/02/04/vsphere-6-0-storage-features-part-1-nfs-v4-1/


Instalando o actualizando las VMWare Tools en VM Linux

Fuente:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2016867

 

– en ESX: Vaya a Virtual Machine > Install VMware Tools (o VM > Install VMware Tools).
– y ahora en la VM, entrando por SSH o consola:

– dir /dev/cd*
– ahí vemos que el dispositivo correcto es: /dev/cdrom
– sudo mount /dev/cdrom /media/cdrom
– ls /media/cdrom
– tar xzvf /media/cdrom/VMwareTools-*.tar.gz -C /tmp/
– cd /tmp/vmware-tools-distrib/
– sudo ./vmware-install.pl -d
– rm -fr /tmp/vmware-tools-distrib/

– apagamos el equipo
– en sus propiedades de VM en ESX marcamos que haga shutdown del guest al darle al botón, suspend y restart del guest al darle esos botones, también. Además, que sincronice la fecha y hora con el host.
– marcamos que sincronice la hora entre el host y el guest
– marcamos que verifique que las vmwaretools estén actualizadas al arrancar.
– lo arrancamos de nuevo.


Actualizar ESXi standalone a última versión 4 de julio de 2014

Vamos a actualizar el ESXi a la última versión con patchlevel del 4 de julio de 2014, via consola, sin CD usando interent:

 

  1. Apagar todas las VMs
  2. Abrir una ventana SSH para ir viendo el log del progreso:
    # tail -f /var/log/esxupdate.log
  3. Abrir otra ventana SSH
  4. Poner el ESXi en maintenance mode:
    # vim-cmd /hostsvc/maintenance_mode_enter
    o viclient as root via esxi console … Summary Commands … enter maintenance mode
  5. Ver qué versión hay actualmente instalada:
    # vmware -v
    VMware ESXi 5.0.0 build-474610 (o la que sea actualmente instalada)
  6. Abrir el firewall para que el ESXi pueda descargarse cosas de internet:
    # esxcli network firewall ruleset set -e true -r httpClient
  7. Con esto vemos el listado posible de “profiles” para instalar:
    # esxcli software sources profile list -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml
  8. Hemos seleccionado el último “standard” con las vmware-tools incluidas:
    # esxcli software profile update -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml -p ESXi-5.5.0-20140704001-standard
  9. Ahora toca mirar la ventana SSH donde hemos abierto el log para ver el progreso
  10. Cuando vuelva a la vida la ventana SSH donde ejecutamos el comando del update, reiniciamos:
    # reboot
  11. Cerramos la primera ventana SSH.
  12. Recuperamos la ventana SSH restante y cerramos de nuevo el firewall:
    # esxcli network firewall ruleset set -e false -r httpClient
  13. Comprobamos la versión instalada:
    # vmware -v
    VMware ESXi 5.5.0 build-1623387 (o a la que se haya actualizado)
  14. Sacamos al ESXi del maintenance mode:
    # vim-cmd /hostsvc/maintenance_mode_exit
    o viclient as root via
    esxi console … Summary Commands … exit maintenance mode

 

HITO: actualizado ESXi a 5.5 U1 con patchlevel del 4 de julio de 2014: ESXi-5.5.0-20140704001-standard

Actualizar las vmware-tools según sea necesario. Si fallan en automático, reiniciar la VM y reintentar. Se ve en el status del viClient.

 

Fuentes:

 

 


DRS en accción: el VMWare se pone verde

Esto de ponerse verde, que nadie me malinterprete, se debe a la “moda” (necesaria o no para un producto concreto) de ser ecológico, bien sea por la vía moral o por la interesada.

La vía moral se basa en el interés por proteger lo poco que nos queda de medioambiente y, como segundo objetivo,  tratar de dar marcha atrás en el casi finalizado proceso de destruccción de nuestro planeta: el punto de no retorno. Esto es, el principio del irremediable fin: la imparable reacción en cadena.

La vía interesada es la más común: reducción de costes de producción o etiquetas de marketing para vender más. A esta la “aceptamos como barco”, pues lleva implícita su ayuda a los fines de la primera vía. Si es que en este tipo de soluciones de conveniencia está el futuro del ser humano, está claro. Somos unos interesados por naturaleza. Yo personalmente “no lo soy”; me declaro tonto del culo y punto.

Tras este speech, pasemos al lado menos freak con otro aporte a la categoría VMWare.

El VMWare, el más avanzado (y caro) de los sistemas de virtualziación, permite consolidar (colocar varias máquinas físicas convertidas a virtuales sobre una sola máquina física) servidores de nuestro centro de datos. Eso ya supone un ahorro de energía (en cuanto a consumo de máquinas y refrigeración y fabricación de hardware), ya que maximiza el aprovechamiento de la máquina física, eliminando los costes residuales de mantener un equipo encendido, aunque no esté haciendo “nada”.

Pero VMWare ha ido más allá y en su VMWare Infraestructure 4 ha agregado otro “protocolo” más a su enorme pila: el Distributed Resource Scheduler (DRS pa los amigos).

Básicamente usa los protocolos inferiores (incluido VMotion) para consolidar máquinas virtuales en el menor número de máquinas físicas, garantizando la capacidad de proceso mínima y sin perder la disponibilidad de los servicios en el proceso de consolidación.

Es decir, que si tenemos 10 nodos (máquinas físicas con ESX instalado que forman una “granja” de VMWare)  con 50 máquinas virtuales repartidas entre ellos dando tiza en horario de oficina, al llegar la noche, vamos a tener 15 nodos “vacíos” de carga de proceso. Podríamos reunir (consolidar) las máquinas virtuales en un menor número de nodos, durmiendo los sobrantes.

Esta tarea la podríamos hacer a mano usando el VMotion. Pero DRS nos lo automatiza. En cuanto detecta que puede consolidar, se pone a ello, realizando el proceso inverso cuando se le pida más “chicha”.

Un vídeo vale más que mil palabras 😉
http://www.youtube.com/watch?v=7CbRS0GGuNc&feature=fvw

Fuentes:


Ampliando el disco virtual de una VM en VMWare

Lo que mayormente viene a denominarse aumentar el tamaño del fichero VMDK.

Quién no se ha quedado sin espacio en disco en algún servidor virtualziado de desarrollo alguna vez?¿. Pues con este método se puede aumentar el disco de “la misma forma” que lo haríamos sustituyendo en una máquina física el disco viejo por uno nuevo más grande.

 

Fuente: