Tag Archives: Vcenter 5.1

VMWARE RELEASES vCENTER 5.1 UPDATE 1a THAT FIXES UPDATE 1 ISSUES AS WELL.

For those who kept close watch on 5.1 Update 1 – you are aware of the failed domain login attempts to the vsphere client or the web client which will basically lock you out of your own vmware environment. What vmware had to say about the issue,

This issue can occur if the specified vCenter Server login domain user account is associated with a large number of domain groups and multiple domains are configured as SSO identity sources. The precise number of groups at which this issue can occur varies due to the nature of Active Directory internals. However, it is more likely to occur once domain-group membership for an account exceeds 19.

So if you have an SSO configured for multiple domain identity sources or if you have vcenter domain user accounts associated with large number of groups – updating to 5.1 Update 1 will break things for you!

If you already updated to vCenter 5.1 Update 1 – then the fix is you simply update vCenter to 5.1 Update 1a. The KB article is here.

The article explaining what went wrong is here. The issue was identified to have caused because of the way Active directory domain trusts work.

vCenter 5.1 Update 1 has been replaced with vCenter 5.1 Update 1a for you to download and install.

Lets hope 1a won’t break anything else 🙂

Please do comment if you feel like!

 

 

 

VM Replication in ESXi 5.1

rjapproves QuickY (For the impatient like me!)

  • VMware introduced virtual machine replication in today’s ESXi 5.1 announcement.
  • Virtual machine replication replicates your primary virtual machine to another datacenter so you can quickly bring up your virtual machines in a disaster event at the primary site.
  • A virtual machine is copied to the other site, a full copy followed by changed block copies are done.
  • Intelligent copy where application and/or database consistency is maintained using Microsoft Volume shadow copy service(VSS)
  • Replication is free product and is added as a feature
  • Replication runs off a agent that comes with each hypervisor install and a vSphere Replication appliance that runs on each vcenter at per vcenter basis. As of now, its maximum of 10 appliances per vcenter supporting 500 virtual machine replications per site.
  • Replication can be done on a per virtual machine and per hard disk basis.
  • The target virtual machine will not power on if the primary (source) virtual machine is pingable by vcenter server and/or is still powered on.
  • Recovery vm once powered on will have to be manually connected to the network via the vcenter web console (one click action).

InDepth

This is exciting, VMware finally takes up Microsoft’s Hyper-V challenge and offers replication as a free product add on for all of us to enjoy.

So what is vmware replication really all about? Think of vmware replication as basically having a clone of your virtual machine on another hypervisor which may or may not be on the same site. Ideally, the replication will occur from one physical site to another. The catch is that this clone is constantly being updated – aka – any changes in the source site are transferred to the target site depending on the interval for replication you set.

The hypervisor inherently has a agent and there is a vmware replication appliance per vcenter whose job is to receive replication data and also keep track of the statuses. A vCenter can have upto 10 maximum vmware replication appliances. I am not clear on the maximum virtual machines that can be replicated but it seems like there is a cap on 500 virtual machines per vCenter.

The way it works, in the web based vcenter portal, you simply enable replication by a click and choose a virtual machine to replicate to another datacenter hypervisor. You get to choose how often the replication is to run, basically a RPO for your virtual machine. VMware allows a low RPO of 15 mins to a maximum of 24 hours. You can also set the destination virtual machine to have its disks as thin as opposed to the thick disks at the primary site. This allows you to save storage space on the target site.

Once that is set, you are all done, the initial replication will be a complete copy of your virtual machine over the wire. Now if you have a huge virtual machine, you can choose to pre-seed it to cut down on replication time. You can either copy it/clone it to a usb storage or FTP and then pre-seed that at the destination. Once Pre-seed is done, only changed blocks are copied. Change block tracking, i believe, is automatically enabled and only blocks that are changed are copied over. Remember the VA Agent is responsible to send over changed blocks and these are received by the VMware replication appliance on the other end.

 

Some cool things you can do is specifically pick which disks in a virtual machine you want to replicate and which you choose not to. For instance you can have a designated disk as swap disk for a virtual machine and you may choose not to replicate that disk.

To failover the virtual machine you simply have to initiate it from the vcenter web client, however remember, failover will not work or will not be allowed if your primary vm is still powered on and/or vcenter can ping it. When the target virtual machine comes up, it will disconnected from networks. The idea is for an administrator to look at the target and then to connect it to the network and not to have them blindly power on. This is to prevent accidental power ons that may result in network conflicts if any could happen.

I am quite sure that VMware is using the Virtual Disk Development Kit(VDDK) to get this all to work. The host agents that come loaded with the ESXi 5.1 install on the box use the VDDK to attach/detach disks and also ship data over wire. There are no security issues as of today, and replication is pretty secure.

I don’t have specific details yet but I will add more as we play along.

Do comment if you have any more information or need to correct/add info.