how to copy a VM from ESXi free to new host w/scp and spaces in filename
-
So I ran in to the following scenario. Small non for profit bought a new server to replace the ebay special they have been running on for the last 4 years. They had a Windows Server Essentials VM running on VMware ESXi free. The new server is running ESXi free.
I ended up using scp in ESXi to copy straight from the old host to the new host. It was less than straight forward because of spaces in the filename. The command ended up being:
scp 'Server 2013_1-flat.vmdk' [email protected]:/vmfs/volumes/5636b7f0-e5b4c691-871b-94188238d4a4/"'Server 2013'"
In order for that to work, a few things had to be done. First SSH had to be started on each host:
Then you have to open the firewall for the SSH client. If you don't when you run the scp command you'll get a time out error.
Once you have done that, should should be able to ssh from one host to the other as a test. For example:
ssh 192.168.43.7
and you should get prompted to accept the RSA key fingerprint and then for a password.
To use scp is pretty straight forward
scp sourceFile user@host:destinationPath
and then you get prompted for the password.To figure out the exact path:
cd /vmfs/volumes
ls
cd yourDataStore
at that point, your path will change to the actual path. My issue came in that I had spaces in the filename. When you tab out the filename, it puts a \ in to escape out the space. Unfortunately, you can't just copy and paste that path to your scp command line. You need to use a double quote outside a single quote as shown in this example:scp 'Server 2013_1-flat.vmdk' [email protected]:/vmfs/volumes/5636b7f0-e5b4c691-871b-94188238d4a4/"'Server 2013'"
With that command underway you will get real time statistics like this:
Server 2013_1-flat.vmdk 17% 75GB 19.1MB/s 10:53:54 ET
Additional notes before someone asks:
I would have considered moving them to HyperV, but they had a SATA drive that contained workstation backups that needed to move over to the new server. In addition it was going to be way quicker to physically move that one drive over to the new server.
The VM was on a bunch of small 136GB SAS drives and the new server has two 1TB SATA drives in a mirror, so I couldn't just move all the drives over and do a local data store copy.
In the past I have used vmware converter or used the vSphere client to download all the files to a windows box and then upload them to the new host. On a small VM without much data, it doesn't take too long. In this case it was going to take hours and two stepping it would have meant getting up in the middle of the night to start the second step.
-
Nice direct transfer solution.
I'm not sure what the SATA drive of workstation backups have to do with not using Hyper-V or XenServer?
What's your IOPs difference on the new two drive versus the old multi drive system?
-
@Dashrender said in how to copy a VM from ESXi free to new host w/scp and spaces in filename:
I'm not sure what the SATA drive of workstation backups have to do with not using Hyper-V or XenServer?
The idea was that I could just add that drive as a datastore in VMware and all my stuff would automagically be there. Tried it this morning and VMware sees the drive, but doesn't recognize the file system. Need to do more research.
-
Doesn't VMware use its own filesystem on block storage?
NFS or SBM use their host system's filesystem, as far as I know.
To do what you want, mount the drive in something that can present it as NFS.
-
So I ended up having to SSH in to the ESXi host and give it the command:
partedUtil mklabel /vmfs/devices/disks/naa.600508b1001cabcdaf821b64d8080017 gpt
That fixed the problem with the drive only showing up in Devices with a partition type of "unknown" but also wiped the drive. Not the end of the world since it was just a workstation backup target drive. I think it has to do with the fact that the Dell server it came out of had one type of SATA adapter, and when I added it in to the HP server it wanted to add it as a Volume in the array manager. At least ESXi didn't see it the first time around until I did that.
Before I ran that command, I ran this:
partedUtil getptbl /vmfs/devices/disks/naa.600508b1001cabcdaf821b64d8080017
which produced this output:
Error: The primary GPT table states that the backup GPT is located beyond the end of disk. This may happen if the disk has shrunk or partition table is corrupted. Fix, by writing backup table at the end? This will also fix the last usable sector appropriately as per the new reduced size. diskPath (/dev/disks/naa.600508b1001cabcdaf821b64d8080017) diskSize (3906963632) AlternateLBA (3907029167) LastUsableLBA (3907029134) Warning: The available space to /dev/disks/naa.600508b1001cabcdaf821b64d8080017 appears to have shrunk. This may happen if the disk size has reduced. The space has been reduced by (65536 blocks). You can fix the GPT to correct the available space or continue with the current settings ? This will also move the backup table at the end if it is not at the end already. diskSize (3906963632) AlternateLBA (3907029167) LastUsableLBA (3907029134) NewLastUsableLBA (3906963598) Error: Can't have a partition outside the disk! Unable to read partition table for device /vmfs/devices/disks/naa.600508b1001cabcdaf821b64d8080017
-
Was the drive formatted GPT in the old system?
-
Not sure, and I'm not going to power up the old system to find out. New one is running fine. If I ever run in to a situation like that again, there are a lot more checks I would do.