How to increase XOA-memory with XOA

KPS

Hi!

Lately, I had to increase the memory of the XOA-VM.
I tried this through XOA "itself" and failed...

After changing the memory-value for the VM, I thought, it would reboot, but it was shut down and I had to start it manually.

Is this "expected" behaviour? Shouldn't there be a "change after next boot"?

Best wishes
KPS

olivierlambert

In theory, we could tell XO to say "shutdown the VM, change the static memory, and start it". But if you are doing on XO itself, it will obviously stop at "shutdown the VM" since the rest cannot be executed.

It's a chicken-egg problem My advice: just do a quick:

xe vm-memory-limits-set vm=XOA static-min=2GiB dynamic-min=4GiB dynamic-max=8GiB static-max=8GiB

jebrown

@olivierlambert

do you need to edit anything else after increasing the memory for the XOA VM?
on the help guides it says ```
In that case, you need to increase the memory allocated to the XOA VM (from 2GB to 4GB or 8GB). Note that simply increasing the RAM for the VM is not enough. You must also edit the service file (/etc/systemd/system/xo-server.service) to increase the memory allocated to the xo-server process itself.

[link text](https://xen-orchestra.com/docs/troubleshooting.html#configuration)

olivierlambert

It's 2 different things. It's not because you add RAM that you might need to raise the Node memory either. First, add memory and see if it's enough

blackliner

could XCP-ng support the use case by accepting new resource quotas, and apply them on the next reboot?

olivierlambert

I'm not sure to get your question @blackliner

Can you rephrase or detail it?

blackliner

Instead of forcing a reboot when changing the CPU or memory resources, the new settings could be "saved" and applied at the next possible time, e.g. when there is a reboot.

olivierlambert

Okay so:

You are not forced to reboot to add or remove vCPU, depending on the vCPU max value
However, I understand what you mean and the potential use case. However a VM reboot is different than a halt+boot, and a VM.reboot isn't enough to change it. Maybe we could have a modal telling "can't apply now, would you like to do the change by shutdown/start the VM?". But the issue if we store it, and the "surprise" you can have if you set it and forgot then

blackliner

@olivierlambert said in How to increase XOA-memory with XOA:

"can't apply now, would you like to do the change by shutdown/start the VM?"

this 100%! Because then the approach looks like this:

UI - changing the resources
UI - trigger a shutdown
UI - go to the xo-lite and launch the VM

instead of

UI - change the resources, get prompted for a halt+boot, press ok, resulting in the chicken and egg problem plus an error message shortly before the UI goes dark
UI - go to the xo-lite and figure out what is going on, realize you can't change resources in xo-lite
CLI - ssh to the master
CLI - run the command to upgrade resources
CLI - start the VM (I hope you copied the UUID, because this command does not take vm names)