XCP-ng 8.3 betas and RCs feedback 🚀

[stormi]

@xerxist Who says we're not doing both?

[stormi]

@Andrew @Anonabhar Indeed, it's not the same driver so the old card will keep using the old driver.

[john.c]

@cunrun said in XCP-ng 8.3 beta :

@john-c Yeah, tried all of that. I get the same issue with older GPU's when vGPU'ing them. So I'm wondering if it's a setting on the Dell Server BIOS.

Have you enabled SR-IOV in Integrated Devices on the Dell Server's BIOS?

[xerxist]

@stormi

It seems it would fix my iGPU passthrough issue with the NUC13

[xerxist]

@stormi

Which kernel are you looking at since 4.19 will be EOL in 9 months?

[ThierryC01]

I applied the very last batch of XCP-ng 8.3 updates and after a smart reboot (which took forever to complete and did not resume all my VM automatically), I have lost my ISO storage: the folder "/ISO" has been deleted by the update and the fstab has been overwritten. This is becoming annoying, I never ever had to "repair" anything related to my storage in my 20 years of using Vmware Esx but this is already the second time I have to do it in my 2 years of using XCP-ng and the very first time an update deletes a mounting point. I understand 8.3 is still a beta, hence my feedback.

[Tristis Oris]

@ThierryC01 Why are you using fstab?

[ThierryC01]

@Tristis-Oris Well, this is how local disks are mounted right?

[Tristis Oris]

@ThierryC01 possible way, but not only one. It recomended to configure nothing at dom0.

literally created 2nd local storage with 1 click:

[ThierryC01]

@Tristis-Oris Except that your method is to create the SR, mine already exists, is full of .iso files and could be wiped doing your method!!! The SR exists, I can see the list of files that should be there but it is marked as "disconnected".

[Tristis Oris]

@ThierryC01 iso sr can be mounted same way without wipe. I admit some cases where fstab is required, but not for this.

[ThierryC01]

Yeah... point is, the mounting point has been deleted and the fstab overwritten during the updates... as I mentioned in my post above.

[Tristis Oris]

@ThierryC01 well, such unpredictable thing shouldn't happens.

[stormi]

@ThierryC01 I don't see how an update could delete a /ISO folder on the system. An upgrade using the ISO, yes, because it actually reinstalls XCP-ng and migrates the configuration it knows about, but not a simple yum update. What happened exactly? How did you update?

[stormi]

An update will not overwrite /etc/fstab either, or there's a serious packaging bug somewhere. I will do some tests.

[stormi]

@ThierryC01 Is there a /etc/fstab.orig file on your system? If yes, does it contain the missing line about the ISO? And what's the output of rpm -q setup?

[ThierryC01]

@stormi Now that you mention that, I did perform an ISO upgrade I should not have performed would I known. Remember a few posts above. My bad...

[stormi]

@xerxist said in XCP-ng 8.3 beta :

Which kernel are you looking at since 4.19 will be EOL in 9 months?

So, the main blocker in the way to upgrade the kernel is a kernel module we use for storage access from the VMs. Work is being done to replace it, which will unlock the possibility to move to a newer kernel. Which version exactly will be chosen in due time. Likely a LTS kernel.

Meanwhile, XCP-ng 8.3 remains on 4.19, on which we'll continue to provide security fixes for vulnerabilities that may affect it in the context of dom0.

[xerxist]

@stormi

Thanks for the explanation.
Will this be added like what there is now as an alternative kernel?

[stormi]

@xerxist Possibly, but then only some storage drivers will work with it. This will mainly be for testing purposes and gathering feedback.