On 5/19/2010 1:11 PM, Tom Fitzgerald wrote: >> "The hard way" is to attach both storage systems to VMWare >> machines and tell it to copy data from one to another. This requires >> service interruption while virtual disks are being copied and well as >> being a fairly inefficient way of going about the bit moving compared to >> what the 7210 gives me. >> > Are you sure about this? ESX 4.0 lets me migrate a VM's storage > from one datastore to another without taking it down. > > Yes it's less efficient but unless the move is being handled by > ESX itself, there's no way to avoid a VM reboot when the storage is > re-pointed. > > I can't speak for ESX 3.5. >
ESX 4.0 will allow you to migrate a running VM between storage systems as long as no snapshots exist for the VM. If they have snapshots you have to either remove them or migrate when the VM is off. Both offline and on-line storage vMotion works nicely. (This is true at least for our ESX deployment, and it surprised me. If you're experience is different I'd love to know that.) However, regardless of success at the ESX level, we're also using VMware's LabManager product, which is more limited. there's a separate database where LabManager tracks meta-information about VMs. Based on our experience (the documentation is, to put it nicely, less than adequate) there is no way that LM can deal with ESX's ability to vMotion -- the vMotion will work but LM loses track of the VMs. We're working on having this confirmed or denied by VMware support. The documentation and knowledge bases all point to an "ssmove.exe" program included with LabManager -- power off, brute force copy of a VM tree, then power back on. What I'd really *like* to do is use the 7210's ZFS sync feature or NFS import and move the filesystem wholesale and just tell ESX to mount if from the new host, but the datastore IDs hurts me there. Thanks -- Dewey _______________________________________________ bblisa mailing list [email protected] http://www.bblisa.org/mailman/listinfo/bblisa
