Storage Vmotion

[DanielMeyer]

I'm a bit confused with storage vmotion. As far as i understand the presentations and whitepapers its just like the classic cold migration except that you dont have any downtime of the migrated vm.

So i thought it might be the ideal solution for my scenario:

2 VMWare ESX Servers with SAN access, VC, vmotion, the works. Now we're going to install one or two very mission critical VMs which have to be online almost 24/7, even a few minutes of downtime would require a tremendous amount of coordination between dozens of affected production sites. Overall our SAN is extremely reliable but for major firmware updates both nodes of the SAN Cluster have to be offline. So our Idea was to install a third ESX Server with some local storage - to migrate the critical VMs to that server using stoarge migration.

Now our consultant tells me that it wont work (and wouldn't be supported anyway by vmware). His argument is that storage migration is only for moving VMs from "old" storage to "new" storage, not for migrating VMs back and forth, even if its just once or twice a year - and that its not possible to have old and new storage online at the same time.

Now i'm rather confused...

[gbowers]

I am assuming that by downing both nodes you are referring to the SP's (storage processors).

If true then you could add the additional ESX server with the local storage; do a standard VMotion prior to the bin changes over to the new server, initiate an SVmotion from the ESX server that has control of the virtual to the local storage device, once the firmware is complete rescan the controller's and copy back to your SAN.

Your last statement is completely wrong, you may want to look for a new consultant, I use SVmotion all the time to rebalance my storage devices as the needs of the VM change. Say you've run out of space and want to move over to a new storage device where you have the extra room.

The only caveat is that your local storage would be much more likely to experience a bottle-neck due to bandwidth limitations; additionally I would not recommend moving more than one or two VMs to local disk.

[weinstein5]

he is right storage vmotion does not involve moving the vm to a different host - what i would suggest is set up the new server so you can vmotion to it - as set up for downing the san vmotion to the new box and then use storage vmotion to move the vms disk to the local storage - when maintenance is done storage vmotion back to shared storage and vmotion back to prodiuction boxes -

[Troy_Clavell]

I would take a look at this .pdf, starting on page 246

http://vmware.com/pdf/vi3_35/esx_3/r35/vi3_35_25_admin_guide.pdf

[demz]

AFAIK your consultant is wrong, SVMotion is designed to migrate VM's files onto another datastore even if it's not a "new" storage...

So feel free to play with it, but take care with heavily used VM with intensive I/O and keep in mind there is a self VMotion during the process so your server has to have enough resources...

[demz]

Ok I've to read posts entirely before writting any answer...

[mreferre]

Yes as others have pointed out what the consultant is picturing is a use case of Storage VMotion .... but it doesn't mean it's the <only> use case.

For some reasons local storage is always <snobbed> and not mentioned when talking about SVMOTION. While I don't see any reasons why it shouldn't work it's my impression VMware doesn't formally support it (whatever "support" means).

If that is the case (and you are concerned) you might want to create an iSCSI LUN to temporarely host your application while upgrading the firmware/code of your storage server. That (iSCSI) appears now (since Update 1) to be officially supported.

Massimo.

[DanielMeyer]

Thanks for all the answers, especially yours Massimo (and nice to see you're still around, maybe you remember me from back then )

Iscsi might just be what i could use... I have another SAN which should be able to do iSCSI, will check this tomorrow.

So I think i could do something like this:

Host A, B would be connected via FC to the primary SAN-cluster and via iSCSI to the secondary SAN. Those would be the active nodes and do all the work. Host C would be in a third datacenter, connected to both the primary SAN-Cluster and the secondary SAN via iSCSI (our SAN supports handing out LUNs via FC and iSCSI at the same time. In case we need to shutdown the primary SAN completely (both heads) we could just svmotion the important VM(s) to the secondary SAN (should be faster than iSCSI to iSCSI, because half the traffic goes through the FC connection), and then vmotion it to host C.

That should be fully supported as far as i read the docs and that blogentry massimo posted.

Danny

[mreferre · Accepted solution]

Hey Daniel .... yes I am still around ..... as long as I don't find something better such as selling ice-creams at the beach of Santa Monica or the like.....

That sounds a plan although I don't see why you have now host C into the picture if the offline "problem" is in the SAN. As long as Hosts A and B are connected to both the FC storage as well as the iSCSI ..... you don't need Host C.

The performance speculations is a bit aggressive. Copying from a fast storage to a slow storage means that the bottloneck is the slow storage .... but it's more complex than this .... depends on r/w ratios, whether the slow one is the source or the target, config of both storages etc etc etc etc etc

Massimo.

[DanielMeyer]

True - I dont "really" need Host C, but i understood the requirements as "and even if your whole datacenter has to go down... and your second datacenter too...", and then a Host C located somewhere else would be handy...

Guess I'll offer my colleges a solution with or without a third host so they can decide if its worth the money - as long as they buy me the vmotion stuff

Would be a good thin actually... I'm trying to get vmotion for ages, but my boss never wanted to spend the money... now the requirement (and the budget) comes from another department