vCenter Server Reduced Downtime Upgrade

I have seen some questions coming in about Reduce Downtime Upgrade features lately, so I figured I’d share some more information about this. This feature was introduced in vSphere 7.0 Update 3 and it provides a new way of doing migration based upgrades for vCenter servers.

Reduced Downtime Upgrade (RDU) simplifies the migration process and reduces downtime (as the name implies) for vCenter while the data is being moved/copied from the old vCenter to the new vCenter. So the only downtime happens when the services on the old vCenter are stopped and started on the new vCenter. The data is copied almost in a vMotion type of way. Pretty slick.

The main question I see is: Does this apply to all deployment types including On-Premises and Cloud deployments?

The answer is NO. This feature (as of right now) only applies to VMC on AWS and Project Arctic. So for now, RDU is not available/supported for on-premises deployments, but that’s not to say it will never be supported on-premises in the near future. Also RDU is only available via API at the moment, and for the VMC on AWS and Project Arctic use cases, the vCenter upgrade is done by VMware Site Reliability Engineers (SRE), so you as a customer don’t need to worry/trigger the upgrade/update of vCenter server. You can safely pass the burden on to the SREs. That alone can justify moving to VMware’s Project Arctic offering when available IMHO.

Hopefully this post answers some questions. For more information refer to the official blog post here.

HTML 5 – vSphere and ESXi Host Web Clients

H5The wait is over (almost). Since the introduction of vSphere Web Client, many admins have slowed down the adoption of the Web Client as well as updates to vSphere due to the performance of said client.

VMware has released a couple of flings in relation to this problem. One of them was the host web client, where you can manage your hosts directly without the need to install the vSphere client. This fling is now part of the latest update to vSphere 6.0 U2. A few days ago, VMware released a similar option for vCenter. Both of these options are based on HTML 5 and javascript.

Host Web Client

Like I mentioned before, starting with vSphere 6.0 U2, the host web client is already embedded into vSphere. If you do not have this update you can still download the OVA and access the host web client that way. Currently it only works if you have vSphere 6.0+ but once version 5.5 U3 is released, it will also work with that version. Here is a link to download the fling.

To access the web client, you will need to add “/ui” at the end of the name/ip address of your host. For example https://<host-name-or-IP>/ui

The client is very responsive and has a nice UI. Not all the features are currently supported, but more will be coming at some point in the near future.

host_ui

 

vCenter Web Client

This HTML web client is only available as a fling at the moment. You will need to deploy an OVA and register the appliance with the vCenter that you would like to manage. Being a fling, not all features are included. It basically focuses on VM management, but I am sure they are working to port all the features over at some point (I hope).

To deploy this ova, you will need to enable SSH and Bash Shell on your VCSA. You can do both from the VCSA web UI. If you are running Windows based vCenter refer to the Fling documentation here.

vcsa_uI-shell

