How to increase XOA-memory with XOA

jebrown

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)

Tristis Oris

simple way - clone XO vm or use Xen client.

blackliner

@Tristis-Oris

clone XO

Is running multiple identical XO a supported use case?

Tristis Oris

@blackliner you need for a 1 minute task.
also you can run multiple xo along.

tjkreidl

@olivierlambert I guess migrating the VM to a different host would not kick in the changes, either, since the VM is technically not shut down in the process?

olivierlambert

Yeah, this raises a lot of question. If you do the change and forgot about it, many things could happen before a shutdown/start.

blackliner

@olivierlambert But it does not sound like a proble. As long as the UI is doing a good job in making the pending change visible, what's the harm? Others do it in a similar fashion

olivierlambert

Not a problem, something to be done correctly, and not implemented at all in the current XCP-ng API. In other words, it's not trivial You can create an issue in XO repo with all the details (and the screenshot), this at least needs some serious work to find what would be the best approach (and then sorted from our backlog)