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 ?
Posts made by gb.123
-
RE: XCP-ng 8.3 beta π
-
RE: USB Passthrough Override Script - to ensure usb-policy.conf consistency
I have another suggestion:
We can simply make a usb-policy.conf builder in XO; where the user can add/remove/edit the filters using GUI and the XO pushes the file after re-building it at every update ?
This should be simple enough and the base XCP-ng would not be touched at all (still be close to upstream Xen!
Of course the caveat is that the user has to update using XO; not directly run
yum update
since in that case XO would not know. (We can build a manual push-override in XO for that like you do for VxLAN certificates)This is assuming pushing a custom file through XAPI is possible .....
-
RE: USB Passthrough Override Script - to ensure usb-policy.conf consistency
@stormi said in USB Passthrough Override Script - to ensure usb-policy.conf consistency:
What we could do short term would be diverging from XenServer's packaging of usb-policy.conf in two ways:
-stop overwriting the file when it has customizations
-add a big warning on top of file stating that were you to modify it, you would not get updates of this file anymore lest you manually watch for usb-policy.conf.rpmnew files to appear after an update, manually merge changes,, and not get support regarding USB matters anymore
This would achieve what your script does, in a much simpler way, but still give us some level of control. Configuration would still be overwritten when you upgrade to a newer release of XCP-ng, which whould also be mentioned in the warning.IMHO, this is not exactly a solution. User Information will still get overwritten and you would need to manage to store it elsewhere and copy paste it on every update.
The above solution is messy and I believe will cause even more tickets as user might 'forget' to re-install his changes and/or update manually.
Better solution IMHO, would be :
- Have a separate user config which probably says
#Start User config
and ends with#End user config
. - Build usb-policy.conf by removing default filters and injecting the above user config file at the appropriate place every-time you guys update and also re-build/inject when the file changes.
In the above way, the user-config will be saved and there should be no tickets stemming from this.
- Have a separate user config which probably says
-
RE: USB Passthrough Override Script - to ensure usb-policy.conf consistency
@stormi said in USB Passthrough Override Script - to ensure usb-policy.conf consistency:
Then I have no doubts that they will use it anyway (and that, someday, this will consume time from our support or developers because they forgot they've done it, and they upgrade to a newer XCP-ng, which erases the changes in /opt, and then they open forum thread or support ticket because the new release is "broken").
My intention was to help and not over-burden you guys. If you feel that this is going to create a havoc of 'tickets', I am taking this script down until you guys decide to use it in which case I would be happy to help.
PS: Once again, I am NOT taking this as an offence, just as a gesture so as not to bother the developers with unwanted tickets.
-
RE: USB Passthrough Override Script - to ensure usb-policy.conf consistency
First of all, I would like to thank you for your efforts in developing XCP-ng and my reply is not directed towards any objections / offence etc.
I am only trying to help everyone.
My following reply is also just a clarification of my understanding in the hopes that it will ultimately help the whole community.Somes files are not meant to be modified. usb-policy.conf was one of them. It still isn't.
Well this is a bit confusing. I am sorry but I was referring to your documentation here :
Passing through Keyboards & Mice
Where is is mentioned:
"xcp-ng host uses usb-policy.conf at /etc/xensource/usb-policy.conf ..... You can edit this file to allow these devices (and any other ones similarly)."Per my understanding of the Filesystem Hierarchy Standard, /opt/ is for files installed by users for the whole system outside the package management system, but user configuration related to this belongs to /etc/opt/.
You are right. But in my case the script itself is the "files installed by users for the whole system outside the package management system" and since my script is whole in itself and does not have any other configuration, I thought it was best to put in /opt as enumerated in your link, since I am treating my script as a whole package which includes uninstaller of the script also (which does not have configuration of the package (to put in /etc/opt), so to speak.)
And the best part is - You could simply remove my script and leave no 'crumbs' and have your system exactly like it was before installing my script simple by running my script with
--remove
command.We unfortunately get too many support tickets due to unwanted dom0 customizations for me to be thrilled by the perspective that many users that using a workaround script that is completely outside our control and (as far as I understood) is susceptible to overriding any future changes we make to the file. Or be used on the wrong version of XCP-ng in a few years. There are really many things to take into account as a maintainer.
I understand and very much appreciate your concern. Trust me I have gone through this.
I can therefore offer you this :- I will mention the XC-ng version this script is tested on in the first post.
- In case you guys change/plan to change anything in the usb-policy.config, just post the link to the new file and I'll change my script accordingly and post the new version alongwith the old one mentioning the version(s).
Another option:
If you include the script with your XCP-ng iso/installer, I can fork your repo in github and directly send you pull requests whenever you change the usb-policy.config so that the users would not need to install the wrong script even by mistake. And if you want further security, you could integrate this with XO so that the user can only edit the 'filter' portion of the file and not the header and footer. (Basically once XO builds and pushes the file, it sticks. Incase of change in base file, both XO & XCP-ng are changed together. Version mismatch can also be incorporated in the script to check that wrong versions are not over-written and user is given a warning so that they know the config has reverted to 'original'. This can also be replicated in XO-Lite since code base will be the same in both cases and therefore would conform to your XO6 standard in future.
^
Please note that the above is ofcourse free of charge as my dedication and contribution to help this community grow.We're not discussing the use case between ourselves, we're making a point towards upstream XAPI developers who didn't see the need I took the time to explain to them on behalf of our users.
I once again, very very much appreciate that you are doing this as usb is a critical part for others and me as well. I know this is used more in home-labs than in corporate environments but I believe there is enough userbase for this to make sense. So I very much appreciate that you are trying to make the upstream XAPI developers so that we can have a tighter and error free integration in future. However, as per my experience, I don't think that happening very soon as it is generally a herculean task to convince a big company. The smaller ones are more open to suggestion and development since they have a stronger drive to grow.
The first step before changing Xen Orchestra is providing the appropriate API at the XAPI level, where XAPI will manage the USB configuration changes asked by users. Adding it to Xen Orchestra, which is a XAPI client, would then likely be rather simple.
I very much agree with you and thats why I wrote 'in addition' to your suggestion. But as I earlier said, out of experience, I don't see that this happening very soon even though the best thing would be to incorporate this in XAPI as you suggested since it will be consistent with the whole software in general.
-
RE: USB Passthrough Override Script - to ensure usb-policy.conf consistency
Why don't you write your custom configuration somewhere in /etc?
Because updates seem to override my configurations. (I think we all are already aware of this issue)
It does not seem right to modify files under /opt, which is supposed to be untouched outside installation and update operations.
That's not true! The /opt folder in general in Linux is for user installed files(common files for all users)/ common applications which are generally not touched by OS updates so this is correctly placed as intended in this case.
Precisely the reason why this has been kept under /opt so that the updates don't over-write the files which are supposed to by already modified by the user !As with any dom0 customizations, anyone using this script, make sure you remember that it is there, understand what it does, and be ready to debug it if doesn't work or breaks something.
I know. This script's intension is to modify the config file in the usb-policy.conf under /etc/xensource folder. There is not much to remember, understand or debug as this a very very simple script which has been tested by me several times and I assure you there are 0 bugs ! This will hold true till the format of
/etc/xensource/usb-policy.conf
is not drastically changed (which seems very unlikely at this stage).What if we need to fix something really important in it, such as a security issue? Or it causes an issue that you don't immediately recognize as a consequence of the script, but then ask our support team to troubleshoot it?
Security issue ? Cause an issue that is not immediately recognized? It's almost impossible!
This particular file is just a list of allow & deny rights for USB. This script does NOTHING that the user himself/herself cannot do ! What would happen if the user changes the file manually and then comes to you for support ? You have already put this in your docs that the user should change this file if he wants pass-through of HID devices. And when this change is over-written without any warning, there is even more chance of the user approaching you for support. Atleast in this case you would know what exactly is being done!Infact I was hoping you guys would thank me for building this script so that you guys don't get support tickets due to wrong editing/ errors in editing
usb-policy.conf
manually by the user!As far as my script is concerned, I have not come to you for support and you have my word that I will NEVER come to you for support for this particular script !
A proper fix would be making XAPI include custom configuration from users, as I suggested to the XAPI project. You can share your use cases in the bug report, by the way: https://github.com/xapi-project/xen-api/issues/4935. Especially if they're in production setups.
As I have already mentioned here (Please refer to the Disclaimer which is literally the first line of the post !)
And here also, that :
this is supposed to be a workaround until you guys fix this issue.Is this the best implementation ?
No ! Absolutely not ! But what can we do till you ponder and finalize it in this issue : https://github.com/xapi-project/xen-api/issues/4935
To be fair, its been about a year and still its being 'pondered' upon if it is needed !Right now you are just discussing the 'use-case' (which for some of us are already using), I am assuming this would be months and months of wait till you even reach to stage of bug-testing let alone the release. (which is ok, considering the work you guys are doing and I know you guys have even more priorities with other features so this would probably be taking a back-seat)
Till this is done, you really don't expect us to just not do anything at all ?
Please note that my intention with this post was to help people and contribute to XCP-ng in any and every way I can !
If I can help other users, then I don't see the reason not to... Everyone is free to post any questions/bugs they have regarding this here and I'll try my best to answer them !Now for the implementation part :
What you suggested is Absolutely the right way to go about it. I welcome your suggestion and to add to your suggestion, the best way should be that we create another 'Tab' in the Xen-Orchestra GUI with label as 'USB' in the Host section besides the 'Advanced' tab (or maybe besides the 'Storage' tab)
Inside the Tab, we can have a section called 'Filters' which allows the user to add/edit/delete the filters line by line and the
usb-policy.conf
file gets generated and pushed by XAPI to the host. This file should be pushed at a place where is it not touched by updates. In case you want to update the base file due to any reason like security or update in APIs etc. , you can update the Xen Orchestra and the dom0 and then just re-build & re-push the user filters back using XAPI so that the user does not have to re-edit the filters every-time they update dom0. -
RE: XCP-ng 8.3 beta π
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.
-
USB Passthrough Override Script - to ensure usb-policy.conf consistency
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 preventusb-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 :
- Please save this script as install_usb_pass.sh
- Run
chmod +x install_usb_pass.sh
- Run
./install_usb_pass.sh
Instructions for Remove :
- Run
./install_usb_pass.sh --remove
- 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)
-
RE: XCP-ng 8.3 beta π
Any way to get the UUID of the Host using CLI ?
What I mean is not the list of hosts usingxe host-list params=uuid
but I only want to get the host uuid of the host on which the command is being run on. -
RE: XCP-ng 8.3 beta π
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.conf
on 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. -
RE: XCP-ng 8.3 beta π
In continuation of my previous post, I also noticed that any changes to
/etc/xensource/usb-policy.conf
are 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) -
RE: XCP-ng 8.3 beta π
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. -
RE: XCP-ng 8.3 beta π
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-devices
commands 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!
-
-
RE: XOSTOR hyperconvergence preview
Storage between the servers is not shared as a large file system like Gluster. Right?
So for example, each 4 hosts has 2TB storage then the max HD space is 2TBAs @stormi mentioned, this depends on your replication factor. It works like this for your example:
Total Space = (No of Hosts x Storage ) / Replication Factor
(Assuming you have same storage on all nodes)Eg. replication factor is 2, then :
Total Space = (4 x 2)/2 = 4 TB
Note:
What you have to keep in mind though is it also depends on each SSD you have so say if you put 1.5 TB SSD & 0.5 TB SSD, then although you have 2TB on each node, but if you create a VM with 1TB space, you will not be able to create another VM with 1TB since there will not be enough contiguous space. What it means is that XOSTOR will not split the VM disk on two separate drives in case of JBOD.
In case of Raid 0 at bios level, you may be able to get away with this but Raid 0 is not recommended.Is the NIC speed of the storage network important? Is 2x40G on each server for this overkill?
The question is generic and it actually depends on your workload and SSD speed (Gen4 or Gen5 or if you have an old Gen1). At the outset 2x40G seems to be more than enough for most applications. If you have a an old Gen1 SSD or SATA SSD, then you might not even reach the full bandwidth in case of 2x40GB (practically speaking).
What software raid on the NVME disks is recommended?
For going production with Nvme SSDs, I would not recommend RAID at all ! JBOD would work just fine.(Assuming your are using generic applications)
-
RE: EOL: XCP-ng Center has come to an end (New Maintainer!)
Very excited to receive a wonderful and detailed reply from @michael-manley.
Thanks @michael-manley for taking over the maintenance of XCP-ng Center!
-
RE: Xen 4.17 on XCP-ng 8.3!
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
-
RE: XCP-ng 8.3 beta π
I think it was to do with chrony not updating the time. There was a mismatch in system time.
-
RE: XCP-ng 8.3 beta π
When trying to run :
yum install xcp-ng-updater
I get this error :
http://mirrors.xcp-ng.org/8/8.3/base/x86_64/repodata/repomd.xml: [Errno 14] HTTPS Error 302 - Found
Anyone else getting this ?
I have freshly installed from the link mentioned in the blog : https://xcp-ng.org/blog/2024/02/15/xcp-ng-8-3-beta-2/
UPDATE: This may be due to mismatch in System-time. I updated Time with Chrony and it worked. Maybe a co-incidence but its working not and the error is not re-producable for now.
-
RE: SMB SR Creation Fails
@olivierlambert said in SMB SR Creation Fails:
(like maybe starting to select shared or not, but this might introduce complexity: we'll discuss that with @clemencebx )
Rather than selecting shared or not, we can simply have level of creation... eg. if created at pool level, it is shared, if at node level, then only connected to node.
That should help reduce complexity in UI.