@andriy.sultanov said in "Block migraton" option on the VM´s Advanced tab: @panzersrmm @panzersrmm said in "Block migraton" option on the VM´s Advanced tab: Hi! Is there a VM parameter that saves this "Block migration" UI button? I wasn't able to identify which one it is with command: xe vm-param-list uuid=<VMuuid> Thank you! How do you mean? Is the XO option not persistent? XO sets these parameters: # xe vm-list uuid=$UUID params=blocked-operations blocked-operations (MRW) : pool_migrate: true; migrate_send: true Which you can set like this yourself: # xe vm-param-set uuid=$UUID blocked-operations:migrate_send=true # xe vm-param-set uuid=$UUID blocked-operations:pool_migrate=true @andriy.sultanov Thank you for your answer! That's what I was looking for. I was looking directly at the VM parameters, with xe vm-param-list uuid=$UUID and I was directly searching for "blocked_migration". Now I know what to look for. @olivierlambert Thank you for pinging the appropriate team for the answer.

Hi, To start, it's good to read: https://docs.vates.tech/security/ Especially https://docs.vates.tech/security/#contact--disclosure Then, I can answer here directly: we are not affected since Redis is only listening locally, therefore it's not exposed outside XO. There's nothing interesting to do with that CVE, because in order to use it, you already must be a privileged user.

@Forza Good point. I need to apply the latest patches anyway, so I'll be rebooting the pool later today anyway.

@ThisGuy_420 Great! We'll try to get those tools available more broadly and finally get a 1.0 officially, this is taking too much time while they are perfectly working. Pinging @Team-OS-Platform-Release

This is now solved. I rebuilt the XO VM and can create multiple VMs as expected.

@olivierlambert said in Xen Orchestra commit a62ac Templates not loading data: The fix was merged in master, you should have it now if you update to the latest commit Very cool. Works perfectly fine again. Love this Keep up the excellent work you guys Regards, Marc

@olivierlambert yes Olivier. but I'm in doubt of the correct redirection I have to make in NPM ... Should I port the token part of the url also in the redirected internal part ? or do I miss an nginx parameter to help pass this token 'inside' ?

@flakpyro All this complexity makes me question the advantages of having all hosts in the same pool.

Ping @pdonias

@okynnor IIRC, it would take a reboot before the problem showed up. I'd check after a reboot if XenSvc wasn't stuck in the starting state.

Then reboot than broken host and in the meantime, re-issue the power reset command from the master.

I had a similar issue, and what helped me was routing update traffic through Static Residential Proxies to avoid deep packet inspection that was blocking some repositories. They worked better than regular proxies in our setup since they look like normal home users, so the network didn’t treat the traffic as suspicious. You might need to whitelist some domains manually though, depending on how strict your proxy rules are.

That's very clear, thank you for your prompt response!

It might record the max static RAM (IDK)

@DustinB Thank you. I understand, it's absolutely a cosmetic request.

@olivierlambert did not check that unfortunately, since it it is already setup now, will be hard to reproduce it

@Cygace Someone from the community may jump in and help troubleshoot this. The best approach would be to not modify the Dom0 installation by installing Zabbix via a community post, as you're customizing the installation. The vates team and XCP-ng specifically need to include these packages to ensure you're able to get support. Best of luck

@cgasser are the backup job running normally (if any ) ? can you disable temporary the backup network ? the rrd stats should be visible immediately afte if this is the root cause

Yes! That's a good guide for what you want to achieve