Search results

Verify speed: 1068.22 MB/s is a bit curious given the rest of the numbers.. but I guess this should be amortized when processing chunks in parallel. the TLS speed also looks better than your actual throughput. dd-ing /dev/zero is not a valid benchmark at all, in particular if you are using ZFS...

what does "proxmox-backup-client benchmark --repository <...>" say if you run it on one of the PVE hosts? at what speed does a single backup task peak? might be that the actual transfer over HTTP 2.0/TLS with a single TCP connection is your bottle neck

if you have access to the guest volumes in a format that Qemu understands (e.g., flat vmdk or plain raw) you can import those and try to recreate matching configs on the PVE side. it might take a bit of fiddling and guess work, depending on how your guests were set up on ESXI.

https://bugzilla.proxmox.com/show_bug.cgi?id=3881

https://bugzilla.proxmox.com/show_bug.cgi?id=3233 persistent bitmaps are tracked here, in case you want to get notified about updates

yes, it tries to log into your ESXI because it uses the API to query guests and their configs and their volumes.

bei PBS, ja. (wenn du per CLI meinst - du kannst das interfaces config file selber anpassen wie du moechtest ;)).

you can run `dhclient` or manually configure an address (before or after chrooting)

stop mode backup will just stop the VM and then start it paused to ensure consistency. it will then setup the copy-before-write-filters before starting actual guest execution.

yes, exit that first shell, then you end up in a second shell with more features and binaries!

sounds like you might be in the wrong shell if you are using the debug mode of the installer (the first time you are dropped in the initrd stage, the second time is a more complete environment).. you can pick any writable folder as the target though, just adapt the rest of the commands

boot a live cd (the installer environment in debug mode should work as well), then basically follow https://pve.proxmox.com/wiki/Recover_From_Grub_Failure#General_advice , but instead of the last few steps with proxmox-boot-tool, reinstall the kernel package after chrooting.

yes, the "priv/lock" dir is special-cased to handle lock expiry (after 120s, with calling code only holding the lock for 60s) - because otherwise if the node gets fenced or crashes between the mkdir and the rmdir you end up locked forever.

https://git.proxmox.com/?p=pve-cluster.git;a=blob;f=src/PVE/Cluster.pm;h=bdb465f710aa5b4135e0f23fc85d9b11c6b5ffec;hb=HEAD#l603 https://git.proxmox.com/?p=pve-cluster.git;a=blob;f=src/pmxcfs/memdb.c;h=77d76526e9052de3befa8ef551c6ef5c9e4b1427;hb=HEAD#l330 might be of interest - but please be...

PBS selbst ist es egal woher hostname/IP kommen, du kannst lediglich nicht die eingebaute netzwerk management API/UI verwenden wenn du auf DHCP setzen willst..

as far as we know, both 6.17.4-2 and 6.17.9+ should not be affected by that problem anymore. there is an upstream proposed fix (instead of the revert we are currently carrying), we will provide a test kernel with that once it has gotten some more feedback, and would appreciate people with...

Authorized uses only. All activity may be monitored and reported. channel 2: open failed: connect failed: open failed your SSH config is likely not suitable for migrating using SSH.

I don't think there is yet..

could you check the logs of the PBS system and the backup writer and reader task logs as well?

is there anything sitting between your PVE and PBS host that might drop the connection prematurely?