@stormi

WHAT THIS VERSION OF XEN CHANGES

I must admit I haven't done my homework yet here. You can check the upstream changelogs at the Xen Project. I'll update this post if someone provides a useful bullet list.

Here you go :

Notable Features
This release has seen the increase in hardware support for both x86 and Arm, together with the addition of other improvements and features:

• MISRA-C integration: The project has officially adopted four directives and 24 rules, added MISRA-C checker build integration, and defined how to document deviations. A number of MISRA-C violations have been fixed.
• Static configuration options for ARM: In many embedded environments, we know ahead of time exactly what resources all guests will need at boot time. In constrained resource environments, allocation on use increases the possibility that the allocation will fail at runtime. With static configuration, resources are allocated statically when the hypervisor boots, removing the possibility of runtime failure. Resources which can be statically configured as of 4.17 include event channels, shared memory, and hypervisor heap.
• ARM: Add “tech preview” implementation for VirtIO. Xen now includes full support for VirtIO on embedded systems, on ARM, for the virtio-mmio transport, allowing a wide range of VirtIO devices to be supported. This includes front-end support in Linux, toolstack (libxl/xl) and dom0less support, and a userspace backend. Currently, the following stand-alone backends are available and have been tested: virtio-disk, virtio-net, i2c, and gpio.
• dom0less / Hyperlaunch: cpupools can be specified at boot using device tree. This allows the use of cpupools in dom0less / Hyperlaunch -style configurations; in particular, it makes it possible to assign different types of CPUs of an ARM big.LITTLE system to different cpupools at boot time.
• dom0less / Hyperlaunch: PV frontend / backend connections can now be specified between guests, allowing statically booted guests with PV devices
• On ARM, p2m structures are now allocated out of a pool of memory set aside at domain creation; this provides better isolation between guests against memory resource failures
• ARM: Mitigations against Spectre-BHB
• x86: IOMMU superpage support for all guest types; improving performance of PCI pass-through
• x86: Security support hosts with up to 12 TiB of RAM
• x86: Can now set cpuid parameters for dom0 at boot time
• x86: mwait-idle support: Added SPR and ADL
• x86: Improved speculative mitigation support, including VIRT_SSBD and MSR_SPEC_CTRL features to help guests know what speculative mitigations they don't need to be done (due to mitigations on the hypervisor side), and to control what kind of speculative mitigations the hypervisor performs on their behalf
• Out-of-tree builds for the hypervisor now supported
• ARM: Since addition of Zephyr RTOS guests support (Xen 4.15, Zephyr 3.1.0), work has been done on making it possible to run Zephyr in dom0 improving boot time, stability and paving the way for future safety certification for Xen-based systems

Source : https://wiki.xenproject.org/wiki/Xen_Project_4.17_Feature_List

@olivierlambert @stormi

I have a suggestion w.r.t interface-rename.
Can we have a screen at the installation (using iso method) which lists all the NICs and we can rename the interfaces at install time itself ?

Installed in my Homelab. Install went smoothly.

Small bugs I have noticed :
1.

This ONLY happens when using KVM and 'scaling' the display to fit window.

This happens ONLY on the first boot after applying patch ( 6 programs ) once release iso is installed.
This goes away from the second boot.

Everything seems to be working smoothly for now. Kudos to the Vates Team !

For everyone who needs to ensure usb-policy.conf remains 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.

@olivierlambert

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.

Very excited to receive a wonderful and detailed reply from @michael-manley.

Thanks @michael-manley for taking over the maintenance of XCP-ng Center!

Hello,

I don't know how many people use this so as per discussion with stormi, the has been removed. If you would like the script to be back, please upvote this post. Once there are enough upvotes, I'll post the script back. Thanks.

Disclaimer:
This script is made as a workaround to prevent usb-policy.conf from getting overridden by new patches/restarts.

Testing Status:

• XCP-ng version 8.3 - Works.
• XCP-ng version 8.2 - Untested. (Should Work)
• Other versions - Completely Untested. Do not use unless you know what you are doing !

Instructions for Install :

1. Please save this script as install_usb_pass.sh
2. Run chmod +x install_usb_pass.sh
3. Run ./install_usb_pass.sh

Instructions for Remove :

1. Run ./install_usb_pass.sh --remove
2. Restart host to complete Uninstallation (this is temporary till I fix last 2 lines of the code)

