So double check cloudinit logs, so you'll know at boot what happened and why it didn't take your configuration into account

Are you trying to power on the master? If yes, it won't work, only the master can boot slaves.

@x-rayd said in Logs Partition Full: and where are updates from xcp-ng? I was not really expecting this question this I gave you the absolute reference regarding updates in XCP-ng in a message earlier: https://xcp-ng.org/docs/updates.html

Hard to tell. If it happens again, try immediately to compare XO behavior with other clients to see if we can tell where is the problem

Hi, Thanks for picture update, I will fix it

The information is visible in the build number you have in your XO section. The build number will be visible in the latest appliance once deployed. Because it's not mandatory to use the last one, we don't track it. As I said, it's not a problem to update it until we ask people to change it

Because I want to push users through a web portal interface which can obtain information from XO-Server for presentation back (ie: VM status, parameters, etc) whilst also allowing users to start/restart/shutdown VMs. We looked at XOA however it was too expensive and the free version has nag text messages which I don't want presented to users.

FWIW, this issue was likely due to using an outdated version of Node. The script is being updated to detect this scenario.

So yes, it was the service not started properly, so we didn't get the info into XOA You are welcome, enjoy it!

@Biggen Yeah... definitely easier to backup / restore the config file.

I am back to the office and I am troubleshooting different settings and connection setups. I appreciate all your input. The issue is configuring the right NIC0/NIC1/WAN/ and LAN. Once I am done I post my setting. Thanks again for everyone.

Short answer is that the module is referring to wrong symbol table. Its a lookup table for function interaction between module and kernel. Easy answer is to use this .config file and build full kernel.

Yep.. that did it... started it on the older host, and can now migrate it backwards and forwards with on issues... Thanks Olive... as always. Peter.

I'm not familiar with Terraform, but I can tell you that you can get more info about an unknown error from the peer error in XO on the Settings > Logs page.

Good, keep us posted.

Wow, didn't know it was possible to violate those rules!

@r1 @olivierlambert Hello! There is nothing in any logs at all, on either the Dom_0 or Dom_U at the time of the crash, the journal on the Dom_U stops updating at the instant of the freeze and only resumes after it has been destroyed and re-started. We are in the process of moving sites to HVM, that is an ongoing part of our plan, 1 down... We've not tried running a screen session, but that is a very good idea, and we'll do that - thanks! I don't believe we've tried running in debug mode either, so will pursue that too. Thanks for the advice, I appreciate it - I know it isn't anything even remotely related to your work, but as an XCP-ng user personally, I wasn't sure where else to try. Thanks, Mark

Thanks for the tip. Requested.

I don't have an immediate solution but the goal for the future is that the timeout cancellation will be clearly visible in logs.

Check dmesg in the VM