@DustinB3403 said in Troubleshooting poor network performance:

@DustinB3403 said in Troubleshooting poor network performance:

Moving from that port which was only giving 10FDx to an unused port, gave us 1000FDx.

I'm not sure where this issue stems from..

Got it sorted out, for some reason (and I'm still working on the specifics) our ESXi hosts secondary NIC keeps falling to 10FDx (likely some misconfiguration at setup).

I've moved XO off of this nic, and performance has been fixed.

If you want to improve ESXi performance, install KVM.

Registry editor:

Hkey_local_machine\system\currentcontrolset\services\nlasvc\parameters\internet
Open- enableactiveprobing

Change value data from 0 to 1

Ok and Restart the computer.

This removes a warning that does not mean what it claims to mean. It is a bad warning that end users should normally not see as it is false and confusing.

Working with Postfix and got some hidden characters that were killing my file. So hard to find. But here is how you do it. In this example it is for the vmail_mailbox file, but this applies to just anything.

tr -cd '\11\12\40-\176' < vmail_mailbox > vmail_mailbox_clean

@Obsolesce said in V2V Migration - Going from Hyper-V to ESXi:

@CCWTech said in V2V Migration - Going from Hyper-V to ESXi:

I know @Oksana is here, maybe she can give some input.

That's just a marketing account most people block.

I've been out drinking with Oksana.

If you want to use Castopod, you almost certainly want to connect it to an S3 bucket. But the documentation on the site is missing a couple critical elements. The bucket must be specified and the format of the host needs the header. Here is an example configuration from the end of the .env file.

media.fileManager="s3"
media.s3.endpoint="https://s3.us-east-001.backblazeb2.com"
media.s3.bucket="bucketname"
media.s3.key="mykeyID"
media.s3.secret="mykeySecret"
media.s3.region="us-east-001"

This took some tracking down. The media.s3.bucket is absolutely critical, but does not appear in the documentation. The https:// I'm told is required as it prefixes bad data without it.

Turns out it is an App Armor restriction that Unity hasn't mentioned anywhere in their documentation even though we are at LEAST two releases into this problem. The fix is simple, but should be part of the install docs.

This is the error for the search engines:

No usable sandbox! Update your kernel or see Chromium Docs - Linux SUID Sandbox Development 48 for more information on developing with the SUID sandbox. If you want to live dangerously and need an immediate workaround, you can try using --no-sandbox.

To Test:

sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

And then for the real fix: /etc/sysctl.d/unity.conf

kernel.apparmor_restrict_unprivileged_userns=0