Migration LXC privilegiert zu LXD?

[nyami]

Hallo Leute,

ich habe eine sehr gut funktionierende Nextcloud Instanz in einem Bullseye-LXC-Container laufen.

Da ich nun Blut gerochen habe lese ich überall das es empfohlen wird dem ganzen LXD "über zu stülpen"
um mehr und leichtere Möglichkeiten der Administration zu haben. Auch einen Container auf einem
anderen Rechner zu nutzen und einfach zu übertragen scheint dort sinnvoller machbar.

Wie seht Ihr das? Was muss ich beachten, wenn ich nun per snap LXD installiere?
Der LXC Container muss unbedingt weiter laufen, bis ich verstehe wie es mit LXD geht!

Wie wäre ein sinnvolles Vorgehen? Was ist zu tun /zu lesen? Bitte für Newbies.
Ich bin mit dem Thema noch sehr am Anfang. Wenn ich also Blödsinn erzähle, habt bitte etwas Nachsicht und korrigiert nach Herzenslust.

Danke vorab
LG
Sven

[Blackbox]

Für den Anfang stellt sich mir die Frage, wo du im Debian Repository lxd gefunden haben willst?

[nyami]

Habe ich nicht!
Vielleicht sagst Du mir was der Hintergrund Deiner Frage ist?

[bluestar]

Vielleicht sagst Du mir was der Hintergrund Deiner Frage ist?

Darf ich mal vermuten? Du möchtest ein Snap (Fremdpaket) in Debian nutzen, beschreibst dein Erfahrungslevel „Newbies“ und hegst die Hoffnung, hier die passende Hilfe zu finden?

Wenn du das ausprobieren willst und uns hier deine Erfahrungen/Probleme teilen möchtest, dann freuen sich sicherlich einige hier.

Da ich nun Blut gerochen habe lese ich überall das es empfohlen wird dem ganzen LXD "über zu stülpen"
um mehr und leichtere Möglichkeiten der Administration zu haben.

Da sehe ich zwischen LXC und LXD keine großen Unterschiede, ich nutze Ansible für Container und VMs gleichermaßen. Mich müsste LXD dafür jedoch erst einmal überzeugen & es in Debian hineinschaffen, die Go Abhängigkeiten von LXD sind da wohl schon seit Jahren ein Problemmonster, was man dazu so liest.

Auch einen Container auf einem
anderen Rechner zu nutzen und einfach zu übertragen scheint dort sinnvoller machbar.

Auch das geht mit LXC recht problemlos, es kommt halt darauf an, welches Dateisystem unter dem Container liegt. ZFS bewährt sich hier sehr gut und bei größeren Installationen kann ich Proxmox wirklich empfehlen.

[Blackbox]

Vielleicht sagst Du mir was der Hintergrund Deiner Frage ist?

Das war eine Vorsichtsmaßnahme gegen Trolle, die fallen in letzter Zeit durch vermehrte Aktivität auf.
Die nötigen Informationen hat dir bluestar erteilt.

[novalix]

Hola!

Es ist etwas verwirrend, dass man auf der Suche nach Information und Problemlösungen zu lxc unweigerlich auf lxd stößt. Man gewinnt schnell den Eindruck, lxd sei so eine Art de facto Standard.

Mein Lösungsvorschlag:
Versuche die lxc toolchain möglichst genau zu verstehen und überlege dann, was lxd darüber hinaus anbietet.
Die meisten "goodies" von lxd richten sich an Automatisierungsanforderungen, also an Umgebungen, in denen häufige Bearbeitungen (erstellen, löschen, verschieben, ...) von Containern stattfinden.
Das meiste davon lässt sich vergleichsweise problemlos auch "händisch" erledigen.

Du brauchst z.B. für das Verschieben eines Containers auf einen anderen Host weder lxd noch ein CoW-Dateisystem (zfs, btrfs). Diese Technologien *können* das Verfahren vereinfachen, sind aber im Zweifelsfall für sich so voraussetzungsvoll, dass ihre Vorteile erst bei massiver Nutzung zum tragen kommen.

[nyami]

von novalix » 12.12.2021 14:26:08

Hola!

Es ist etwas verwirrend, dass man auf der Suche nach Information und Problemlösungen zu lxc unweigerlich auf lxd stößt. Man gewinnt schnell den Eindruck, lxd sei so eine Art de facto Standard.

