@sborrill Is the user a member of the resource set that you created? Does the VM belong to that same resource set? (You can check that at the very bottom of the Advanced tab of the VM) Could you post the full error log that you get when the Self Service user tries to snapshot the VM?
@olivierlambert @sborrill By default, Self Service users can snapshot their VMs and it will consume the same amount of resources as the VM again. If you don't want that, you can ignore snapshots in the quota computation by adding this to xo-server's config:
[selfService]
ignoreVmSnapshotResources = true
Hi @RaHu! No, at the moment, we don't synchronize hosts' information. I'm not even sure where that information could go as there isn't such a thing as a host object in Netbox, AFAIK.
@olivierlambert No, because {name} will be replaced by the main name input (at the top of the form), not the individual names in case of bulk creation. So you should get "test1", "test2", as expected.
Hi @bnerickson, indeed, the configurations are correctly imported but plugins aren't automatically "configured" when you import a config. We'll improve that, thanks for the report 
@theaeon No, that's a normal case and it's handled properly. The issue would be if one of the IPs has 2 IPs in the same field separated by a white space like: "x.x.x.x y.y.y.y", or if the field is just empty or anything else that doesn't look like a proper IP address.
If you want to check the addresses more thoroughly, you can install xo-cli with npm i -g xo-cli, log into your XO with xo-cli --register <XO-Server URL> <username> <password> and then run xo-cli --list-objects --addresses type=VM \$pool=<pool ID>.
Hi @kajetan321, please add this to your xo-server config file:
[logs]
level = 'debug'
then test the plugin again and check xo-server's output when the error occurs to help identify what's causing the issue.
Thanks @theaeon. Could you check if some of your VMs on that pool have invalid IP addresses? You can do that from the home page by filtering only the VMs on that pool (Pools selector at the top of the page) and expanding the details for all the VMs to show the IP addresses (hamburger button at the top right hand corner). Each IP address must be in its own blue rectangle and with the correct format for either IPv4 or IPv6. Let me know if this is too hard to check, we'll find another way.
Hi @theaeon, this should already be fixed, could you check the full log for that error in Settings > Logs? It should give you more details.
Hi @luca-steinke, this is indeed something that we should and will document. Here are the minimum required permissions:
View permissions on:
All permissions on:
Hi @NielsH, thanks for the feedback, we'll discuss it but this may indeed have to wait for XO 6.
@jedimarcus We fixed it on master. If you pull the branch and rebuild, the test should pass now.
@jedimarcus It's not that old but they indeed changed the limit from 50 to 100 characters in version 2.10. We'll fix the plugin so that the test also passes on old versions, and since you were able to synchronize your pool, you can ignore the test failure. And thanks for the report
Thanks @cookie-eater2000, we'll take a look.
Hi @frabatbecker, there was a small issue with job.runSequence, we fixed it in master. We also added a button to allow you to copy job IDs from the UI. Thanks for the report and let us know if you have other issues!
@notscottsmith So apparently, the old protocol also adds x/ipv4/x fields with space-delimited IPs. That's what causing the issue, so we'll have to handle them too. Thanks!
@notscottsmith Ok, could you run this inside XO's directory with the VM's host and its password:
./packages/xen-api/dist/cli.js --au <HOST> root <HOST ROOT PASSWORD>
It should start a CLI. And then run this with the VM's UUID:
> find({ uuid: '<VM UUID>' }).$guest_metrics.networks
@olivierlambert Most likely, yes. But it shouldn't be an issue anymore after this change (XO 5.60) so I don't understand why the error is still happening.
@notscottsmith Do you see those space-delimited IPs in the UI too?