Host-based backup of VMs running on Red Hat Virtualization, Oracle Linux Virtualization Manager, Scale Computing Hypercore, XCP-ng, HPE VM Essentials.
Post Reply
sdolcourt
Influencer
Posts: 19
Liked: 30 times
Joined: Oct 22, 2025 7:17 pm
Full Name: Seth Dolcourt
Contact:

Feature Reqeusts - HPE Essentials worker

Post by sdolcourt »

I have an existing case 08028917

Root issue is on the daily, the worker fails to synchronize update options, causing a perpetual update settings sync item in the Failed folder on the Home panel.

1. User defined password for the worker, at the time of worker deployment. The worker is deployed with a password that only VBR and the worker care about. However, we as admins don't know what that password is, or how to (operative phrase) easily take control of it. Case engineer did provide a round-about procedure to change the password. Not exactly an exact process, not the support engineer's fault.

Password creation or password modification must be native to the worker deployment / post deploy management, because worker is a node on the network, and we gotta have access control over it. I don't know yet what manner of fresh hell auditors have for us if we are backing up SOX / CUI / SPA servers with the worker, but admin access to the worker can be audited.

2. Worker powers off after backup, but does not have a native option to keep it powered on. Case engineer provided a procedure to change a .json parameter. This need to be a radio button option at the time of worker deploymnet, e.g keep powered on after backups complete. Also selectable in Properties post-install. Our Esseentials is on prem, and is not subject to any internal chargeback for utilization, so I see no pressure to power it off.

3. Unable to natively schedule of worker power on X minutes prior to scheduled backup. If I choose to keep the worker powered off, I would like it to power on, say, 10 minutes prior to backups. Veeam should do this natively, I should not have to write a script for HPE to power on the VM.

Further, I don't know how the worker "knows" how many jobs it is scheduled to do. To have the worker power on, power off, power on, power off as driven by the job schedules feels like a whole bunch of power actions that just don't have to happen.

4. Properties of the worker is grayed out, when worker is powered on. The only option available is Disable Worker. Why? Properites should always be active, regardless of worker power state. Seems like a bug, or an incorrect decision on the part of developers.
Post Reply

Who is online

Users browsing this forum: No registered users and 5 guests