Search results

Server running on ESX, client running on Proxmox: [root@my-esx:~] /usr/lib/vmware/vsan/bin/iperf3.copy -s -B 192.168.0.123 -p 8000 ----------------------------------------------------------- Server listening on 8000 (test #1) ----------------------------------------------------------- Accepted...

I tend to agree; if you're doing these transfers over an open network speed probably isn't your primary concern anyway. It would also theoretically be pretty straightforward to inject an encryption/decryption step into the pipeline before/after netcat, but at the moment the primary concern is...

This looks awesome! I'll give this a test tomorrow and post the results.

There are also some additional niceties afforded by the import tool. It's definitely possible to migrate using shared storage of one kind or another but it involves more steps, both on the ESX side in the form of moving the VMs around to get them onto the shared storage and on the Proxmox side...

That's much of the same issue we're having. 20 min for a 50GiB VM isn't the end of the world, but for some of our larger VMs there's no way we can sustain the downtime to move 2TiB at that rate. I know I've said this already, but I am deeply appreciative of the work you've put into improving...

I'm going to investigate how difficult this is, as since we've repurposed some of our ESX hosts into our Proxmox test environment we're already wired up to a few of the datastores off the SAN. I was just really trying to avoid straying from the beaten path, but I think we left that idea in the...

It's gigabit. I just did the math myself, dd just outputs total chunks and total time. The disk in question was 50 GiB and the dd process took 7 minutes and 53 seconds which gives an effective speed of around 0.85 Gb/s if my/Wolfram Alpha's math is right. I dd-ed over 10 GiB of zeroes and got...

Yeah, the 192.168.0.150 interface is the PVE side of the iPerf3 test I posted earlier. So interestingly it seems like I'm only able to pull ~0.9 Gb/s running dd and sending the results to null. [root@my-esx:~] time dd if=/vmfs/volumes/fs72_test_datastore_03/TESTVM01/TESTVM01_1-flat.vmdk bs=16M...

OK just finished the nc test. It doubled throughput but it seems to still be a long shot from the theoretical network throughput we'd expect: root@pve:~# nc -l -p 8000 -s 192.168.0.150 | pv | dd bs=16M of=/rpool/data/testfile.vmdk 50.0GiB 0:09:19 [91.6MiB/s] [...

Yeah I checked that on our end. Seems like it's disabled presently.

I was also doing a bit of research this morning, and it looks like the throughput limitations of SSH from ESX and it seems that this is potentially an issue with resource limits applied to the busybox environment on the ESX side. Nothing conclusive, but here are some of the references to this...

OK so I did a little bit of playing around with the 1.1.2 release this afternoon. Here's some questions and findings in no particular order: Does it fallback to HTTP whenever a password is provided? I don't seem to be able to figure out a way to get the GUI to let me add the ESX storage without...

So weirdly I re-copied my test VM and it seemed to get exactly the same throughput. It's got 2 disks; a 1GiB and a 50Gib disk. With the original version, the VM transfers in ~20 minutes, and with the modified importer I see the exact same performance, within maybe 40 seconds. I'm running over a...

Thanks, this is awesome! I'll give it a shot this afternoon and report back with my findings.

I'm going to see if I can figure out how to get it to compile (I am also not a Rust developer) with that value changed to 8 and see if it has any impact on throughput. This is a great find, thanks for doing the legwork on this.

Sorry forgot to mention this in my original post. No, I have no snapshots on the machine. We do have some other options, but I'll admit that at this point my curiosity has gotten the better of me and, options aside, I'd like to understand what's going on here and why it's so slow.

For reference, we're doing a 2x10Gb -> 2x10Gb transfer and we're seeing a rate of roughly 50GiB import in 20 min. EDIT: When we do the same import via Veeam restore we're able to import the disk in ~6 minutes.

I've seen similar results in my limited testing. I'm able to pull the machines across the wire much faster using `scp` but then you lose out on the ESXi importer magic. You can go create the VMs and import the disks by hand but I was hoping to avoid doing that as it adds a lot more opportunity...

From what I'm able to tell it doesn't seem that I'm hitting CPU limits. On the Proxmox side the import tool is using 11% of a CPU core and on the ESXi side I don't see anything using a full core.

I've recently been experimenting with the ESXi import process in preparation for a migration from VMware to Proxmox. I'm having an issue where the disk import process runs extremely slowly. I've got a 10 Gb link between the ESXi host and Proxmox (verified with `iperf3` tests between the boxes on...