You are reading a single comment by @TheShipwright and its replies.
Click here to read the full conversation.
London Fixed Gear and Single-Speed is a community of predominantly fixed gear and single-speed cyclists in and around London, UK.
This site is supported almost exclusively by donations. Please consider donating a small amount regularly.
@TheShipwright
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.