@olivierlambert I'm willing to dig in and provide any data. right now it's 10 VM's all with 1 disk each, i'm currently running a backup without NBD using my flash array as a NFS destination, it's a handful of fast samsung SAS 12 SSD's that are striped (they're 3.2TB each). When that finishes I'll flip NBD back up and re-run so at least I think that will take storage out of the equation I believe.

@Andrew Exporting all my large VM's worked on that branch.

@Forza Wow, I just tried that out and backup speed increased by 48%.

@HeMaN this may have actually worked...
In etc/network/interfaces

The primary network interface

allow-hotplug eth0
iface eth0 inet dhcp

This is an autoconfigured IPv6 interface

iface eth0 inet6 auto
post-up route add default via 10.10.10.1 dev eth0

auto eth1
iface eth1 inet static
address 10.10.5.188
post-up route del default dev eth1

@olivierlambert well I still can't have 2 networks in that VM, literally all I need to do is be able to set 10.10.10.1 in eth0 as the default gateway and I can find no way to do that. Debian is defaulting to eth1 with the backup network as default. I can find no persistent way to set a default gateway of my choosing.

@olivierlambert there no XO problem. I thought I figured out how to have a 2nd network on the debian XO VM but I'm at a loss. I spent half the night trying to figure out how to make a persistent default gateway in debian and nothing seems to work. Either the VM has no access on my first subnet or ONLY has access to the 2nd subnet if I did a defined route in interfaces file. This seems like such a simple thing but I've tried everything from every forum I can find.

@florent like Oliver was telling me, to compare secure to secure, it is faster than https,.still curious if anyway to try insecure.

Also. Is there a way to update XO (from sources) without losing the config.yaml or just a minor inconvenience until NBD is fully rolled into XO? (I assume we'll get told when we don't have to run custom config for NBD whenever it's ready?)

Shows my lack of Linux fu, the solution was flushing the default route in debian and then setting it to eth0.

Edit(2 hours later): ended up being so much more digging to make that a persistent change, but appears to be working after reboot now.

@olivierlambert So..the problem is I'm trying to add 2nd network to the XO VM that is attached to a 2nd PIF on the host to have a dedicated wire for backups. The backing up over that network works fine to the NAS(different physical box). But then the XO VM apparently decided to use eth1 for all it's web access instead of eth0 and therefore Google sign-in dies and you can't even ping google.com from debian terminal either.

I'm not sure the right way to fix that, my standard subnet is 10.10.10.0 and I use .5.0 and .4.0 for storage networks, each box had 3x10Gb lines run to it

@olivierlambert

I'm running from sources. I recently switched from master to florents test branch for NBD stuff and back to master.

commit 76bd5

Not sure what is going on, I've been using Google oauth to sign into XO for a couple weeks and now it suddenly stopped working and I haven't changed anything with the plugin settings or on google cloud. It's the only plug-in I have installed, I also use google SSO on some other applications on another VM and they all seem to be fine (KASM, portainer, etc)

InternalOAuthError: Failed to obtain access token
at Strategy.OAuth2Strategy._createOAuthError (/home/anthony/xen-orchestra/node_modules/passport-oauth2/lib/strategy.js:423:17)
at /home/anthony/xen-orchestra/node_modules/passport-oauth2/lib/strategy.js:177:45
at /home/anthony/xen-orchestra/node_modules/oauth/lib/oauth2.js:191:18
at ClientRequest.<anonymous> (/home/anthony/xen-orchestra/node_modules/oauth/lib/oauth2.js:162:5)
at ClientRequest.emit (node:events:513:28)
at ClientRequest.patchedEmit [as emit] (/home/anthony/xen-orchestra/@xen-orchestra/log/configure.js:52:17)
at TLSSocket.socketErrorListener (node:_http_client:502:9)
at TLSSocket.emit (node:events:513:28)
at TLSSocket.patchedEmit [as emit] (/home/anthony/xen-orchestra/@xen-orchestra/log/configure.js:52:17)
at emitErrorNT (node:internal/streams/destroy:151:8)
at emitErrorCloseNT (node:internal/streams/destroy:116:3)
at processTicksAndRejections (node:internal/process/task_queues:82:21)

@florent How would I verify for testing if its insecure NBD or not? I switched to your branch and rebuilt, I see the same message about not allowed but dunno if that matters.

@florent Yes to multiple blocks. I did see this in host>networks page.

I do (and did) have the preferNbd set.