Einrichtung einer virtuellen Maschine unter Manjaro‑Linux zur Nutzung von Archicad

[jta]

Einleitung und Zielsetzung

Virtuelle Maschinen ermöglichen es, ein Betriebssystem isoliert vom Hauptsystem zu betreiben. Dadurch erreicht ihr eine höhere digitale Souveränität und könnt experimentieren, ohne euren Host negativ zu beeinflussen. In diesem Beitrag zeige ich euch, wie ihr mit QEMU/KVM, libvirt und virt-manager unter Manjaro‑Linux eine VM einrichtet – als Basis, um unter anderem Archicad zu betreiben.
Wichtig: Archicad lässt sich zwar in einer VM installieren, jedoch kann die Lizenzaktivierung nicht innerhalb der virtuellen Umgebung durchgeführt werden.

Voraussetzungen

• Betriebssystem: Manjaro‑Linux
• Hardware: Rechner mit Virtualisierungsunterstützung (VT-x/AMD-V im BIOS aktiviert)
• Netzwerk: Internetzugang für den Download der Pakete
• Kenntnisse: Grundkenntnisse im Umgang mit dem Terminal

1. Installation der nötigen Pakete

Öffnet ein Terminal und führt folgenden Befehl aus:

sudo pacman -Syu qemu virt-manager libvirt

Erklärung:

• qemu/kvm: Ermöglichen die Virtualisierung.
• virt-manager: Bietet eine grafische Oberfläche zur Einrichtung und Verwaltung eurer VMs.
• libvirt: Steuert die Virtualisierungsdienste und stellt unter anderem den Befehl virsh bereit.

Tipp: Stellt sicher, dass euer System vollständig aktualisiert ist (siehe pacman -Syu).

2. Aktivieren und Starten des libvirt-Dienstes

Damit alle Virtualisierungsdienste laufen, aktiviert und startet ihr den libvirtd-Dienst:

sudo systemctl enable libvirtd
sudo systemctl start libvirtd

Erklärung:

• enable: Sorgt dafür, dass libvirtd beim Systemstart automatisch geladen wird.
• start: Startet den Dienst sofort.

3. Überprüfen und Starten des Standard-Netzwerks („default“)

a) Netzwerk überprüfen:

Gib folgenden Befehl ein, um zu sehen, ob das Standard-Netzwerk existiert:

sudo virsh --connect qemu:///system net-list --all

Mögliche Ausgabe:

Name       Status   Autom. Start   Bleibend
-----------------------------------------------------
default    Inaktiv  nein           ja

b) Netzwerk aktivieren:

Falls das Netzwerk „default“ inaktiv ist, startet es mit:

sudo virsh --connect qemu:///system net-start default
sudo virsh --connect qemu:///system net-autostart default

Erklärung:

• net-start: Aktiviert das Netzwerk sofort.
• net-autostart: Stellt sicher, dass es beim nächsten Neustart automatisch geladen wird.

4. Erstellen einer virtuellen Festplatte

Bevor ihr die VM installiert, erstellt ihr ein virtuelles Laufwerk (z. B. eine 60 GB große Festplatte):

qemu-img create -f qcow2 ~/windows11.qcow2 60G

Erklärung:

• qcow2: Ein flexibles und weit verbreitetes Festplattenformat.
• Passt Pfad und Größe nach euren Bedürfnissen an.

5. Erstellen und Installieren der Virtuellen Maschine

Es gibt zwei Möglichkeiten: die grafische Oberfläche von virt-manager oder die Installation per Terminal. Hier ein Beispiel mit virt-install (passt den Pfad zur Windows‑11‑ISO an):

sudo virt-install \
--name Windows11 \
--ram 4096 \
--disk path=/var/lib/libvirt/images/windows11.qcow2,size=60 \
--vcpus 2 \
--os-type windows \
--os-variant win11 \
--network network=default \
--graphics spice \
--cdrom /pfad/zur/windows11.iso

Erklärung:

