[BBLISA] NFS re-export or NFS proxy?

[Dewey Sasser]

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