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.

@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...

stormi created this issue in xapi-project/xen-api

open USB 3 for vUSB #6389

@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

@olivierlambert @hitechhillbilly

I don't see any indications that it's capped at 16... it's at least 16 with a VGPU, but otherwise the value is just passed through to QEMU (which might do some capping of its own ...)

You should be able to see how much your VM booted with:

xe vm-param-list uuid=VM_UUID | grep video_mib

And set it to a bigger value with:

xe vm-param-set uuid=VM_UUID platform:videoram=32

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

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

@panzersrmm I don't think these are saved in the XAPI VM object (that you are querying with xe) - these are tracked by XOA itself.

@xen-orchestra ?

@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

@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.

@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?

@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/)

@TITUS-MAXIMUS You are correct. Sorry, the command to run is /opt/xensource/libexec/xen-cmdline --get-dom0 xen-pciback.hide - does this return anything? what's the return code of the command?

@TITUS-MAXIMUS --get-dom0 being empty means no PCI devices were hidden from dom0 either, did you follow this step of the guide? https://docs.xcp-ng.org/compute/#2-tell-xcp-ng-not-to-use-this-device-id-for-dom0

@TITUS-MAXIMUS Could you please attach /var/log/xensource.log from the time of the error? Would be very useful to have a backtrace from where the error occurs