andriy.sultanov

I've got a fix for this issue in the pipeline and would really appreciate if anyone here could test to confirm if it resolves the problem for you.

You'd need to install a custom build (not production-ready, be careful, all the usual warnings apply here) according to these steps:

0. Before updating, preferably check that exporting a particular VM with compression on results in the timeout error consistently.

1. Write the following file to /etc/yum.repos.d/xvatest.repo:

[xva-test-repo]
name=xva-test-repo
baseurl=https://koji.xcp-ng.org/repos/user/8/8.3/asultanov1/x86_64/
enabled=0
metadata_expire=1m
gpgcheck=1
repo_gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-xcpng

2. Make sure you're up to date on the rest of your packages with yum upgrade --enablerepo=testing (reboot if necessary)
3. Install the fix (this should install *.xvafix.1 packages):

yum upgrade xapi-core qcow-stream-tool vhd-tool --enablerepo=xva-test-repo

4. Restart the toolstack:

xe-toolstack-restart

@ph7 This update only covers the security issue described above. Fix for the stats issue will roll out later.

@chicagomed Could you (and others with the issue) please post the output of lspci -mnn for the devices that are not shown in xe pci-list?

XAPI filters for PCI devices with classes 01XX, 02XX, and 03XX as a safety measure (better to be safe than sorry in avoiding passthrough of critical devices), but perhaps we could reasonably expand this filter.

@flakpyro I'll add some additional error-checking, but looks like you're affected by the snapshot_of issue and should run another script (yes, I know...) to fix these stale references: https://github.com/xcp-ng/xcp/blob/master/scripts/snapshot-fixer.py

@jivanpal We do not currently have any plans to support elliptic curve keys - this is a very sensitive topic given different governmental security requirements around the world.

Note that Let's Encrypt recommends a dual setup for this exact reason: "Our recommendation is to serve a dual-cert config, offering an RSA certificate by default, and a (much smaller) ECDSA certificate to those clients that indicate support." (https://letsencrypt.org/docs/integration-guide/)

@jmannik Please upload your /var/log/xensource.log from the time of the error, otherwise it's hard to see what went wrong

@panzersrmm

@panzersrmm said in "Block migraton" option on the VM´s Advanced tab:

Hi! Is there a VM parameter that saves this "Block migration" UI button?

I wasn't able to identify which one it is with command:

xe vm-param-list uuid=<VMuuid>

Thank you!

How do you mean? Is the XO option not persistent?

XO sets these parameters:

# xe vm-list uuid=$UUID params=blocked-operations
blocked-operations (MRW)    : pool_migrate: true; migrate_send: true

Which you can set like this yourself:

# xe vm-param-set uuid=$UUID blocked-operations:migrate_send=true
# xe vm-param-set uuid=$UUID blocked-operations:pool_migrate=true

@techjeff I'll fix the script to not choke on empty lines - thanks for the spot!

Our documentation (https://docs.xcp-ng.org/compute/#passing-through-keyboards-and-mice) does say to run usb_scan.py -d to verify the config file, though the error wasn't particularly helpful...

The config file also specifies its "syntax is an ordered list of rules", maybe the fact that the order is important could be worth emphasizing even more?

@olivierlambert The only discussion about USB3 that I'm aware of is about making USB3 passthrough faster (https://github.com/xapi-project/xen-api/issues/6389). Not being able to see them in the guest OS at all would indicate a different issue...

@Greg_E Thanks, but that will not be necessary - I think I've figured out where the problem lies now. Good luck with the move