Transfer rate between ESXi host using "Veem backup and FastSCP"

[Pixxxx]

Dear all,

I have two ESXi host connected with different 1G-Eth ports on an HP switch

now I'm trying to transfer data between the two hosts using "Veem backup and FastSCP" tool

a transfer rate of 1MB/s is normal? do you know a way to enhance network performances?

note that no collisions or mismatch discovered on the switch port

thanks in advance

[AndreTheGiant]

The speed is quite slow.

But could depend also by your storage speed.

Make a similar test with datastore browser.

Andre

[Pixxxx]

which should be a good transfer rate for this scenario?

thanks

[idle-jam]

anything 10 to 15 MB/s is good for me ..

[Pixxxx]

considering that no external storage are used and that transfer is made between local disks on different server, which check it should be done in order to understand if something is wrongly configured?

also, what happen if a timeout error will be experienced? the file will be copied and it will be not functional or the copy will not succeed?

thanks

[Pixxxx]

I solved the slow transfer rate experienced during network copy running the Veem tool in an XP Virtual Machine hosted on the ESXi 3.5 host.

Now my transfer rate is around 40MB/s

Thanks to all for your help

[idle-jam]

my apology for the delay but glad to see that you have such a good speed .

[Pixxxx]

Dear all,

I can confirm, I have a great transfer rate, the better one experienced has been upper then 50MB/s

despite this I have a problem, using Veeam.... I am able to transfer files with a high dimension but I am not able to transfer vmdk files larger then 270GB, today I have tried to transfer one vmdk files of 300GB three times without succeding, see error below

now question is, there are some limitations in my environment? there are limitations in Veeam backup....?

do you have suggestions?

I'm using Veeam... in order to make a failover ESXi machine in the meanwhile of taking in place the following scenario:

1. Installation of a new RAID5 VirtualDisk reserved for backup purpose on my HP MSA2000 series storage

2. Installation of the new VirtualDisk mentioned above on my ESXi 3.5 host

3. Implement ghettoVCB scripts and make backup on the new backup storage

you think that in this way backup of very large vmdk will be possible? the backup will be compressed?

I will also try to reduce any large vmdk file splitting them in different virtual disks

any suggestion is welcomed

Best Regards

[ldelloca · Accepted solution]

Hi,

this job is a replica maybe? If you're using VMFS as a target, you have to double check the block size, if it's the default 1 Mb, maximum size of a vmdk disk is 256 Gb.

The value you got 274878668800 byte, divided three times by 1024, gives you exactly 256.0007095336914 GB. Probably this is the problem.

PS: I've seen by your error screencap you're from Italy, come visit us on the Italian User Group pages 🙂

Regards,

Luca.

--
Luca Dell'Oca
http://www.vuemuer.it
[rewarding points to a useful answer is a way to say thanks]

[Pixxxx]

Hi Luca,

yes you are right, the Block Size is 1MB

so, considering that I have to be able to transfer on this backup host some guest VM with 500GB storage, is 8MB block size the best way to proceed?

I have two local storage, both created with 1MB block size, I would like to solve the issue in this way:

1. allocate all the guest OS on a single storage

2. delete the second storage

3. create again the storage with 8MB block size

4. relocate the guest os that where previously located there

after that, I should be able to backup the machine with 500GB storage that are in place on the active host

last question, may be a problem move file from different storage with different block size? in my understanding it should not be a problem

thanks in advance

[ldelloca]

In my opinion, creating all datastores with 8 mb is far more useful and avoids some future problems like this one you are facing.

Performances are not really affected by block size, and with 8 Mb you can always create vmdk the size you want. Since we are talking about files sizing in the Gb area, loosing some mb due to saving configuration files on a 8 mb block is a small issue.

The procedure you suggested is correct, I would move around VMs and progressively recreate all datastore with 8 mb block size.

Last, there is no problem in moving files between datastores with different block size, except two issues:

- as you have faced, you could stuck in an operation if target datastore has small block size and you try to move there a larger vmdk

- performances is worst when you move/copy files between datastores with different block size, Dunca Epping wrote a detailed article about this (http://www.yellow-bricks.com/2011/02/24/storage-vmotion-performance-difference/)

Regards,

Luca.

--

Luca Dell'Oca

http://www.vuemuer.it

[Assign points to a useful answer is a way to say thanks]

[Pixxxx]

thanks for your help, I will let you know the result