• --name: Vergibt den Namen der VM (hier "Windows11").
• --ram: Weist 4096 MB Arbeitsspeicher zu.
• --disk: Definiert Speicherort und Größe der virtuellen Festplatte.
• --vcpus: Zuweisung der virtuellen Prozessoren.
• --os-type / --os-variant: Optimiert die Konfiguration für das jeweilige Betriebssystem.
• --network: Verbindet die VM mit dem "default"-Netzwerk.
• --graphics: Ermöglicht die grafische Darstellung (über SPICE).
• --cdrom: Legt den Pfad zur ISO-Datei fest, von der die Installation erfolgt.

Tipp: Falls ihr Schwierigkeiten habt, nutzt die GUI von virt-manager für eine schrittweise Einrichtung.

6. Starten der Virtuellen Maschine

Wenn ihr die VM über virt-install erstellt habt, startet sie automatisch. Andernfalls könnt ihr sie auch manuell starten:

sudo virsh start Windows11

Überprüft den Status mit:

sudo virsh list --all

7. Mögliche Fehler und Tipps

• Netzwerkprobleme:
  • Fehlermeldung: „network 'default' is not active“
  • Lösung: Das Netzwerk wie oben beschrieben starten.
• Unterschiede zwischen Session- und Systemmodus:
  • Achtet darauf, immer den Systemmodus (qemu:///system) zu verwenden.
• Berechtigungen:
  • Viele Befehle benötigen sudo; bei Fehlermeldungen wie „Permission denied“ einfach sudo voranstellen.
• Pfadangaben:
  • Stellt sicher, dass ISO- und Festplattenpfade korrekt eingegeben wurden.

---

Wichtiger Hinweis zu Archicad

Auch wenn diese Anleitung euch eine leistungsfähige VM bietet, um Archicad in einem geschützten Umfeld zu betreiben, bleibt eine gravierende Einschränkung bestehen: Die Softwarelizenz von Archicad lässt sich bedauerlicherweise nicht in eine Virtuelle Maschine herunterladen. Das bedeutet, dass ihr Archicad zwar in der VM installieren und nutzen könnt, aber die Lizenzaktivierung – ein unabdingbarer Schritt zur Nutzung – nicht innerhalb der virtuellen Umgebung durchgeführt werden kann. Überlegt daher genau, ob diese Methode für euer Setup geeignet ist oder ob ein nativer Betrieb in Betracht gezogen werden sollte.

---

Fazit

Mit dieser Anleitung richtet ihr unter Manjaro‑Linux eine virtuelle Maschine ein, die euch eine alternative und isolierte Arbeitsumgebung bietet. Ob zur Installation von Windows 11 oder anderen Betriebssystemen – die VM ist ein wertvolles Werkzeug für experimentelle Setups und digitale Souveränität. Denkt jedoch an den Lizenzhinweis zu Archicad, der den Einsatz in der VM erheblich einschränkt.

Optional: Für fortgeschrittene Anwender gibt es ergänzende Anleitungen zur Einrichtung von PCI‑Passthrough (z. B. zur direkten Weitergabe einer Grafikkarte an die VM), was insbesondere für grafikintensive Anwendungen interessant sein kann – auch hier bleibt jedoch der oben genannte Lizenzhinweis bestehen.

Viel Erfolg beim Experimentieren und dem Aufbau eurer eigenen, digitalen Umgebung!

[jta]

Fortsetzung: Einrichtung von PCI‑Passthrough in einer virtuellen Windows‑Maschine

1. Vorbereitung des Linux‑Systems

A. GRUB-Konfiguration anpassen

Um die Hardware optimal für den Passthrough vorzubereiten, müsst ihr den GRUB-Bootloader so konfigurieren, dass IOMMU aktiviert wird. Öffnet dazu die GRUB-Konfiguration:

sudo nano /etc/default/grub

Sucht die Zeile mit GRUB_CMDLINE_LINUX_DEFAULT und ergänzt folgende Parameter (Beispiel):

GRUB_CMDLINE_LINUX_DEFAULT="quiet amd_iommu=on iommu=pt video=efifb:off"

Hinweis: Je nach Hardware (bspw. bei Intel-Prozessoren) müsst ihr eventuell Parameter wie intel_iommu=on verwenden.

Anschließend aktualisiert ihr GRUB. Unter Manjaro kann dies in der Regel so erfolgen:

sudo update-grub

Sollte dieser Befehl nicht verfügbar sein, verwendet alternativ:

sudo grub-mkconfig -o /boot/grub/grub.cfg

B. VFIO-Bindung konfigurieren

Damit bestimmte Geräte nicht vom Hostsystem, sondern ausschließlich vom VFIO‑Treiber genutzt werden, erstellt bzw. bearbeitet ihr die Datei für die VFIO-Konfiguration:

sudo nano /etc/modprobe.d/vfio.conf

Fügt hier die entsprechenden Einträge ein – als Beispiel:

• Für eine NVIDIA-Grafikkarte:

  options vfio-pci ids=10de:2705,10de:22bb

• Für den Intel X540‑T2 Netzwerkadapter:

  options vfio-pci ids=8086:1528

Speichert die Datei und aktualisiert anschließend das Initramfs:

sudo mkinitcpio -P

Zum Abschluss startet ihr euer System neu:

sudo reboot

---

2. Überprüfung der VFIO-Bindung

Nach dem Neustart solltet ihr kontrollieren, ob die gewünschten Geräte erfolgreich an den VFIO‑Treiber gebunden wurden.

Überprüfung mittels lspci:

Ermittelt die relevanten Geräte (z. B. den Netzwerkadapter an Adresse 03:00) mit:

lspci -nnk | grep -A 3 '03:00'

In der Ausgabe sollte unter anderem stehen:

Kernel driver in use: vfio-pci

Falls statt dessen andere Treiber (z. B. ixgbe) angezeigt werden, ist der Passthrough noch nicht korrekt eingerichtet.

Überprüfung der Kernelmeldungen:

Verwendet:

sudo dmesg | grep -i vfio

So erkennt ihr, ob VFIO ohne Fehler gestartet wurde. Achtet darauf, stets mit sudo zu arbeiten, um alle Meldungen zu erhalten.

---

3. Konfiguration der virtuellen Windows‑Maschine für PCI‑Passthrough

A. VM-Grundkonfiguration

• CPU: Stellt im Virt-Manager die Option „Host‑Passthrough“ ein, damit die VM direkt auf eure Prozessorfunktionen zugreifen kann. Diese Einstellung erfolgt über die grafische Oberfläche – die VM muss dazu ausgeschaltet sein.
• Firmware & Chipsatz: Nutzt UEFI (OVMF) in Kombination mit dem Q35‑Chipsatz, um moderne Hardware zu emulieren. Dies wird ebenfalls im Virt-Manager konfiguriert.

B. Hardware direkt an die VM durchreichen

Für jedes Gerät, das ihr per Passthrough nutzen möchtet (Grafikkarte, Maus, Tastatur, Netzwerkkarte), müsst ihr die VM-Konfiguration anpassen.

1. Ermitteln der Geräteadresse

Verwendet den Befehl:

lspci -nn | grep -i ethernet

Beispielausgabe für die Intel X540‑T2:

03:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller 10-Gigabit X540-AT2 [8086:1528] (rev 01)
03:00.1 Ethernet controller [0200]: Intel Corporation Ethernet Controller 10-Gigabit X540-AT2 [8086:1528] (rev 01)

Notiert euch die Bus-, Slot- und Funktionsnummern. Ähnliche Vorgehensweisen gelten für die Grafikkarte sowie USB-Geräte (Tastatur/Maus).

2. Bearbeiten der VM-XML

Um die Geräte der VM zuzuordnen, öffnet ihr die XML-Konfiguration der VM (im folgenden Beispiel „win11“):

sudo EDITOR=nano virsh edit win11

Fügt im <devices>-Abschnitt für jedes Gerät einen Eintrag hinzu. Beispiel für beide Ports der Netzwerkkarte:

<hostdev mode='subsystem' type='pci' managed='yes'>
  <source>
    <address domain='0x0000' bus='0x03' slot='0x00' function='0x0'/>
  </source>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='yes'>
  <source>
    <address domain='0x0000' bus='0x03' slot='0x00' function='0x1'/>
  </source>
</hostdev>

Analog könnt ihr weitere <hostdev>-Blöcke für die Grafikkarte sowie für USB-Geräte (Maus, Tastatur) hinzufügen.
Hinweis: Falls bereits ein <hostdev>-Eintrag existiert, können doppelte Einträge zu Fehlern führen („Hostdev already exists“). Überprüft die aktuelle Konfiguration mit:

sudo virsh dumpxml win11 | grep -A 5 "<hostdev"

---

4. Test und Überprüfung in der Windows‑VM

Sobald ihr alle gewünschten Geräte der VM zugeordnet habt, startet sie:

sudo virsh start win11

In der virtuellen Windows‑Umgebung öffnet ihr den Geräte-Manager, um zu prüfen, ob alle durchgereichten Geräte (z. B. Netzwerkkarte, Grafikkarte, USB-Geräte) korrekt erkannt werden. Sollte ein Gerät nicht angezeigt werden, prüft die XML-Konfiguration und ob die Geräte tatsächlich vom VFIO‑Treiber übernommen wurden.

---

5. Zusammenfassung und Erfahrungen

Wichtige Schritte:

• GRUB-Anpassung: Aktiviert IOMMU (amd_iommu=on oder intel_iommu=on) und passt die Bootparameter an.
• VFIO-Bindung: Konfiguriert /etc/modprobe.d/vfio.conf und erstellt ein neues Initramfs.
• Geräteüberprüfung: Nutzt lspci und dmesg, um sicherzustellen, dass die Geräte korrekt gebunden sind.
• VM-Konfiguration: Bearbeitet die XML der VM über virsh, um die Hardware direkt durchzureichen.
• Test in Windows: Kontrolliert im Geräte-Manager, ob alle Komponenten ordnungsgemäß funktionieren.

Erkenntnisse:
Die Einrichtung von PCI‑Passthrough erfordert sorgfältige Konfiguration und genaue Eingaben – schon ein Tippfehler in der GRUB-Konfiguration oder in den Geräte-IDs kann den Prozess behindern. Dennoch zeigt systematisches Vorgehen, dass auch komplexe Setups realisierbar sind.

---

Fazit

Mit diesem erweiterten Setup könnt ihr eure virtuelle Windows‑Maschine um direkt durchgereichte Hardwarekomponenten ergänzen – ideal, wenn ihr beispielsweise grafikintensive Anwendungen nutzen möchtet oder spezielle Hardwarefunktionen benötigt. Achtet darauf, dass alle Änderungen (vor allem an der GRUB-Konfiguration und den VFIO‑Bindungen) mit Bedacht vorgenommen werden und testet die Konfiguration Schritt für Schritt.

Diese Anleitung ist als Fortsetzung des ersten Beitrags zu verstehen und soll euch dabei helfen, eure VM noch leistungsfähiger und hardware-näher zu betreiben. Viel Erfolg bei euren Experimenten und beim Erreichen einer noch höheren digitalen Souveränität!

[jta]

Die Archicad-Lizenzproblematik

Ein wesentlicher Kritikpunkt bei der Nutzung von Archicad in einer virtuellen Maschine ist die Lizenzierung.
Wichtig: Archicad lässt sich zwar in einer VM installieren, aber der Lizenzmanager verhindert den Download und die Aktivierung der Lizenz innerhalb der virtuellen Umgebung. Dies führt dazu, dass trotz technisch einwandfreier Einrichtung die voll funktionsfähige Nutzung der Software nicht gewährleistet werden kann.

Warum blockiert der Lizenzmanager den Download?

• Schutzmechanismen:
  Lizenzmanager moderner Software setzen häufig auf Mechanismen, die die Umgebung analysieren. Wird eine VM erkannt, kann der Lizenzmanager den Lizenzdownload gezielt blockieren, um unautorisierte Nutzung oder Umgehung von Lizenzbestimmungen zu verhindern.

• Auswirkungen auf den Betrieb:
  Selbst wenn alle anderen Komponenten in der VM korrekt konfiguriert sind – inklusive der Verschleierung der Virtualisierungsmerkmale – bleibt die zentrale Einschränkung bestehen: Ohne aktive Lizenz kann Archicad nicht genutzt werden.

Alternative Ansätze

• Natives Setup:
  Aufgrund dieser Problematik empfiehlt es sich, Archicad auf einem nativen Betriebssystem zu installieren, um die uneingeschränkte Nutzung der Software zu gewährleisten.

• Hybrid-Lösungen:
  Für Testumgebungen oder experimentelle Setups können alternative Softwarelösungen in Betracht gezogen werden, die weniger restriktive Lizenzmodelle in virtuellen Umgebungen unterstützen. Eine langfristige Lösung für Archicad selbst ist jedoch meines Erachtens derzeit nicht in Aussicht.

[jta]

Ich möchte ergänzend mitteilen, dass der Download der Softwarelizenz mit dem Lizenz-Manager in meiner Konfiguration zwar nicht funktioniert hat. Starte ich jedoch Archicad direkt und öffne das zu bearbeitende Projekt, wird die Lizenz anschließend dennoch heruntergeladen und ich kann Archicad ohne jede Einschränkung nutzen. Eine Eigenart, die hoffentlich so bleibt!

Abgesehen davon, läuft die virtuelle Maschine unter Manjaro-Linux einwandfrei. Ich hoffe, dass sich trotz des teils erheblichen Aufwands noch weitere Interessierte finden, die diese Schritte ausprobieren und von den Vorteilen einer virtuellen Umgebung profitieren.

Herzliche Grüße
Jan Taplick

[Stefan L_]

Danke für die ausführliche Beschreibung.

[archig]

... Trotzdem möchte ich mal vorsichtig nachfragen, welche konkreten Vorteile Du dabei siehst.

Der Aufwand ist ja schon hoch, und der Performance von ArchiCAD wird es auch nicht unbedingt zugute kommen. 

[jta]

In unserem Architekturbüro haben wir bewusst den Weg gewählt, eine virtuelle Maschine unter Linux zu betreiben, um eine stabile, performante und datensouveräne Arbeitsumgebung zu schaffen.
Archicad gehört dabei zu den wenigen Programmen, während der Großteil unserer weiteren Anwendungen entweder direkt für Linux portiert wurde, als Open-Source-Lösungen verfügbar sind oder zuverlässig über Wine bzw. Crossover installiert und genutzt wird.

So vermeiden wir störende Telemetrie und unerwünschte Werbeeinblendungen und behalten gleichzeitig die volle Kontrolle über unsere Systeme und Daten.
Der damit gewonnene Grad an Unabhängigkeit und Sicherheit hat sich in der täglichen Arbeit voll ausgezahlt – unsere Arbeitsabläufe laufen reibungslos, und die Investition in diesen Ansatz erweist sich als absolut alltagstauglich.

Meines Erachtens lohnt es sich, sich auch vor dem Hintergrund des aktuellen weltpolitischen Kontexts intensiv mit der digitalen Souveränität auseinanderzusetzen. In Anbetracht dessen ist die investierte Mühe keine allzu hohe Hürde, sofern das Know-how und die entsprechende Hardware vorhanden sind.

Beste Grüße
Jan Taplick

[archig]

Danke für die ausführliche Beschreibung. Und für die Infos bezüglich der Gründe, die Dich bzw. das Architekturbüro veranlasst haben, im Allgemeinen auf Open-Source zu setzen, ArchiCAD in einer Virtuellen Maschine zu installieren, und hohen Wert auf die eigene Datensouverenität zu legen. Aber: 

Es muss jemanden im Büro geben, der über das notwendige Wissen zum Umgang mit Linux verfügt, Das Büro muss die Priorität auf Open Source bei Standardbürosoftware (Office, Projektplanung, etc) legen (wenn nicht, kann man es gleich bleiben lassen...), und man muss bei spezieller Architektensoftware (AVA, Baukosten, Energieberatung) schauen, ob das auch in einer Virtuellen Maschine läuft (die Software macht wahrscheinlich nicht die Probleme, sondern eher wieder die Lizenz). 

Für mich kommt es wegen einem Teil der genannten Gründe nicht in Betracht. 

Würde mich aber doch interessieren, ob das sonst jemand hier ernsthaft in Erwägung zieht

[torben_wadlinger]

Sorry, aber das ist totaler Humbug. Das Ziel der Datensouveränität gewinnst Du damit auch nicht, da du wieder auf Windows setzen musst - zwar in einer VM gekapselt, aber Windows bleibt Windows.

Es gibt so viele bessere Lösungen, angefangen bei Macs (wenn es ein Unix-oides System sein soll), über VM's in einem Proxmox-Server, der dann eben ordentliche Passthrough-Grafik-Hardware hat und mit Zugriff via RDP oder VNC, bis hin zu einer kleinen Cluster-Lösung mit HP Z1-Workstations und der HP-Remote-Lösung HP-RGS für Macs, Windows und Linux. Das nach-hause-telefonieren löst Du ohnehin über Port-Sperren im Router für die jeweiligen IP's oder MAC's.

Lokal reicht dann ein Thin-Client für ein paar Euro und Zugriff bekommst Du via VPN von Aussen auf die VM's, d.h. echtes mobiles Arbeiten ohne dass die Daten das Büro verlassen.

[jta]

Hallo Torben,

vielen Dank für deine kritische Anmerkung und die zusätzlichen Vorschläge. Ich verstehe deinen Einwand gut, möchte aber einige Aspekte klarstellen und unsere Sichtweise erläutern.

Unser Ansatz basiert darauf, dass wir Linux als primäres Betriebssystem einsetzen möchten – aus Überzeugung für Open-Source, Privatsphäre und Kontrolle über unsere Systeme. Natürlich bleibt Windows als Betriebssystem innerhalb der VM erhalten, doch das entscheidende Kriterium hierbei ist, wie weit der Zugriff und die Kommunikation von Windows kontrolliert werden können.

Gerade durch die Kapselung von Windows in einer VM haben wir zahlreiche Vorteile:

• Kontrolle und Isolation: Wir steuern präzise, welche Daten in die VM hinein- und hinausfließen. Ein direkter, unkontrollierter Zugriff von Windows auf unsere Netzwerk- oder Firmendaten wird dadurch erheblich erschwert.

• Bessere Updatestrategie: Die VM ermöglicht unkomplizierte Snapshots und Backups. Sollte ein Windows-Update oder Software-Update Probleme verursachen, können wir innerhalb kürzester Zeit auf einen funktionierenden Zustand zurückkehren.

• Datensouveränität: Auch wenn Windows in einer VM läuft, sind unsere Daten nicht abhängig vom Betriebssystem. Wir speichern alle relevanten Daten primär unter Linux. Windows ist lediglich ausführendes Werkzeug, nicht Verwalter oder zentraler Speicherplatz unserer Firmendaten.

Deine Vorschläge zu alternativen Lösungen wie Proxmox, RDP oder HP-RGS finde ich ebenfalls interessant. Proxmox mit GPU-Passthrough wäre technisch sicherlich möglich, aber die lokale Nutzung einer VM hat für uns in Bezug auf Flexibilität und Benutzerfreundlichkeit aktuell größere Vorteile. Zudem wollen wir nicht zwingend Remote-Desktop-Lösungen einsetzen, da diese auch Performanceverluste (besonders bei CAD-Software wie Archicad) oder Latenzprobleme mit sich bringen könnten.

Die Nutzung eines Macs wäre ebenfalls denkbar, reduziert aber wiederum die Kontrolle, welche wir durch Linux gewinnen, und bedeutet eine Abhängigkeit von einer einzigen Hardware- und Softwareplattform.

VPN und Firewall-Regeln gehören selbstverständlich auch bei uns zur Standardausstattung, aber die Kapselung einer VM stellt hier noch eine zusätzliche Sicherheitsschicht dar.

Unterm Strich zeigt unsere Erfahrung, dass unser aktuelles Setup sich im Alltag bewährt hat. Deine Punkte sind absolut valide – und sicher nicht für jedes Büro gleich relevant. In unserem Fall überwiegen jedoch die Vorteile deutlich.

Beste Grüße Jan Taplick