Mein Lösungsvorschlag:
Versuche die lxc toolchain möglichst genau zu verstehen und überlege dann, was lxd darüber hinaus anbietet.
Die meisten "goodies" von lxd richten sich an Automatisierungsanforderungen, also an Umgebungen, in denen häufige Bearbeitungen (erstellen, löschen, verschieben, ...) von Containern stattfinden.
Das meiste davon lässt sich vergleichsweise problemlos auch "händisch" erledigen.

Hi novalix,
ich habe nach dieser Anleitung den Container copiert und übertragen:

https://fragland.dev/clone-an-lxc-conta ... -commands/

Und bekomme beim Startversuch:

Code: Alles auswählen

lxc-start -n bullseye-nextcloud
lxc-start: bullseye-nextcloud: lxccontainer.c: wait_on_daemonized_start: 859 Received container state "ABORTING" instead of "RUNNING"
lxc-start: bullseye-nextcloud: tools/lxc_start.c: main: 308 The container failed to start
lxc-start: bullseye-nextcloud: tools/lxc_start.c: main: 311 To get more details, run the container in foreground mode
lxc-start: bullseye-nextcloud: tools/lxc_start.c: main: 313 Additional information can be obtained by setting the --logfile and --logpriority options

Ich finde nicht wirklich etwas über die Fehlersuche bei lxc-Containern.
Vielleicht kannst Du mir hier eine Input geben?

[bluestar]

Hi novalix,

Ich bin zwar nicht novalix, ebenfalls ein hallo an dich.

Ich finde nicht wirklich etwas über die Fehlersuche bei lxc-Containern.
Vielleicht kannst Du mir hier eine Input geben?

Zuerst einmal solltest du prüfen, ob deine beiden Hostsysteme grundlegend gleich konfiguriert sind.
* gleiches Basis-System (Debian Bullseye)?
* gleiche Benennung der LXC Netzwerkbrücke?
* gleiche Subuid/subgids?

Und natürlich solltest du den Hinweis nutzen und den Container mal mit aktiviertem Logging starten:

Code: Alles auswählen

lxc-start: bullseye-nextcloud: tools/lxc_start.c: main: 311 To get more details, run the container in foreground mode
lxc-start: bullseye-nextcloud: tools/lxc_start.c: main: 313 Additional information can be obtained by setting the --logfile and --logpriority options

Starte deinen Container mal mit

Code: Alles auswählen

lxc-start -n bullseye-nextcloud --logfile /tmp/bullsey-nextcloud.log

Was parallel dazu hilfreich sein kann, poste mal deine Container Konfiguration.

[nyami]

Hi Bluestar,

natürlich, gerne.

Ich habe auf beiden Systemen Bullseye laufen, allerdings einmal auf einem Raspi3 und einmal ein Intel Celeron System.

Code: Alles auswählen

# Template used to create this container: /usr/share/lxc/templates/lxc-debian
# Parameters passed to the template: -r bullseye -a armhf
# For additional config options, please look at lxc.container.conf(5)
# Uncomment the following line to support nesting containers:
#lxc.include = /usr/share/lxc/config/nesting.conf
# (Be aware this has security implications)
#lxc.net.0.type = veth
#lxc.net.0.hwaddr = 00:16:3e:40:9a:38
#lxc.net.0.link = lxcbr0
#lxc.net.0.flags = up
lxc.apparmor.profile = generated
lxc.apparmor.allow_nesting = 1
lxc.net.0.type = macvlan
lxc.net.0.flags = up
lxc.net.0.link = br0
lxc.net.0.macvlan.mode = bridge
lxc.net.0.name = eth0
lxc.net.0.mtu = 1500
lxc.net.0.hwaddr = 00:16:3e:9a:fa:42
# Common configuration
lxc.include = /usr/share/lxc/config/debian.common.conf
# Container specific configuration
lxc.tty.max = 4
lxc.arch = armhf
lxc.pty.max = 1024
lxc.rootfs.path = dir:/var/lib/lxc/bullseye-nextcloud/rootfs
lxc.uts.name = bullseye-nextcloud

lxc.mount.entry = /shares/nextcloud-data nextcloud-data none bind 0 0
lxc.mount.entry = /shares/webdav webdav none bind 0 0

[bluestar]

einmal auf einem Raspi3 und einmal ein Intel Celeron

Das sind zwei unterschiedliche Architekturen, der RasPi ist ein Arm System, der Celeron ein x86 System.

Kurzum das wird nicht funktionieren.