@acebmxer Thanks for the report, we'll check that! Regarding themes, it will remain non-persistent until we implement the full theme system.

@jacob.becker Thanks for the detailed feedback, we'll see how we can improve that

@acebmxer Themes are in preview for now. Don't worry, persistency and other features will come after user management arrives in XO 6

@fluxtor Do you mean that you edit the backup job through the API before running it?

@aesparragon We're looking into that, thanks!

@jacob.becker We're adding the maintenance icon very soon, thanks for the feedback. Regarding VM vs host in the treeview, do you mean that the icon isn't clear enough? Do you have the same issue with pools?

@capeschools Indeed, updates are still done in XO 5 for now, we're trying to implement critical features first, but don't hesitate to upvote it on our dedicated platform if it's a priority for you: https://feedback.vates.tech/posts/11/add-xo-updater-tab

@ufm Thanks for the report. With the current implementation, it seems to be normal. Could you show me where it says that in the documentation and we'll discuss with the team whether it should be changed or not. Thanks!

@DaleDibbadel Are you running XOA or XO from the sources? Are you up-to-date?

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

I'm not sure if it's a good idea to show a Backup issue every time a Cont.rep. job is run

Thanks for the feedback, we'll fix that!

@XCP-ng-JustGreat said in ️ XO 6: dedicated thread for all your feedback!:

However, the periodic console refresh interrupts the performing of actual work

We'll investigate that issue, thanks for the report.

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

In ContRep, Conf/meta and in one of the Full Backup jobs I get Report when Never. But they are enabled in XO5 with mail address and Report when Skipped and failure

This definitely looks like a bug, we'll check that, thanks again!

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

It seems now these VM Notes are stuffed into a small "Description" field inside the "Quick Info" panel for a VM.

Notes and descriptions are 2 separate things. We haven't added notes in XO 6 yet, but don't worry, we will! And XO 5 and XO 6 will be available side by side until XO 6 is fully usable, so you're not going to lose your notes, no need to back them up

Thanks for all the feedback!

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

I found another link that isn't completely fixed
https://xcp-ng.org/forum/topic/10613/suspicius-presentation-of-time-in-backup/

Are you in UTC+1? This one might simply be because the VM's name shows the UTC time while, in the tables, we convert dates to your actual timezone.

@acebmxer, @ph7 said in ️ XO 6: dedicated thread for all your feedback!:

In thin provisioning It would be nice to have info about a VMs actual use of disk space

We're actually in the middle of improving how sizes are measured in general: SRs (thin/thick), VDIs, snapshots, chains of VDIs, transfered vs used vs allocated size, etc.

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

XOA v5 links not working...

We're still fixing a few things regarding this. It will most likely be fixed very soon

@Alexander-0 said in ️ XO 6: dedicated thread for all your feedback!:

With XO from source if I put config.mounts.toml into /etc/xo-server/ I have to provide absolute paths instead of relative ones

Both should work. Do you start xo-server in any specific way?

@bazzacad Those are orphan VDI snapshots.

@ph7 Thanks for all the feedback! We took notes of everything, and we're already fixing some of them

@jr-m4, @probain and @acebmxer We were eventually able to reproduce the VDI name bug, we'll fix that!

@Davidj-0 said in ️ XO 6: dedicated thread for all your feedback!:

Should we add this to https://docs.xen-orchestra.com/installation#installing-dependencies ? Or will it not be necessary after the next release?

It won't be necessary after we merge this PR, which should be very soon.

@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?

@marcoi Thanks @acebmxer for answering, we'll make a change very soon so that you no longer have to do that.

@pilow Our precise backlog is private but here's the short-term roadmap:

• Actions, starting with VMs lifecycle. XO 6 is mostly read-only for now but this will change soon.
• User management and allowing non-admin users to use XO 6 + ACLs.
• XOA license management.

@ph7 If we answered your other messages, most likely we have it in our backlog. But just to make sure we're not missing anything, you can indeed put the links here and we'll check them. Thanks again!

End of November:

• XOA admin users on the latest channel will see a new option in the left-hand menu to access XO 6. XO 5 will remain the default interface, but you can begin testing XO 6 whenever you like.

• Users running XO from source will transition to XO 6 by default, with a link in the interface to return to XO 5 when needed.

End of December:

• XOA's latest channel will also move to XO 6 as the default interface. XO 5 will also remain accessible whenever you need it.

• Stable channel will remain on XO 5 by default.

@archw It's the amount of seconds after which the job run will be marked as failed if the run hasn't ended. If you configure a timeout on vm.restart with multiple VMs, the timeout will apply on each VM individually.

@archw Since the jobs settings give you an automatic direct access to the API methods, the parameters are not documented, unfortunately. Regarding vm.restart, force will hard-reboot the VM instead of going through the guest tools and bypassBlockedOperation will restart the VM even if you enabled "Protect against accidental shutdown" in the VM's advanced tab.

@love2scoot You can add this to your xo-server config file:

[logs]
filter = 'xo-server-auth-ldap'

Then xo-server's logs will only contain logs coming from the LDAP plugin, including more debug logs during a group sync. Don't forget to remove it once you're done to get your logs back to normal.

Hi! Regarding the templates issue, we're working on a fix on branch pierre-fix-xsa468-test master. Would anyone having the issue be available to test it?

This is essentially why I said in the other thread that "Self Service and ACLs weren't designed to work together"

To keep it simple: Self Service will indeed allow some users to see and use some resources even though they don't have ACLs for them. Then, when they create VMs, it will automatically assign ACLs on the objects under the hood. That's why, even though it's not impossible, most of the time it's not recommended to use them together since you might override ACLs that Self Service assigns automatically.

We're actually starting to think of a redesign (or at least improvements) of those 2 features so feedback is very welcome about any use case that you might have that isn't covered by them at the moment. I already took note of the "dynamic" need for resource set objects.

Hi @olympicgreg, this seems to be the intended behaviour.

Self Service and ACLs weren't designed to work together, so when you create a VM, you either do it under the Self Service feature or thanks to the ACLs you have. So in your case, the user might have Viewer ACLs on the pool, but since they create the VM using Self Service, they will only be able to see the resources available in the Self Service resource set.

Regarding ACLs, "Viewer" is not enough to be able to create a VM on the pool. But if you change it to "Admin", you'll see that the user is now able to create a VM outside of the Self Service feature, simply by selecting the pool. And in that case, they'll be able to see all the pool's networks.

@kagbasi-ngc It's not possible at the moment. How would you expect it to work? Would it try to request the first server and fallback to the second one in case of error? And do that for every single request?

@andrewperry Exactly

Hi @andrewperry, a "server" in XO 5 represents a "connection to a pool". Since you need to enter your physical server's information, that's why we called it that way. But we agree too much vocabulary can be confusing so in XO 6 we'll change that and probably call it something like "Pool connections".

@ph7 Thanks for the report, we'll check that