Script Code

Removed for now, in the interest of not overburdening over lovely devs !
[See Post](https://xcp-ng.org/forum/post/73783)

Installed in my Homelab. Install went smoothly.

Small bugs I have noticed :
1.

This ONLY happens when using KVM and 'scaling' the display to fit window.

This happens ONLY on the first boot after applying patch ( 6 programs ) once release iso is installed.
This goes away from the second boot.

Everything seems to be working smoothly for now. Kudos to the Vates Team !

@stormi said in XCP-ng 8.3 betas and RCs feedback :

http-nbd-transfer-1.4.0-1.xcpng8.3: XOSTOR-related fixes

Does this mean XOSTOR is ready to be tested in 8.3 ?

@bufanda @yann

Thanks for the tip ! Anyway to delete the crontab created for root ? Or it is not required (since it is blank anyways) ? (I should have just used crontab -ir)

@stormi

I also noticed that I get an option to "Upgrade" to RC1 from beta 2. This should technically not happen since I installed beta 2 in Legacy BIOS mode and am now installing RC1 in UEFI mode since the former would be deprecated.

Is that an error in installer or upgrade is possible ?

@stormi @olivierlambert

I have also successfully run a test install of RC1 on my lab. Everything seems to be working fine. The TLS issue also seems to go away (will also put a separate post on the topic concerned).

Good Job guys !

One thing I noticed :

I seem to get an error message

no crontab for root

while running crontab -e the first time.

Is that normal? Is it ok to run a cron job for root ?

@bufanda @jivanpal

Thank you soooo much for your valuable answers !

@stormi

Thanks for letting me know about the deprecation. I missed seeing it in XCP-Ng 8.3 Beta 2 while I was testing it using the ISO install method.
I believe there is no 'upgrade' path from BIOS to UEFI? ( I would need to completely re-install the host again... right ?)

Does XCP-ng have the option of secure boot when installing from iso? (I am not talking about the Guest VMs here)

Hello @stormi @olivierlambert

Is there any real performance difference between installing XCP-NG host on BIOS mode vs installing it on UEFI mode? (Not the VMs, I mean the host itself)

Is there any benefit of installing xcp-ng using uefi, considering we can still have uefi VMs even if we install the host in BIOS mode... correct ?

@olivierlambert @stormi

I have a suggestion w.r.t interface-rename.
Can we have a screen at the installation (using iso method) which lists all the NICs and we can rename the interfaces at install time itself ?

@planedrop said in Get Properties of VxLAN:

@gb-123 Yeah I do think it'd be really nice to have all the info exposed in the GUI, not sure if there are any plans for that, but I like the idea.

+1 for this but I think the Devs are busy with other important features.

@BenjiReis said in SDN Controller Errors:

@gb-123 The tunnel are numbered by order of creation by XAPI, you can't change them.

Bug Report: At the time of adding a host to existing GRE/VxLANs in the network, the XAPI takes into account the Alphabetical name while creating the tunnel numbers. Specific Eg.:

1. Add 2 Hosts to a pool.
2. Create VxLAN called "VxLAN" -> This will be created as tunnel0
3. Create GRE called "GRE" -> This will be created as tunnel1 (since tunnel0 already exists)
4. Add new Host.

Error : New Host will have GRE as tunnel0 and VxLAN as tunnel1

I don't know if the above happened to me as a one-time case scenario or there is a bug, but worth a check.

You should take a look a look at XO's logs to see if you can find something that might trigger the SDN controller.

Does the host added frequently has another weird behavior?

Can you let me know the file I should see the log or should I look for journalctl ?
The weird behavior is that after several restarts, the VM gets connected and then after restart looses connection again. But I noticed whenever a VM is started on a host, the Host gets added to the SDN as per the logs above.

Just a last question which I need to further diagnose this-
Does the Host ever call on XO or is it always XO that calls on the Host (Server-Client)?
Or do they use WebSockets connection (so that the host does not need to call XO) ?

What would happen if I turn off XO after creating a SDN network ?

@BenjiReis

Update 4 :
The GRE connection works, but us spotty at times. Sometimes, the VM doesn't connect, but if I restart the VM several times, it starts to connect. This is when I have not changed any setting between starts.

(From what I remember, it was working perfectly in 8.2.1. Do you think this is a problem with 8.3 beta ? )