XO from source
Problem: XO5 is disconnected and stuck on "Still Loading" (see picture below)
When trying later commits after XO6 became default. XO5 has broken entirely. And I have not been able to solve this yet.

Troubleshooting steps are the following:

git reset --hard <commit hash>
rm node_modules/ -rf
yarn
yarn build

Whilst XO6 is working as expected. There are lots of functions that need XO5. Which is why I haven't noticed this until just now (today).

Last known good Commit: 4b4c9b91f3722401a7d3eb2eaf549980fd2f3e5b
This is also where I had XO6 in preview mode and XO5 working perfectly fine next to each other.

Screenshots:

• Still Loading
  

@olivierlambert said in ️ XO 6: dedicated thread for all your feedback!:

So I quickly experimented different "identities"/themes.

Here is "Nord" in dark mode:

Please add this. This was gorgeous!

@dinhngtu said in XCP-ng Windows PV tools announcements:

@probain The canonical way is to check the product_id instead https://docs.ansible.com/projects/ansible/latest/collections/ansible/windows/win_package_module.html#parameter-product_id The ProductCode changes every time a new version of XCP-ng Windows PV tools is released, and you can get it from each release's MSI:

No problem... If you ever decide to have the .exe-file as a separate item. Not bundled within the zip-file. Then I would be even happier. But until then, thanks for everything!

Would it be possible to either have direct links to the exe's without them being zipped? Or list the version number of the xen-guest-agent.exe?

I'm installing these through Ansible (see code below). And it would be way cleaner if either of those two wishes could be true.

    - name: Install Xen Guest tools on Windows hosts
      when: ansible_system == "Win32NT"
      tags: xcp_ng
      block:
        - name: Install Xen Guest Tools
          when: ansible_virtualization_type == "xen"
          block:
            - name: Copy over Latest Xen PV drivers
              ansible.windows.win_copy:
                src: "XenTools-x64_{{ xen_guest_agent_version }}.msi"
                dest: "C:\\Users\\{{ ansible_user }}\\Downloads\\XenDrivers-x64.msi"
                force: true

            - name: Install XenDrivers if the version isnt already created
              ansible.windows.win_package:
                path: "C:\\Users\\{{ ansible_user }}\\Downloads\\XenDrivers-x64.msi"
                creates_path: C:\Program Files\XCP-ng\Windows PV Drivers\XenGuestAgent\xen-guest-agent.exe
                creates_version: "{{ xen_guest_agent_version }}"
                arguments:
                  - /quiet

Noticing that the NIC for Realtek RTL8139 shows up as "-" in VM System

The Intel e1000 works as intended though.

@pdonias said in ️ XO 6: dedicated thread for all your feedback!:

@jr-m4 Thanks for the feedback! I tried to reproduce that but I don't seem to get the same behaviour. Let me make sure I understood:

• You select a template
• VDI names get prefilled automatically
• You select another template
• VDI names don't change automatically (but on my side it looks like they do change)

Could you confirm that?
This is my other account.
Acctually. The VDI name does change. But it changes to the name of the previous selected template.

This is the steps I do, and it is reproducible

• I choose to create new vm
• I choose the first template. (Almalinux
• VDI is named: disk_0_rggi
• Without leaving the page. Choosing another template instead. (CentOS 7)
• The VDI is now named: AlmaLinux 8_0_3cgh
• This behaviour repeats each time a new template is chosen.

Creating a new VM. The "Created by" field is trashed. (bad joke). But the UI-bugg is there.

@wezke said in Ansible Role - Install XO from source - Now available:

@probain

Thank you for sharing your ansible role, ill have a look at it

It's far, far from perfect. So there might be a few rough edges that I solved manually. But I welcome feedback.

For completeness sake. Confirming that the fix also works in my second lab as well.

@florent said in Snapshots are no longer being pruned? Commit 58f02:

@probain thanks for signaling this, we just merged a fix, that fix it on our labs
can you test it on your side ?
https://github.com/vatesfr/xen-orchestra/pull/9202

I can confirm that it solves the issue in my primary lab. Tomorrow I will be able to re-validate at my second lab as well.
Thank you for such a quick fix!

I can now reliably recreate the behavior between the commits mentioned above.
As I expected, the problems with finding a "known good" was due to user error

@AlexD2006

Thanks for your input.

So I believe I've managed to find which commit breaks my snapshot-pruning.

If I use the commit: 8a390057b648205b7ae2c6ccc2a0bc78dc624e08 - Then the pruning works.

However, if I go to the next one: 05c6f87a1212e81c51e63f6a585b9e97a3c1bfb2- Pruning breaks and snapshots are no longer being deleted as retention says they should.

I can consistently and reliably re-create the different scenarios in my first lab. This doesn't explain why I'm seing inconsistent results in my other lab. But that might be user error, that I have to double check tomorrow!

Perhaps you could try to see if you see the same behaviour between the commits?

It might be that my known good, isn't that good at all.

I can replicate the problem in my second lab as well. But it is being affected even with commits older than a101e.
I'm still trying to find and provide better/useful information.

Trying to pin down a "known good" at the moment.

Update:
~~Found one: a101e

I'll try to step through the commits, to find where it breaks.~~

Update 2: a101e might not be a "known good".

Running XO from source - Commit 58f02 on a fully update XCP-NG 8.3
Since Friday (error might have come silently from earlier), snapshots are no longer being pruned. After week-end, when I got a possibility to look at what was/is happening. I had 109 snapshots for each VM. The retention is 4.

• I've tried to delete the old schedule and re-create it.
• I've tried to delete the backup-job, and re-create it.
• I've tried adjusting the retetion

None of the above have had any discernable affect.

Is there something else I can do or provide, to maybe hammer out this? Since I belive it to be a bug. I would very much want to do my part in finding the solution.

Thanks!

I've mentioned it on the forums once or twice. And after @wezke explicitly asked for it. I decided to take the time to finally go ahead and publish an Ansible-role for installing XO from source.

Benefits from using any of the many installation-scripts:

Scripts are often quite big. Making them hard to validate and scrutinize for security reasons.

Ansible (imho) is easier to read and see what it does.

If you are orchestrating your environment through Ansible already, this should drop in semi-nicely

This follows the official steps from the Xen-Orchestra docs, except for ONE main thing. This does not run the xo-server as root. In the hopes that it should raise security just a tiny bit more.

Note and Disclaimer!
Do your own validation of the source. Do NOT take my word for how this works. And use it at your own risk.
Now, with all disclaimers out of the way. Feel free to use as you'd like. I hope the community takes kindly to this.

https://github.com/cloudrootab/ansible_role_xoce

PS: This is ported from my private role. But should work. See the disclaimer above!
PPS: This is a re-post from a now deleted forum-post, where I mistakenly placed the topic in XCP-NG/Installation.

@wezke
I'll try to get some time later on and make a cloned & public version release of my role. No promises about timeframe, as I am absolutely swamped right now.

@MajorP93

Well yes and no.

A script is harder to verify for maliciousness. I'm not saying that this script is bad. Rather that I have a paranoid standard practice that I start from.

Ansible has several benefits as well. That I value above using specialized scripts.

The beauty is that everyone can use and do whatever solution they like the best.

@pierrebrunet
For Google Workspace:
Yes it is in the "Service Provider details"-section: See screenshot for example

Edit: Removed doubled screenshot

@pierrebrunet
I'm jumping in here as well. Reporting that the PR fixes it for Google Workspace as well!
However, the checkbox in GW is called "Signed response".
No further adjustments of the plugin itself was needed.

@marcoi
I do this constantly by using either ctrl+mouse click, or middle mouse click.