XCP-ng 8.3 betas and RCs feedback π
-
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.
-
@ThierryC01 Why are you using fstab?
-
@Tristis-Oris Well, this is how local disks are mounted right?
-
@ThierryC01 possible way, but not only one. It recomended to configure nothing at dom0.
literally created 2nd local storage with 1 click:
-
@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".
-
@ThierryC01 iso sr can be mounted same way without wipe. I admit some cases where fstab is required, but not for this.
-
Yeah... point is, the mounting point has been deleted and the fstab overwritten during the updates... as I mentioned in my post above.
-
@ThierryC01 well, such unpredictable thing shouldn't happens.
-
@ThierryC01 I don't see how an update could delete a
/ISOfolder 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 simpleyum update. What happened exactly? How did you update? -
An update will not overwrite
/etc/fstabeither, or there's a serious packaging bug somewhere. I will do some tests. -
@ThierryC01 Is there a
/etc/fstab.origfile on your system? If yes, does it contain the missing line about the ISO? And what's the output ofrpm -q setup? -
@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... -
@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.
-
Thanks for the explanation.
Will this be added like what there is now as an alternative kernel? -
@xerxist Possibly, but then only some storage drivers will work with it. This will mainly be for testing purposes and gathering feedback.
-
Not to be negative but in a professional environment auditors will trip on this. No one wants to explain to auditors that its plastered from upstream somewhere. Also itβs good for new hardware support. But good to hear work is progress.
-
USB Passthrough Testing & Feedback :
Tested 2 Devices :-
-
16 GB USB Flash Drive - Transcend
Results : Works Perfectly -
ePass2003 Token (for Digital Signatures)
Results :Not Detected(See update)
Deep Diving :
lsusb&usb-devicescommands list the device (vendor id - 096e) on console (cli). However, the device is not shown in the 'Advanced' tab of the node/host.Maybe devices getting filtered only for USB Media / Flash Drive in Xen Orchestra ?Update :
Token also works now after editing :/etc/xensource/usb-policy.conf
as enumerated here.Thanks to @olivierlambert for the above link and prompt guidance!
-
-
Probably not in the white list of device type. Read https://docs.xcp-ng.org/compute/#οΈ-usb-passthrough for more details.
-
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?
