Kuberenets cluster recipe not happy

mathiashedberg

So after some more testing it seems the template mapping is wrong again. My k8s VMs started with 500MB, and when i looked at the bash history, i saw that yet again, the k8s VMs were based on an existing VM running on the system. The ram was set to 500MB because thats what the base VM ram settings were. This is the same issue as earlier on.

olivierlambert

Are you sure you removed the templates?

mathiashedberg

So this new VM for k8s seems to be based on an existing VM, which itself is based on the Debian 10 template (when it was created a long time ago)

mathiashedberg

@olivierlambert Ill remove them using the windows client

olivierlambert

Our recipe is based on Debian available in XO Hub template.

olivierlambert

In XO, you can search it in Templates view and remove it

mathiashedberg

@olivierlambert Yes i removed it from the Hub > Templates view. It should be noted that i take regular backups of the VMs created with this debian 10 template, so i think it is using them

Backups are done with the XCP-NG center: 'Pool' > 'VM Snapshot Schedule' setting

olivierlambert

Please do NOT use XCP-ng Center "snapshot schedule" feature please

mathiashedberg

@olivierlambert For a homelab setup this is currently the only "free" solution to snapshotting that i know of (other than file system based like ZFS).

Going from "free" to 77USD a month is quite a jump imo.

olivierlambert

It's a bit off topic but:

Remember, snapshot is not backup
You can use XO from the sources to have all XO source code without feature restrictions (but XO hub/recipe is XOA because it's a service connected on xen-orchestra.com where we host the machines).

Anyway, let's try to find the original problem

DustinB

@mathiashedberg said in Kuberenets cluster recipe not happy:

@olivierlambert For a homelab setup this is currently the only "free" solution to snapshotting that i know of (other than file system based like ZFS).

Going from "free" to 77USD a month is quite a jump imo.

Xen Orchestra is free and open source. You can follow the build from source instructions or use a script like the one posted to my github

mathiashedberg

@olivierlambert
The snapshot functionality is still quite tempting to use, as I have not had any issues with it before now. I'll admit I'm not too up to date on what features are recommended or not when it comes to XCP-NG.

@DustinB I think its great that we have such useful software that is free and open source. If my comment came off as negative I apologize, that was not my intention.

Moving forward I would assume that removing all my snapshots would remedy the issue. However I'm not too sure on how keen I am on doing that right at this moment with my current setup, maybe on a different test lab.

BenjiReis

@mathiashedberg the snaphots might be indeed the problem.

When looking for the template, the recipe looks for a VM with xo:resource:xva:id=<template uuid> in its other-config, a snapshot of the template VM would probably have this field se and it should not.

Can you check if it's the case? and if the is-template field is true.

olivierlambert

That's an interesting thing. I think it might be a potential bug because of XenCenter snapshot algorithm that handle is-template differently than XO.

BenjiReis

@olivierlambert should I also check that is-a-snapshot is false?

olivierlambert

Double check what do you have when we install a template from XO Hub. If is-a-snapshot is at false, then yes, add this condition. We should use the installed template, not anything else.

BenjiReis

Okay so a fix is coming soon, i'll update here once released.

mathiashedberg

@benjireis
So you are correct on all those points. Here are the relevant params from the snapshot that was being used:

is-a-template ( RW): true
is-a-snapshot ( RO): true
other-config (MRW): auto_poweron: false; xo:resource:xva:id: a677aa91-f5d5-46ec-bd53-956b73fc7871; xo:resource:namespace: Debian10; xo:resource:xva:version: 1.0.0; import_task: OpaqueRef:71bd99c2-11c3-4306-a5b9-7fe6e86f551b; mac_seed: 02166646-6e3b-de07-1b11-872d538d3f01; base_template_name: Debian Stretch 9.0; install-methods: cdrom,nfs,http,ftp; linux_template: true

BenjiReis

@mathiashedberg good to know.

So you can wait for the fix or remove the xo:resource:xva:id from the other_configs of the snapshots or remove the snapshots

mathiashedberg

@benjireis Looks like version 5.56.0 runs as expected! No issues so far!