-
• #3
If you can take the server offline then you could use cp, which is the ESX/unix native file copy command like copy in DOS.
Create the new storage, add it to the ESX box, ssh (with putty etc) in to the esx server if you have SSH enabled if not enable it in the FW.
find the folder where u r copying from
e.g /vmfs/volumes/53d3386e-4f27795e-a81f-00265521cfc4/SERVER1
stay in the folder and do a
"cp -R * /vmfs/volumes/53d3386e-4f27795e-a82f-00265521ghc4/SERVER2"Have a look at "cp --help" to ensure you're using all the options.
when your start the new VM you'll get the "have you moved or copied it" message I think "copied it" is safest option.Or you could have a go at using "datastore browser" from the ESX client. This long winded as I think u can only copy to a local/network drive on your LAN and then u have to copy it back, making it a two step process. Winscp from Windows will do it but I think this creates a temp local file so quite slow. The ESX converter tool which runs from Windows and connects to your ESX could do it I guess as well and you can change VMDK sizes on fly.
Is the storage thin or thick etc? From memory there's an set of tweaks required if moving from thick to thin to reclaim white space in the vmdk.
good luck
-
• #4
cheers thanks for that - new storage will be thin provisioned
essentially they have run out of space in current datastore for their solidworks CAD server which keeps falling over
so plan is this essentially:
- Install Hp JBod and fill with disks and configure Hp P2000 to accept new dual I/O 12 bay Jabod
- Patch storage controllers then expand by 24tb/configure new raid set
- Configure storage hosts reconfigure iscsi network physical and virtual
- Configure Vcentre to accept new storage and map new data stores to Esx hosts
- Backup sql databases from Solidworks2/vcentre to new storage
- Tidy and clean data on all virtual servers ready for V2V/migration
- V2V Solidworks thin provision Vm Storage
- Run a full veeam backup
- V2v File sever and thin provision storage.
- V2v Dc’s exchange and all other virtual servers to free off over provisioned space on the san
- Transfer new backups from san to slower iscsi storage and reconfigure Veaam targets
- Shut down all production servers and move to new storage while we rebuild the original p200 san
- Build new raid set on P2000 once completed move sms dependant on performance requirements to their desired locations.
- reconfigure Veam build new backup jobs and test.
- Test solid works and erp10 and confirm backups are sound
- Create new storage policies to avoid this in the future
- Test storage fail over including both iscsi controllers and recovery from network attached storage.
method using cp-r etc - is this similar to doing File -> Export -> Export OVF template and then choose thick or thin and 'copied it'? as mentioned here - http://serverfault.com/questions/372526/move-vmware-esxi-vm-to-new-datastore-preserve-thin-provisioning
Assuming this also copies the VHD or VMFS (VHD is Hyper-V maybe, can't remember) this could also work, as we'll be backing up server VM's first
- Install Hp JBod and fill with disks and configure Hp P2000 to accept new dual I/O 12 bay Jabod
-
• #5
re Cp -R and VF, no I don't think so as that looks like it's gonna be a two step process, 1. export OVF onto accessible storage (like datastore browser download) and then import.
the CP -r is a single copy from one place to another, the caveat being it can't expand VMDKs if you want to do that then need a tool like the VM Converter which will copy and change in the copied version.
Is this what you mean when you say v2v or are you using veeam for that?I remembered the extra step when going from thick to thin, which was to run windows native "sdelete"on the clients however this may have only be relevant to our env. We went from an MSA2420 (all fat vols) to 3PAR with thin vols and the first test box didn't "thin" out on the 3par env so I tested a few options and this was the only way to reclaim space. It essentially zeros out the supposedly blank space so when it's moved the thin vol can recognise it as unused.
Do you boot from the SAN/Iscsi storage?
I'm trying to think back how we used to do this before vmotion etc, but I think we had seperate luns and therefore vmdks for the C: (OS) and D:,E: (data vols) so we could assign new ESX storage and then new vols in the clients and effectively create another drive. We could then copy the files from within Windows from e.g. D: to E: and provided you've stopped all access, once copied remap the drive letters and reboot. -
• #6
Is this what you mean when you say v2v or are you using veeam for that? - I think they just mean copy existing VM servers from existing datastore to new lun
Do you boot from the SAN/Iscsi storage? Not sure, I'll have a better idea tomorrow when I visit the site - the screenshot I was sent is below - that shows the datastores
-
• #7
anyone know a quick and easy way of syncing Exchange users in a domain forest trust? (both sides Exchange 2010)
Sure there used to be an IT nerds thread?
Anyway, any VMWare/Storage gurus out there?
I need to extend datastore into a SAN extension, which may end up just being created as a new separate Lun
What is best way of moving VM's/VMFS? I think the client only has vmware essentials, so not sure they have licence for storage vmotion. They do have Veeam backup and replication though, which I believe you can move VM's with - but it's the VM virtual discs that concern me
Ta