Categories

Archive

June 2025
M T W T F S S
 1
2345678
9101112131415
16171819202122
23242526272829
30  

Most viewed posts

VM replication in vSphere 5.1

29 August 2012
Comments off
Reading Time: 4 minutes

Another interesting feature in vSphere 5.1 is the vSphere Replication (VR) technology. This feature was first introduced on 2011 with Site Recovery Manager 5.0 (on vSphere 5.0) to protect virtual machines natively by copying their disk files to another location where they are ready to be recovered, using a VM replication technology (storage vendor independent) instead of the storage replication (storage vendor depend). It provides simple and cost-efficient replication of applications to a failover site.

The big change is that now it is a component delivered simple with vSphere editions (starting from Essentials Plus), and of course also comes bundled with Site Recovery Manager. This offers protection and simple recoverability to the vast majority of VMware customers without extra cost.

And it’s completly integrated in the new vSphere Web Client!

This feature is probably a clear replay to Microsoft move to include a similar function in their new Hyper-V3 product! But will be also a possible strike to some products in the ecosystem.

From technical point of view, it’s a non-disruptive technology: it does not use vSphere file-system snapshots nor impact the execution of the VM in any abnormal way. Since VR tracks changes at a sub-VM level, but above the file system, it is completely transparent to the VM unless Microsoft Volume Snapshot Service is being used to make the VM quiescent (and this could be handled in the write way).

It works in a similar way as on Site Recovery Manager 5.0, but now is more simple because it does not need SRM (although it could still be used) and also both the “VRMS and VRS” in the SRM 5.0 implementation of VR are included in a single “VR Appliance” now (still one per paired site and it could also support multi-site configuration!).

But note that vSphere Replication is targeted at replicating the virtual disks of powered on virtual machines only because it’s based on a disk filter to track changes that pass through it, therefore static images can not be tracked. For this reason could not be used in those cases:

  • Powered-off or suspended VMs
  • FT, linked clones, VM templates
  • VM snapshots in and of themselves are not replicated but instead are collapsed during replication (Note: Reverting from a snapshot may cause a full sync!)
  • Non-disks attached to a VM (ISOs, floppy images, etc) could not be replicated

Some interesting note:

  • Can replicate to a different format than its primary disk (for example you can replicate a thick provisioned disk to be a thin provisioned replica)
  • VMs can be replicated with a recovery point objective (RPO) of at most 15 minutes and at least 24 hours
  • Virtual Hardware 7 or later is required for VMs to be protected by VR
  • It require vCenter Server version 5.1 with the new Web Client, but can work with ESXi 5.x!
  • Both Storage vMotion and Storage DRS are supported, but with some considerations and exceptions

One important note is the dependency with vCenter Server, because on the other side you need vCenter Server to click “Recover”.If you have a single vCenter Server this could be a problem, but there is an unsopported solution descrived on this post.

Also the VA could be paired only with one vCenter Server, and this will limit the flexibility (for example in multi-site topology).

VMware

Enhanced vMotion with vSphere 5.1

29 August 2012
Comments off
Reading Time: 2 minutes

With the new vSphere 5.1 a new vMotion option has been added (only in the new Web Client) that combine vMotion and Storage vMotion in a singe hot migration step to migrate between hosts/clusters without shared storage! This could increase the mobility of the VMs and usage also of local storage (for some cases). Both VM state and VM files are transported across network using the vMotion vmkernel interfaces (so a good network design could be necessary).

The requirements are:

  • Hosts must be managed by same vCenter Server
  • Hosts must be part of same Datacenter
  • Hosts must be on the same layer-2 network (and same switch if VDS is used)
  • Hosts must have the same CPU or have the same EVC baseline (like for the vMotion across clusters)

continue reading…

VMware ,

Bye bye vSphere Client

29 August 2012
1 comment
Reading Time: 2 minutes

In the previous new products release we have notice several changes in some core parts, and several components are gone (see What’s in and what’s out). Now with the new vSphere 5.1 a new historical component (from the VI 3.0) will die soon: the vSphere Client!

The limits of this client are:

  • it works only on Windows client (so it isn’t a multi-platform solution) and has some dependency with the .NET Frameworks
  • it’s a thick client-server approach (compared with thin solutions, like browser oriented)
  • it’s “complicated” to deploy and upgrade (strange that VMware has not opted to a simple ThinApp packaged to deliver this products)
  • most of the vCenter plugins may require also a client plugin part

continue reading…

VMware

VMware reveils the news in the End User Computing

