@olivierlambert Same behavior. Should I open a case with support?
I have noticed if I do a manual health check outside of the backup job, it behaves as I'd expect....restores VM>>power-on>>management tools seen>>power-off>>destroy.
@olivierlambert Same behavior. Should I open a case with support?
I have noticed if I do a manual health check outside of the backup job, it behaves as I'd expect....restores VM>>power-on>>management tools seen>>power-off>>destroy.
@olivierlambert -- stable channel
Current version: 5.92.1 - XOA build: 20240311
@olivierlambert And a Windows machine...this one is admittedly installed with the agent I pulled from Citrix (https://www.xenserver.com/downloads). Same backup job/schedule though.
@olivierlambert From what I can see, the management agent appears to be operational. I'm up for other ideas to check, if you have some?
Apologies if this has been addressed somewhere else, a quick search didn't yield any keyword responses.
I've created a delta backup job that's been running fine for some time. When I tick the "health check" in the schedule (and select the destination SR), the health check portion of the job ultimately fails. It performs the backup like it should, performs the restore and boots the VM to the point that the management agent is recognized, but then just pauses. After ~10 minutes it will power down the VMs and report a job failure. I know there is supposedly a way to execute a script (https://xen-orchestra.com/docs/backups.html#backup-health-check), but 1) I'm happy enough with just the boot check & 2) I'm not seeing a method of tagging, or in this case untagging, the restored VMs to remove the script method. The restored VM objects are given a "restored from backup" and a "xo:no-bak=Health Check" tag.
I see there is a way to restore based on tag, so I can see adding a "xo-backup-healthcheck-xenstore" to an existing VM to force the script method restore, but in this case I don't want the script method.
What am I missing?
@olivierlambert Did anything ever come of this?
@lukasz-engel said in Feature request - VM folders:
My 2 cents as current vSphere user (searching for replacement after new VMware prices knocked my socks off):
Tags in XO are currently only "view filtering feature", nothing more.
There is no method in XO to (without selecting each vm separately):
- attach ACL to group of vms
- select group of vms for backup job
Tags are also error-prone, as I have to manually enter tag name each time (for each vm) and possibly make a typo (there are not even "hints" from current tag names).
I would like to add vm to "group" and this should cause deriving ACLs from "group" and adding to backup job assigned to "group", etc; whatever this "group" would be - folder/tag.
As I have ~500 vms, grouping is "must have" for me.
I'll live if "groups" are tags not folders.
But not having this at all in XO is BIG disadvantage for me.
(without this I quite like what I found in xcp-ng/xo).For me - something like folder seems more natural for such things than tags, but I am biased (as vSphere has folders...).
And generally - in current situation (new prices for vSphere) I suspect there may be more users like me, searching for vSphere replacement, and making XO more friendly for them would be advantage for them...
I do think a lot of this 'group' idea could be made possible using the self service resourceSets, especially if we were able to maybe set "Operator" ACLs on said resourceSet. Maybe even allow tags to be applied to a resourceSet so things like backups would be applied to entire resourceSets vs. an individual VM?
@DustinB So what features about the pool are you wanting to use that you can't just give them access to the individual host (i.e. as a single host pool)?
@DustinB
Does the Self Service resource sets not cover your needs? I understand wanting to limit resources so they don't impact others, but pinning down to a specific host that may be a part of a larger pool can make ACLs ugly. Especially when you enable HA or Plans/DRS. If you aren't planning to enable those features, why not leave the host as an independent pool and give them access that way?
@olivierlambert
I know this thread has kinda gone stagnant, but is an upcoming XO/UI change planning to incorporate ACLs with tags? This feature would be greatly appreciated, as carving out ACLs for individual VMs becomes very tedious.
I can currently assign VMs to self-service resources, but the default permission when doing so is "admin" and I have users where I'd like to assign a lower level roll in bulk. I know I can go back and modify that ACL, but again...tedious, especially at scale. For the self-service resources maybe adding an "Admins", "Operators", & "Viewers" component in place of the current "Users" would be easier?
Maybe there is something else I'm missing?