XCP-ng 8.3 betas and RCs feedback 🚀
-
Thanks for the prompt reply !
You are right. The device was filtered. I am now removing from filter and re-testing.
Update: Re-tested and everything seems to work fine.
I will further try to use the signature device to see if it actually works inside the VM.PS: I see no reason to filter tokens by default. Can we remove the DENY line for smartcards by default ?
We also need to add :DENY: Class=03 subclass=00 prot=00 # HID
as this class is used by some MSI motherboards for HID. Since rest of the HID are filtered, this should be added too for consistency sake. -
So which page do need to refer my auditor to for all the patching that is done once the kernel is EOL?
-
In continuation of my previous post, I also noticed that any changes to
/etc/xensource/usb-policy.confare reverted in case of updates. I also notices this reverting in case of restart (but need to confirm this after thorough testing as it may be one-time senario) -
@gb-123 In case of restart I never had it reverted only in case of update. After an update I just run an ansible playbook to add my whitelist entries again. sure it's a work around and some include file like usb-policy.conf.d/*conf would be nice to have.
-
It reverted for me once in case of re-start but that has not happened the second time. That's why reported it as 'one-time' scenario.
I agree having usb-policy.conf.d/*conf would be nice to have.
For workaround, I am working on a script to over-write
/etc/xensource/usb-policy.confon every reboot (should take care of the updates as well). This is a crude way of doing it but this is just meant as a workaround rather than a long term solution which is adding the conf in something like usb-policy.conf.d/*conf as you mentioned. -
Any way to get the UUID of the Host using CLI ?
What I mean is not the list of hosts usingxe host-list params=uuidbut I only want to get the host uuid of the host on which the command is being run on. -
@gb-123
cat /etc/xensource-inventory | grep -i installation_uuid -
@Tristis-Oris Thanks a Lot!
-
For everyone who needs to ensure
usb-policy.confremains intact after update/reboot, I have posted a workaround script here.Please note this is a workaround script only till a better implementation is done by the xcp-ng team.
-
@xerxist said in XCP-ng 8.3 beta
:So which page do need to refer my auditor to for all the patching that is done once the kernel is EOL?
Just in case I’ve asked Lawerence on Youtube what his thoughts are on promoting EOL products to his clients
-
https://xcp-ng.org/docs/releases.html#all-releases
Latest LTS: XCP-ng 8.2 Using the Long Term Support version is relevant if: you want to be sure the system will stay stable you want to **have all security fixes** without doing major upgrades every year you want a predictable migration path on a longer timeframe you don't care about new features coming for the next years LTS releases are supported for 5 years.XCP-ng 8.2 still has about a year and 3 months left of support.
-
That is not the point I’m trying to make.
The heart of the OS is going to be end of life December this year. You can probably plaster away but you need to keep track of everything for cve’s etc.. if you don’t want an auditor to trip on this. As they will because it’s end of life. -
@xerxist The Linux kernel is not exactly the heart of XCP-ng. Xen is. Also, the threat model is different from that of a Linux distribution, because the main threat here comes from VMs (privilege escalation, information disclosure, DoS...), and this is taken very deep care of, at every level.
XCP-ng's management network being meant to be on a dedicated network, not exposed to direct attackers, makes network attacks a lower threat but of course doesn't negate it so it still is to be taken into account.
Your concerns are valid, especially regarding how to make an auditor accept that it is actually maintained for the scope of XCP-ng's needs, and we're looking how to document it.
-
Yesterday, as I was about to walk out of the office for a deposition, someone walked in and said the connection to oen of the VM's was dead.
I opened up Idrac to the Dell host (Dell Inc. PowerEdge R540) and found a black screen unlike any I've seen before with XCP-NG; my vague recollection was a standard linux screen with "system" or something like that. I had twenty minutes to get to the deposition so I didn't have time to do normal debugging so I rebooted the host and watched as it did a normal reboot. It came back and all was well.
Now that the dust has cleared, this is my first chance to look into what happened. Where do I start? /var/log/xensource.log? /var/log/kern.log? Something else?
Thanks!
-
@archw Some information at https://docs.xcp-ng.org/troubleshooting/log-files/
-
I have been installing 8.3 beta 2 on a variety of different server grade hardware in the last week. (HP DL325, HP DL20, Lenovo SR250V2) and all have worked without issues however the issue posted by myself and @rmaclachlan above in regards to networking bonds not reporting the proper speed still remains.
I am also seeing lots of xcp-networkd errors in xensource.log Feb 23 11:41:17 xcpng-test-01 xcp-networkd: [error||3 ||network_utils] Error in read one line of file: /sys/class/net/bond0/device/vendor, exception Unix.Unix_error(Unix.ENOENT, "open", "/sys/class/net/bond0/device/vendor")\x0ARaised by primitive operation at Xapi_stdext_unix__Unixext.with_file in file "lib/xapi-stdext-unix/unixext.ml", line 90, characters 11-40\x0ACalled from Xapi_stdext_unix__Unixext.buffer_of_file in file "lib/xapi-stdext-unix/unixext.ml" (inlined), line 177, characters 31-83\x0ACalled from Xapi_stdext_unix__Unixext.string_of_file in file "lib/xapi-stdext-unix/unixext.ml", line 179, characters 47-73\x0ACalled from Network_utils.Sysfs.read_one_line in file "ocaml/networkd/lib/network_utils.ml", line 156, characters 6-33\x0A Feb 23 11:41:22 xcpng-test-01 xcp-networkd: [error||3 ||network_utils] Error in read one line of file: /sys/class/net/bond0/carrier, exception Unix.Unix_error(Unix.ENOENT, "open", "/sys/class/net/bond0/carrier")\x0ARaised by primitive operation at Xapi_stdext_unix__Unixext.with_file in file "lib/xapi-stdext-unix/unixext.ml", line 90, characters 11-40\x0ACalled from Xapi_stdext_unix__Unixext.buffer_of_file in file "lib/xapi-stdext-unix/unixext.ml" (inlined), line 177, characters 31-83\x0ACalled from Xapi_stdext_unix__Unixext.string_of_file in file "lib/xapi-stdext-unix/unixext.ml", line 179, characters 47-73\x0ACalled from Network_utils.Sysfs.read_one_line in file "ocaml/networkd/lib/network_utils.ml", line 156, characters 6-33\x0A Feb 23 11:41:22 xcpng-test-01 xcp-networkd: [error||3 ||network_utils] Error in read one line of file: /sys/class/net/bond0/device/device, exception Unix.Unix_error(Unix.ENOENT, "open", "/sys/class/net/bond0/device/device")\x0ARaised by primitive operation at Xapi_stdext_unix__Unixext.with_file in file "lib/xapi-stdext-unix/unixext.ml", line 90, characters 11-40\x0ACalled from Xapi_stdext_unix__Unixext.buffer_of_file in file "lib/xapi-stdext-unix/unixext.ml" (inlined), line 177, characters 31-83\x0ACalled from Xapi_stdext_unix__Unixext.string_of_file in file "lib/xapi-stdext-unix/unixext.ml", line 179, characters 47-73\x0ACalled from Network_utils.Sysfs.read_one_line in file "ocaml/networkd/lib/network_utils.ml", line 156, characters 6-33\x0A Feb 23 11:41:22 xcpng-test-01 xcp-networkd: [error||3 ||network_utils] Error in read one line of file: /sys/class/net/bond0/device/vendor, exception Unix.Unix_error(Unix.ENOENT, "open", "/sys/class/net/bond0/device/vendor")\x0ARaised by primitive operation at Xapi_stdext_unix__Unixext.with_file in file "lib/xapi-stdext-unix/unixext.ml", line 90, characters 11-40\x0ACalled from Xapi_stdext_unix__Unixext.buffer_of_file in file "lib/xapi-stdext-unix/unixext.ml" (inlined), line 177, characters 31-83\x0ACalled from Xapi_stdext_unix__Unixext.string_of_file in file "lib/xapi-stdext-unix/unixext.ml", line 179, characters 47-73\x0ACalled from Network_utils.Sysfs.read_one_line in file "ocaml/networkd/lib/network_utils.ml", line 156, characters 6-33\x0A My bond interfaces in XO report as running at 0 b/s as well -
I have recently installed 8.3 beta and all update patches over it... It seems to be running fine for me (on AMD).. Should I go ahead and install XOSTOR over it and see if that works ?
-
XOSTOR isn't entirely ready on 8.3 yet (at least it's not on the latest bug fixes level)
-
So I got a weird one. I have installed the latest XCP 8.3 updates and rebooted my server. All the VM's I had on my test server worked perfectly fine except for a single Debian 9 VM that would start booting and then "power off" just as the kernel started to spit stuff on the display.
I banged around with it for a while and what I found is its a kernel crash somewhere when SMP is initialized. If I only give a single vProc to the VM, it boots normally and all works fine.
At this point, its not causing me any more problems because I jsut rebuilt the VM on something more modern (Rocky 9)
I have perserved this VM if the dev's would like to get more debugging information or wish to try anything. I can also capture the logs if its of interest.
-
