CT/LXC-Update schlägt fehl (config does not exist) — vm.update fällt für LXC auf qemu-Pfad zurück; ct.update via pct exec #51

Closed
opened 2026-06-02 12:38:20 +00:00 by chinux · 0 comments
Owner

Symptom

Update eines LXC/CT schlägt fehl — „Config nicht finden" / Configuration file does not exist.

Root Cause

Die Update-API ist VM-zentriert (/api/update/nodes/<node>/vms/<vmid>/update|preview|scan) und sendet vm.update. Dessen Handler (commands_async.rs:73-91) relayt zum VM-Guest-Agent und fällt sonst auf qm::qm_agent_exec_streaming zurück — also /nodes/<node>/**qemu**/<vmid>/agent/exec. Für einen LXC existiert dieser Pfad nicht (/lxc/<vmid>), pvesh meldet „Configuration file '…/qemu/.conf' does not exist". Es gibt keinen ct.update-Command (nur ct.exec).

Fix

Node-Agent: ct.update (Kanal 1, via pct exec)

Neuer Command analog ct.exec (commands.rs:91, nutzt pct::ct_exec):

pct exec <vmid> -- sh -c "DEBIAN_FRONTEND=noninteractive apt-get update 2>&1 && DEBIAN_FRONTEND=noninteractive apt-get -y dist-upgrade 2>&1"

Streaming-Variante wie bei vm.update (Chunks live ans Backend). Analog ct.update_preview (apt-get -s dist-upgrade | grep -c '^Inst') und CT-Update-Count für das Banner.

Backend: CT-aware Routing — nie qemu-Fallback für LXC

Der Update-Pfad muss kind=ct kennen:

  • CT mit enrolltem VM-Guest-Agent (läuft auch in LXC, vgl. deploy_router.py:310) → vm.update-Relay wie gehabt.
  • CT ohne Agent → ct.update (pct exec).
  • Für LXC niemals auf qm_agent_exec zurückfallen.
    Entweder CT-Endpoints ergänzen (/cts/<vmid>/update|preview|scan) oder den bestehenden Update-Pfad sauber auf VM/CT verzweigen.

Akzeptanz

  • CT-Update läuft (Pakete im Container aktualisiert), Live-Output sichtbar, kein „config does not exist" mehr.
  • Update-Count/Preview funktioniert auch für CTs.
  • VM-Update unverändert.

Bezug

Gleiches Thema wie das CT-IP-Issue (CTs werden wie VMs behandelt).

Branch

fix/ct-update-pct-exec

## Symptom Update eines LXC/CT schlägt fehl — „Config nicht finden" / *Configuration file does not exist*. ## Root Cause Die Update-API ist VM-zentriert (`/api/update/nodes/<node>/vms/<vmid>/update|preview|scan`) und sendet `vm.update`. Dessen Handler (`commands_async.rs:73-91`) relayt zum VM-Guest-Agent und fällt sonst auf `qm::qm_agent_exec_streaming` zurück — also `/nodes/<node>/**qemu**/<vmid>/agent/exec`. Für einen LXC existiert dieser Pfad nicht (`/lxc/<vmid>`), pvesh meldet *„Configuration file '…/qemu/<vmid>.conf' does not exist"*. Es gibt **keinen `ct.update`**-Command (nur `ct.exec`). ## Fix ### Node-Agent: `ct.update` (Kanal 1, via `pct exec`) Neuer Command analog `ct.exec` (`commands.rs:91`, nutzt `pct::ct_exec`): ``` pct exec <vmid> -- sh -c "DEBIAN_FRONTEND=noninteractive apt-get update 2>&1 && DEBIAN_FRONTEND=noninteractive apt-get -y dist-upgrade 2>&1" ``` Streaming-Variante wie bei `vm.update` (Chunks live ans Backend). Analog `ct.update_preview` (`apt-get -s dist-upgrade | grep -c '^Inst'`) und CT-Update-Count für das Banner. ### Backend: CT-aware Routing — **nie** qemu-Fallback für LXC Der Update-Pfad muss `kind=ct` kennen: - CT **mit** enrolltem VM-Guest-Agent (läuft auch in LXC, vgl. `deploy_router.py:310`) → `vm.update`-Relay wie gehabt. - CT **ohne** Agent → `ct.update` (pct exec). - Für LXC **niemals** auf `qm_agent_exec` zurückfallen. Entweder CT-Endpoints ergänzen (`/cts/<vmid>/update|preview|scan`) oder den bestehenden Update-Pfad sauber auf VM/CT verzweigen. ## Akzeptanz - CT-Update läuft (Pakete im Container aktualisiert), Live-Output sichtbar, kein „config does not exist" mehr. - Update-Count/Preview funktioniert auch für CTs. - VM-Update unverändert. ## Bezug Gleiches Thema wie das CT-IP-Issue (CTs werden wie VMs behandelt). ## Branch `fix/ct-update-pct-exec`
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
chinux/theProx#51
No description provided.