I read the following interesting news release from VMware today. It covers lots of new features for the future release (3.5) of VMware but the one that caught my eye discusses a new feature called VMware Storage VMotion.
This feature will apparently allow the migration of a VMware virtual disk between different storage systems in the same manner that VMotion allows a virtual host to be moved between physical servers. I'm interested in how VMware will have chosen to implement this as there are lots of places in the stack they could choose to do it. For example, will there be any integration with array vendors' technology (like SRDF/TrueCopy) to manage the replication at the lowest level? Will the replication be managed via a virtual target/initiator in the fabric or will the VMware O/S manage the duplexed data writes at the application layer?
The difficulty of using replication outside of the application layer will be managing data integrity and also speed of replication cutover as the VMware guest is shifted to the new physical location. Add into that the complexity that each member of the VMware "cluster" will probably want read/write access to the virtual disks on which the virtual hosts are defined, then technologies like SRDF aren't going to work.
What about the CDP products? These seem to be a good logical fit as they replicate and track each block change independently, but I think the same issues of read/write access will apply and therefore these products will be equally unsuitable.
I think it is likely VMware will implement a "standard" cluster with multiple disks being written to by all members of the cluster and using IP to manage synchronisation. This may be good for a local solution but in reality what does VMotion then buy you? As a tool for managing the location of virtual machines across a farm of servers then VMotion is a fantastic tool. I just love the ability to move a host around to manage performance/workload on physical machines and to provide the ability to take physical servers out of a complex in order to do maintenance work.
But with today's 99.999% available storage subsystems, which can be maintained and expanded online without outage, is there any benefit in being able to move a VMware host to another storage system, unless that storage system is remotely located?
Storage VMotion sounds like a great idea but I'm not sure of the practical use of it - especially bearing in mind there will be a significant cost associated with the new feature.
Monday 8 October 2007
Storage VMotion
Subscribe to:
Post Comments (Atom)
Posts
6 comments:
I think it would be useful when/if you wanted to move just one guest from a slow LUN to a faster LUN in the same storage.
Janake, perhaps that is true, however I'd expect if you're that serious about performance you'd have configured your system to have fast LUNs in the first place.
There may be little need for this feature.
When most folks need to move a VM to a different lun, then its really just a case of taking a maintenance window for the VM and copying the VM to the new location. Seeing as most Virtual machines do not need a 24 x 7 x 365 uptime, this is usually not an issue . From what I can see, most clients do not see Vmware as a solution that 24x7 capable..yet.
How about a situation (like mine) where you have a VMWare cluster running production servers, and are upgrading the SAN infrastructure?
We are going from a CX500 to a CX3-80, and Storage Vmotion just might save me from power down/copies and allow the business to continue running during the cutover.
I totally agree with JT. Also Storage VMotion will be very useful if an IT shop wants to consolidate/rearrange their virtual servers among different storage arrays (we were in that situation before and did not really do it due to too much trouble to physically relocate all the VMs). If we have Storage VMotion then we can very easily make it happen without even interrupting the business.
VM is the production world for me. Being able to migrate machines to a different lun to take advantage of NetApp features or change its replication policy, move data between Aggregates to manage storage layout, or between fl scsi and sata real time would be valuable.
Post a Comment