Prior to going through the configuration you will need to

  1. Create an IP Pool (If deploying via C# Client)
    • Note: I deployed using Web Client and didn’t create the IP Pool for me automatically as it is supposed to, so double check you have an IP Pool before powering on the appliance
  2. Deploy the OVA

IP_Pool

After deploying the OVA, creating an IP Pool, and enabling both SSH and Bash Shell on VCSA, it is time to configure the appliance.

  • SSH to the IP address you gave to the appliance using root as the user and demova as the password
  • Type shell to access Bash Shell
  • run the following command in Bash Shell
    • /etc/init.d/vsphere-client configure –start yes –user root –vc <FQDN or IP of vCenter> –ntp <FQDN or IP of NTP server>
  • If you need to change the default password for your root account, you can run the following command from bash shell
    • /usr/bin/chsh -s “/bin/bash” root
  • answer the question by answering YES
  • and enter the credentials for your vCenter


H5_deploy1

H5_deploy2

 

The HTML Web Client is pretty awesome, I gotta say, even if not all the features are there yet. It is super clean, and responsive. I can’t wait for it to be embedded with a full feature set.

 

H5_1

H5_2

Migración de Alarmas de vCenter

Alarmas juegan un papel muy importante en vCenter con el fin de mantener a los administradores de VMware consciente de lo que está pasando con sus entornos. Incluso si usted tiene vCOPS configurados, todavía personalmente gustaría tener las definiciones de alarma establecidos, especialmente en el caso de que el vCOPS vApp está apagado, etc.

Uno de los casos de uso para la migración de definición de alarma es la creación de un nuevo vCenter, o simplemente querer tener todos vCenters configurados con las mismas alarmas. Usted puede hacer todo esto manualmente, pero Si ha definido las definiciones de alarma en el pasado, usted ya sabe de esto una tarea que consume mucho tiempo y las nuevas versiones de vCenter incluyen cada vez más las alarmas a medida que se introducen nuevas versiones. Usted también puede tener sus propias alarmas, en cuyo caso, tiene sentido tener un método para copiar tal definición cuando sea necesario.

VMware tiene un artículo de KB con un guión que data de la versión 4.x. He utilizado este guión, que funciona bien, pero deja un par de pequeños detalles que pueden pasarse por alto, especialmente con las personas con poca o ninguna experiencia con Power Shell y PowerCLI. En KB1032660 VMware tiene un script que puede hacer esto para usted, todo lo que tienes que hacer es editar el script y ejecutarlo. Sin embargo, la imagen muestra el botón PowerShell ISE “correr” para la captura de pantalla. En un entorno “fuera de la caja”, esto fallará. ¿Por qué? Debido a que este script requiere cmdlets PowerCLI (connect-viserver, etc.) y los que no forman parte de PowerShell ISE a menos de importar los complementos de forma manual, lo que es totalmente factible.

Error

 

 

Para hacer el script trabajar, tendrá que agregar el PSSnapins o ejecutar el script desde PowerCLI. La forma más fácil es simplemente ejecutar el script desde PowerCLI. Aunque esto se explica por sí, voy a mostrar cómo hacer para hacer eso.

Información general:

  • Descarga la última versión de PowerCLI de descargas de VMware que responden a su entorno
  • Descarga el guión desde el sitio de VMware KB1032660
  • Abra el script utilizando PowerShell ISE, bloc de notas, libreta ++, o su editor de elección
  • Editar las variables de $ VC1 y $ vc2 y la línea 92 a (verdadero), a continuación, guarde la secuencia de comandos

variables

ifTrue

 

 

 

  • Abrir PowerCLI
  • Vaya a la ubicación donde guardó la secuencia de comandos y ejecutar el script desde allí

navigate

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  • Usted recibirá un par de indicaciones, acaba de golpear Y [por defecto]

En este punto usted debe ver todas las alarmas vCenter copiados al servidor vCenter objetivo. A medida que agrega alertas a su vCenter fuente, puede utilizar este script para guardar todos sus vCenters sincronizados hasta VMware viene con esta herramienta.

¿¡¿¡Solicitud de función!?!?

Deploying VCSA 6.0: Mind the Gap

VMware’s VCSA 6.0 brings a lot of enhancements compared to previous versions. I would seriously consider deploying VCSA in a production environment in order to replace the Windows flavor. For those not familiar with VCSA, this is the virtual appliance option to deploy vCenter in an environment. It reduces the time needed to deploy vCenter and offers an integrated database for no additional cost. Although this post may not be entirely technical, it will allow you to be aware of possible constraints that will prevent you from deploying VCSA before you invest too much time on it.

One of the great things about deploying VCSA over the Windows vCenter is that you will reduce the cost by not deploying a Windows VM as well as having to purchase an MSSQL license. VCSA sounds great so far, but there are some gaps that you need to be aware of before deploying this in an environment.

 

VCSA_mind_the_gap

Some of the shortcomings of VCSA are primarily related to its nature of not being a Windows VM. For some deployments Windows vCenters have been used to also host the VUM (Update Manager) components, as well as programs that provide additional capabilities to the virtual environment such as VSC for NetApp storage, among others. This means that you would still need to deploy a Windows VM to host VUM as well as VSC in this case. Even though you would still be deploying such VM, the need for a MSSQL server/instance is not required which translates in savings.

Another aspect to keep in mind is the installation and migration from previous versions. There is no in-place upgrade from previous versions, but migrations are possible. With this in mind, you may want to consider to just start with a new, fresh environment. I would. Same applies to the Windows flavor. The installation method now comes as an ISO image. This may cause some confusion. In order to deploy VCSA, the ISO is mounted from a Windows system (can be your computer) and installation can be done remotely.

Before installation, make sure you install the Client Integration Plugin located within the ISO under the vcsa folder.

VCSA_CIP

 

 

 

Start the installation by launching the vcsa-setup.html file from the ISO. A Web UI opens up after a few seconds, and gives you the option to install and ‘Upgrade” (migrate). During installation, just provide the target Host information, and the rest of the information needed for the installation. Make sure the VCSA appliance has a proper network connection and you can reach it from the computer deploying the appliance.

vcsa_setupvcsa_UI

 

 

 

 

 

 

 

 

Both Windows and appliance vCenter offerings have the same scalability numbers as it relates to hosts, VMs, clusters, etc.

In conclusion, VCSA is a great choice for vCenter, but just be aware of some of the constraints of not using the Windows option. By the way the Web UI in vSphere 6 is soooo much faster!!! I’m just saying.

 

vSphere 6 Web Client: Yes, Let’s go there…

Since the introduction of vSphere 5.1, VMware introduced the new Web Client. Yes, there was another web client out there, but it was not widely used. A lot of people questioned the change towards a web interface, so here are many reasons for the Web Client:

  • Access from any device with Web access
  • No need to install binaries in multiple locations to access the vSphere environment
  • Multi OS friendly
  • Scalable solution
  • API friendly

This first version was well received by many, but others noticed some slow response within the browsers. Well, I am happy to say that the new Web Client in vSphere is anything but slow. I know for a fact that the VMware team has spent countless hours working to get the slow response issue resolved. I was privileged to be part of a private customer Alpha test for vSphere x.y , and the difference made since the Alpha up until Beta 2 has been tremendous. I had the chance to voice concerns in many areas and obviously the Web Client was one of them, and let me tell you, VMware listens very well and does whatever needs to be done to make customers happy.

I will list some of the changes to the Web Client that I believe most customers will REALLY like.

  • Fast response times for Web Client interaction
    • Very noticeable
  • Faster log on process
  • Browser Friendly
    • Previous version had best results using Google Chrome
  • Recent Tasks (at bottom) is back
  • Drop down menu from home icon for easy, 1-click navigation
  • Core items added to left pane (Networking, Storage, VMs, Hosts)
  • vCenter Inventory Lists
  • 1-click task filtering

 

These are some of many improvements in the new vSphere release that will satisfy the requests of many customers. I was extremely impressed about the speed of the Web Client, but the additional features are icing on the cake.

As you may infer, the “fat client” will play a small to non-existent role moving forward. The C# client may still be used to access the individual hosts, as well as having read only capabilities for objects with virtual hardware version 9 and above, but vCenter tasks will be have to be done through the new an improved Web Client. Based on the huge improvements and new features, I don’t think many people will miss the old client.

Web_Client