@JamesG it should be compatible, yes.

you can check the current command-line value with /opt/xensource/libexec/xen-cmdline --get-dom0 xen-pciback.hide and add all 81-84 devices with --set-dom0

@JamesG Could you pass through 81-84 manually and confirm that it actually fixes the issues for you?

@JamesG You can still manually use xen-cmdline to pass through 81-84 to the VM on 8.3 (this is in fact what xe pci-disable-dom0-access does behind the scenes).

I'll try to see why other devices are omitted and how this can be fixed.

@michael.manley Would it be possible to backport the XSA-498 fixes? I've tried updating the SDK as a whole but it resulted in a lot of churn and caused errors elsewhere: https://github.com/xcp-ng/xenadmin/pull/271

The fixes to the SDK have been posted here https://github.com/xapi-project/xen-api/pull/7176 and here: https://xenbits.xen.org/xsa/advisory-498.html

@Andrew That means you likely don't have any "leaked" VBDs

@Andrew @flakpyro I've updated the script, could you try running it again?

https://gist.github.com/last-genius/edf7dab3b1847ec5bb1d9917996eba41

@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

@pkgw Planning an RPU as a whole is a nice idea in theory, but it's inherently designed to co-exist with normal pool management operations (you should still be able to migrate VMs between hosts B and C during it, or start new ones), we are not "pre-booking" memory and other resources for groups of VMs, otherwise it can quickly make the rest of the pool hard to manage while some VM migrations could still be far away.

Regarding the narrower case - I'll note this down and see if we can improve things, thank you!

@MajorP93 Could you attach /var/log/xensource.log from the time of these issues on the destination host? We want to understand what squeezed is thinking and why it doesn't rebalance the memory.

@florent @fcgo the host that was queried (with host_ip/export_raw_vdi) will do the export from the shared SR, and will redirect the query to the host that can see the SR otherwise. So it's up to the XO/other orchestrators if they want to distribute the load here.

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