@sborrill And for completeness, try pvshim (a.k.a. pv-in-pvh) using xl:
name = "nbpv"
type="pvh"
pvshim=1
pvshim_cmdline="pv-shim console=xen pv-linear-pt=true"
kernel = "/root/netbsd-INSTALL_XEN3_DOMU.gz"
memory = 1024
So pv-in-pvh does work (does require pv-linear-pt=true on shim command line though).
PVH is supported just fine by the xl toolstack on XCP-ng and XenServer, so it's only the relevant glue missing in xapi to enable domain-type=pvh to work.
To demonstrate:
Download a NetBSD INSTALL kernel from https://ftp.netbsd.org/pub/NetBSD/NetBSD-10.1/amd64/binary/kernel/netbsd-INSTALL.gz to /root.
Create /root/nbpvh containing:
name = "nbpvh"
type="pvh"
kernel = "/root/netbsd-INSTALL.gz"
memory = 1024
@TeddyAstie Any idea how to debug this? I'd hoped that enabling VM console output with the following might help:
xenstore-write /local/logconsole/@ /tmp/console.%d.log
With the xl toolstack and pvshim, you see the shim xen kernel start on the VM serial console before handing over to the PV domU kernel. In XCP-ng, there is no output.
@TeddyAstie Thanks, but that appears to make no difference
# xe vm-param-get uuid=82dfbfc3-d620-2aeb-8ac5-2567d44ea479 param-name=domain-type
pv-in-pvh
# xe vm-param-get uuid=82dfbfc3-d620-2aeb-8ac5-2567d44ea479 param-name=platform param-key=pvinpvh-xen-cmdline
pv-shim console=xen pv-linear-pt=true
@TeddyAstie
Yes, I tried pv-in-pvh before posting and it didn't work. The VM appears to go through the starting process and then stops.
My theory is that this is because PV_LINEAR_PT is compiled out which is required by NetBSD PV. Even prior to this you had to enable it with:
/opt/xensource/libexec/xen-cmdline --set-xen pv-linear-pt=true
With the xl tool stack as used by a NetBSD dom0, pvshim does work with the same kernel.
@gduperrey I thought I had. I was replying to that thread and the forum software prompted me to click to reload. It continued to show the contents of the thread above as I clicked to post my reply, so if it opened a new thread, I count that as a bug in the forum, not user error
Yes, I tried pv-in-pvh before posting and it didn't work. The VM appears to go through the starting process and then stops.
My theory is that this is because PV_LINEAR_PT is compiled out which is required by NetBSD PV. Even prior to this you had to enable it with:
/opt/xensource/libexec/xen-cmdline --set-xen pv-linear-pt=true
With the xl tool stack as used by a NetBSD dom0, pvshim does work with the same kernel.
I have a NetBSD VM which was fully PV, but now has been upgraded to have a kernel which supports PVH. How do I configure the VM to use the PVH device model so I can get it to run now that vanilla PV is no longer supported?
--
Stephen
@olivierlambert I have a method I can use to workaround, yes, but there's a few things that violate POLA. It appears as ACL-only cannot be used to allow snapshotting because of the need to give admin-ish access to the SR. Using resource sets and self-service does work, but having to add users, not just groups they are in, to the resource set isn't great. I was unclear about why ACLs (i.e. visibility of a VM) disappeared when removing snapshots.
@sborrill said in Permissions for users to be able to snapshot:
(related question, can an existing VM be added to a self-service resource group?)
It appears not. The Web GUI makes it look like you can by allowing you to pick a resource set but you get the following error:
"message": "the vm is not in a resource set
Note that despite this error, the VM has now been added to the resource set and can be snapshotted (if the user is explicitly a member of the same resource set - not just in a group that is)
@pdonias said in Permissions for users to be able to snapshot:
@sborrill Is the user a member of the resource set that you created?
The user was not explicitly a member, but was a member of a group that was. When I added the user to the resource set, I could snapshot, so it appears that the problem is that group inheritance does not work.
When I removed the user from the resource group (to double-check), it removed all the ACLs from the VM so that it was no longer visible to that user (or group). This looks like a bug. I had to use the share option against the resource set on the advanced settings to grant visibility again.
Does the VM belong to that same resource set?
Yes
Could you post the full error log that you get when the Self Service user tries to snapshot the VM?
vm.snapshot
{
"id": "2af0ed72-7602-ad3a-142f-6f73e556d8b9"
}
{
"code": 2,
"data": {
"permission": "operate",
"object": {
"id": "d0e48e5f-7012-d7c9-e300-0bd33f55d4d9"
}
},
"message": "not enough permissions",
"name": "XoError",
"stack": "XoError: not enough permissions
at factory (/opt/xen-orchestra/packages/xo-common/src/api-errors.js:21:32)
at Object.assert (/opt/xen-orchestra/packages/xo-acl-resolver/index.js:132:17)
at default.checkPermissions (file:///opt/xen-orchestra/packages/xo-server/src/xo-mixins/acls.mjs:109:17)
at Object.<anonymous> (file:///opt/xen-orchestra/packages/xo-server/src/api/vm.mjs:818:5)
at Api.callApiMethod (file:///opt/xen-orchestra/packages/xo-server/src/xo-mixins/api.mjs:307:20)"
}
@sborrill said in Permissions for users to be able to snapshot:
(related question, can an existing VM be added to a self-service resource group?)
It appears not. The Web GUI makes it look like you can by allowing you to pick a resource set but you get the following error:
vm.set
{
"resourceSet": "7hFH8vTa74k",
"id": "44ebddd1-2a33-8775-033a-677b993b103e"
}
{
"message": "the vm is not in a resource set",
"name": "Error",
"stack": "Error: the vm is not in a resource set
at _class2.shareVmResourceSet (file:///opt/xen-orchestra/packages/xo-server/src/xo-mixins/resource-sets.mjs:425:13)
at _class2.setVmResourceSet (file:///opt/xen-orchestra/packages/xo-server/src/xo-mixins/resource-sets.mjs:417:18)
at runMicrotasks (<anonymous>)
at runNextTicks (node:internal/process/task_queues:61:5)
at processImmediate (node:internal/timers:437:9)
at process.topLevelDomainCallback (node:domain:152:15)
at process.callbackTrampoline (node:internal/async_hooks:128:24)
at Object.<anonymous> (file:///opt/xen-orchestra/packages/xo-server/src/api/vm.mjs:530:5)
at Api.callApiMethod (file:///opt/xen-orchestra/packages/xo-server/src/xo-mixins/api.mjs:307:20)"
}
@pdonias I saw that, which is why I check that there was sufficient space defined in the resource set. I found a VM created using self-service cannot be snapshotted without granting Operator rights on the SR (so same behaviour as just using ACLs). The resource set does have the SR listed against it.
@olivierlambert I checked that there was sufficient space in the resource group for a full copy of the VM (assuming the snapshot would grow to the worst-case).
When the end-user views their list of VMs, it is not clear which are part of a resource set. I see that if you click on the details icon next to the number of items to display, then the resource set is displayed against each VM. This is a link, but I get Page not found when I click on the resource set name.
The reason I've been looking at self-service here is because of @julien-f saying that "I think your usage issues will be fixed by self service improvements." in issue 827 as a workaround for users needing Operator rights on the SR. It does seem that the ability to hide SRs from the UI for users as suggested by the OP in that issue would be a start.
@olivierlambert We have users that need the ability to mange and snapshot their own VMs without being able to affect/view other users' VMs or the infrastructure itself. Self-service has been recently implemented to allow them to create their own VMs as well as manage ones we have previously created for them which are covered by ACLs (related question, can an existing VM be added to a self-service resource group?)
I'm trying to understand what minimal permissions are required for a user to be able to snapshot a VM. I've read some github issues and https://xen-orchestra.com/docs/users.html#acls but the situation seems suboptimal.
User:
To allow snapshots, I had to give the user Operator rights over the VDI SR (which gives them far too many other rights).
Based on https://github.com/vatesfr/xen-orchestra/issues/827, I tried creating a VM using self-service as it suggested that might help, but I could not snapshot that either (until the user had Operator rights on the SR). How is self-service meant to help here?
xo-server 5.86.3, xo-web 5.91.2
The LDAP plugin runs the query specified with {{name}} as the username you enter. It then uses the same value for the user account to create. This is OK for simple queries, but imagine you want to search by email address and/or account name while using a consistent name for the user account. It would be very handy to be able to optionally specify an LDAP attribute to extract and use for the user account (this is very similar to what NetScaler does for the SSO attribute).
For example, I have the following query:
(&(|(sAMAccountName={{name}})(mail={{name}}))(memberOf=CN=CloudConsole,CN=Users,DC=domain,DC=internal))
With this I can log in with either AD account name or email address (as long as I am a member of the specified group). Currently XO treats these as two separate accounts (with obvious associated problems for ACL duplication, etc.). I would like to specify that the XO username should be the sAMAccountName attribute
@julien-f Yep, exactly. Respond with 401 header if username or password are wrong (or not present). Probably allow for the realm to be configured too (not important for NetScaler).
I'd like to have the option for using basic http authentication rather than form-based authentication with Xen Orchestra (while still using LDAP for the actual backend authentication). This would allow easy single-sign-on through NetScaler by publishing it as an intranet resource without requiring Advanced/Enterprise licencing for SAML.