28 August 2012
Comments off
Reading Time: < 1 minute

During the keynote of the second day, Steve Herrold have present the new End User Computing (EUC) solutions from VMware.

Starting from the new View and Mirage approach where you can handle both physical and virtual desktop and you really plan both Windows OS migrations (from XP to 7 for example), but also handle the move from physical to virtual (with a real good live example from Vittorio Viarengo).

The next part was the Horizon Suite that can handle the access to all desktops, applications, data of you EUC.

Included the Horizon Mobile that could handle smartphone (and this year the demo was on the iOS version).

For more information see the entire keynote.

VMware ,

VMware Cloud Suite 5.1 announce

27 August 2012
Comments off
Reading Time: 2 minutes

Yesterday, during the live event, VMware has announced the new release of most of their Cloud Suite products (concept already introduced with the announce of the release 5).

New release will be v5.1 for all products to adopt a uniform and consistency enumeration across products (View 5.1 was already released some month ago!).

So this will be the versions changes for the suite:

  • vSphere 5.0 -> 5.1
  • vSphere Storage Appliance (VSA) 1.0 -> 5.1?
  • vCloud Director 1.5 -> 5.1
  • vShield 5.0 -> 5.1
  • vCenter SRM 5.0 -> 5.1
  • vCenter Operations 5.0 -> 5.1?

As you can notice, the suite is no more a simple virtualization suite (ESXi + vCenter Server), but is more complex according the evolution of the virtualization market (with more focus on the cloud) and, of course, of also the technologies and the customer’s needs.

The new vSphere 5.1 will probably be also a reply to the Microsoft Hyper-V3 announces (where most gaps will be closed). In this way we could finally be able to compare the features of two homogeneous product’s version!

What is really interesting is that, due to minor release changes (for most products), those products will be available for people that already have the last version.

VMware

VMware Workstation 9 and Fusion 5

23 August 2012
Comments off
Reading Time: < 1 minute

Could seems strange, but VMware has announce the new release of Workstation 9 and Fusion 5 some days before VMworld US. Probably to keep the focus of the announces on the Enterprise and Cloud platform.

For Workstation, of course this release will support Windows 8 (seems also in the Windows 8 style interface). But more interesting seems:

  • OpenGL support in Linux
  • Restricted Virtual Machines
  • A new web interface to share VMs
  • Hyper-V (although is not supported)

See also:

VMware none

VM replication in VMware SRM 5.0

23 August 2012
Comments off
Reading Time: 3 minutes

One of the interesting feature of VMware SRM 5.0.x is the vSphere Replication (VR) technology that is a VM a replication engine (part of SRM 5.0 and that also requires ESXi 5.0 and later) to implement protecting and replicating virtual machines between sites without the need of storage array–based replication (that usually it’s costly and too much vendor dependent).

It use different elements:

  • VRA (vSphere Replication agent): included in ESXi starting from v5.0
  • VRMS (vSphere Replication Management Server): one virtual appliance (VA) for each site to handle the communication
  • VRS (vSphere Replication Server): one virtual appliance (VA) on the DR side that is just the “target” of the VR agent

The deployment of all those VA could be simple handled from the SRM plugin.

How VR determines what is different and what needs to be replicated

There are two forms of synchronization that VR will use to keep systems synchronized:

  • “Full synch”: that happens usually just on the first pass when the VM is configured for VR, but can also happen occasionally during other situations such as when recovering from a crash.
    When VR is first configured for a virtual machine you can choose a primary disk file or set of disk files and a remote target location to hold the replica. This can be an empty folder, or it can be a copy of the VMDK that has the same UUID as the primary protected system.The first thing VR will do when synchronizing is read the entire disk of both the protected and recovery site and generate a checksum for each block.
    Then it compares the checksum mapping between the two disk files and thereby creates an initial block bundle that needs to be replicated on the first pass to bring the block checksums into alignment. This happens on port 31031.
  • “Lightweight delta”: the ongoing replication is by use of an agent and vSCSI filter that reside within the kernel of an ESXi 5.0 host that tracks the I/O and keeps a bitmap in memory of changed blocks and backs this with a “persistent state file” (.psf) in the home directory of the VM. The psf file contains only pointers to the changed blocks. When it is time to replicate the changes to the remote site, as dictated by the RPO set for the vmdk, a bundle is created with the blocks that are changed and this is sent to the remote site for committing to disk. This replication happens on port 44046.

For more information see also:

VMware
© 2025-2011 vInfrastructure Blog | Disclaimer & Copyright