@mpiton
Thanks for looking into this, I guess it wasn't apparent that I needed to click the Save Configuration button for that plugin. I did that and confirmed that the secret now survives an xo-server restart. Thanks again!
New release !
Cloud Controller Manager v1.2.0
https://github.com/vatesfr/xenorchestra-cloud-controller-manager/releases/tag/v1.2.0
Adds a new cloud-node-out-of-service controller that applies the node.kubernetes.io/out-of-service=nodeshutdown:NoExecute taint to the nodes whose Xen Orchestra VM is halted or has been deleted. More about this feature in the documentation or #90
I can already confirm that I could trigger 2 Jobs manually in XO and it run successfully.
Thanks!
The scheduled ones I will see tomorrow and report if it would fail, but it is not expected.
It could, I don't know what XCP-ng Center can do in details. But again, this is NOT a problem.
I said it 3 times, why do you think it's still related to your coalesce problems?
It's the default parameter of your template. XCP-ng Center is probably forcing fixed memory, XO is just doing template recommendation.
You can change values at creation in "Advanced" section.
@Danp As soon as I read that, I thought "I think I've been down this road before." Sure enough. I gave it 2G of RAM and it wouldn't build. I gave it 4G of RAM and I watched using systat and that final step went to about 52% of RAM usage. It has completed. I routinely run Xen Orchestra on a 1G VM because it's rarely used and it runs fine that way. But building it clearly takes a lot more RAM. I'll update my internal notes. It might be worth it to update the building from source docs to mention having enough RAM.
Thanks for hitting the nail on the head with that advice!
XOA got its own numbering, unrelated to xo-server or xo-web: it'a all a matter of a coherent "whole", including dependencies etc. Thing we can't provide when built on sources.
Please test and report You can switch to latest too, doesn't matter.
@luiscamaral Let me reply to myself. If you update xoa it will show user and password as in bellow description:
Template for Alpine Linux 3.10, with 'root' username and 'xohub' password, DHCP enabled
@karlisi said in Interrupted CR task - what now?:
Automatically deleting incomplete VMs can be dangerous
This is an example - don't take it too strictly. I'm talking about exaclty the above problem. I was not aware of it. No information about the problem and this is the exactly the real problem.
@olivierlambert said in Stuck at copying Continuous Replicated VM:
In order to CR to continue after "booting it", you must use a copy.
In case of you lost your origin VM, then it doesn't matter if you boot the replicated VM directly.
I don't know why full clone doesn't work on this SR.
I give up for now
I have no idea why it did not work. No error messages on the logs also. It just stuck. anyways thank you @olivierlambert for your time.
I created a new VM and attach the copied VDI 1 to it. The second VDI cannot be attached so I delete it and will copy from the source server. Looks like it is working.
I have one more VM to process and this time I will double check the steps and share any progress here.
@S-Pam said
Isn't any SQL server crash safe? I.e. they should handle a system power-loss and gracefully recover (journals). A filesystem snapshot is equivalent of a power loss. You need to configure your databases accordingly.
Most of maria/mysql have enabled innodb doublewrite enabled by default:
https://dev.mysql.com/doc/refman/5.7/en/innodb-doublewrite-buffer.html
But just in case of Active Directory... I really really want to have consistent snapshot/backups
