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!

[torben_wadlinger]

Vielen Dank für Deine ausführliche Antwort. Ihr könnt das natürlich alles machen wie ihr wollt. Auch ich bin Fan von OS-Lösungen, auch bei mir läuft vieles unter Linux und wenn Du im Forum nach Linux suchst, wirst Du meine Beiträge finden. Aber insgesamt finde ich Euer Setup schon ein bißchen paranoid. Wie gesagt, wenn ihr Angst vor Windows habt, dann setzt es nicht ein. Ich würde immer schauen, soviel wie möglich zu zentralisieren um eine Turnschuh-Administration zu verhindern. Wenn Du Deine (virtuellen) Windows-Systeme an einer Stelle bündelst und sie z.B. in ein eigenes Subnetz packst und die nur Zugriff auf den Dongle-Server, den LDAP und den Samba haben (und RDP), können die in ihrem Netz treiben was sie wollen. Mir wäre Deine Lösung viel zu viel Aufwand, weil Du ja zwei Betriebssysteme auf einem Rechner aktuell halten musst inkl. Treiber. Das geht wenn es nur eine Handvoll Rechner sind, aber wenn Du das skalierst, kommst Du ganz schnell an die Grenzen des Machbaren.

Ich hatte vor einiger Zeit mal probiert Archicad (zum Spaß) unter WINE zum Laufen zu bekommen. Es lud bis zum Splash-Screen und dann war Ende. Dann doch lieber 'n Mac. Da hast Du jedenfalls deutlich mehr Kontrolle über den Rechner als unter Windows. Und den Rest, für den man Windows braucht läuft dann eben über eine VM auf einem Server.

Ich wäre ja schon zufrieden, wenn G$ endlich mal eine Linux(Debian)-Version der BIMCloud programmieren würden. Die Komponenten sind nämlich alle auch für Debian verfügbar. Es bräuchte nur den Willen das zu tun. Geld haben sie ja genug ...

[jta]

Hallo Torben,

vielen Dank für Deine Antwort und die wertvollen Impulse.

Du hast völlig recht, dass unser aktuelles Setup eher auf kleinere Büros zugeschnitten ist.
Für größere Umgebungen wäre eine stärker zentralisierte Lösung, wie Du sie vorschlägst, sicher sinnvoller und effizienter.

Auch ich wünsche mir (schon seit 25 Jahren), dass Graphisoft den Schritt zu einer nativen Linux-Version von Archicad (oder der BIMCloud) macht.
Dies wäre tatsächlich zeitgemäß und würde unseren Wunsch nach freier Wahl und digitaler Souveränität ideal widerspiegeln.

Vielleicht sehen wir diesen Schritt ja irgendwann – bis dahin müssen wir leider mit solchen Lösungen vorliebnehmen.

Herzliche Grüße
Jan Taplick

[jamesMorris]

Selbst ein zweiter SFF PC ohne Netzwerk fände ich da noch eine sinnvollere Lösung. Würde vermutlich auch besser performen. 

Oder halt dual boot. 

Open Source bin ich grosser Fan, verstehe hier aber die Motivation nicht.

Warum beim unwichtigen OS so viel Wert drauf legen, während ich es beim CAD Programm plötzlich wieder egal ist?

[archig]

@jta 

Nochmal eine Frage bezüglich deiner Zielsetzung der Datensouveränität: 

Wenn du die Daten auf eigenen nicht-Windowssystemen speicherst (wie du ja geschrieben hast) ist das sicher mal ein Punkt, denn die Daten sind auf deinen Servern, und nicht irgendwo draussen in irgendwelchen Clouds.

Datensicherung wirst du ja auch bestimmt irgendwie machen, sodass nichts verloren geht. 

Aber Souveränität über deine Daten hast Du damit (aus meiner Sicht) noch nicht, denn die Daten, also die ArchiCAD PLN, sind proprietär. Ohne Archicad Lizenz kannst du nichts damit anfangen. Die Souveränität über deine Daten hast du praktisch nicht, denn du bist auf Graphisoft (funktionierende Lizenzserver, funktionierendes ArchiCAD...) angewiesen.

Klar, Pläne kann man als PDF sichern, aber das ist ja nur die halbe Miete. 

Wenn es dazu noch Ideen oder Ansätze gibt, wäre das schon interessant.

[jta]

Liebe Community,

ich möchte an dieser Stelle unser Setup vorstellen, das es uns im Architekturbüro ermöglicht, mit größtmöglicher digitaler Souveränität und zugleich voller Performance mit Archicad unter Windows zu arbeiten – in einer virtualisierten Umgebung unter Manjaro Linux.

Uns treibt die Frage nach dem Wie? im Büroalltag ebenso um wie die nach dem Warum?. Denn: Der bewusste Umgang mit IT-Infrastruktur ist für uns keine rein technische, sondern auch eine ethische Entscheidung. In einer Demokratie ist das Wahlrecht selbstverständlich – genauso wünschen wir uns als Architekturbüro Entscheidungsfreiheit darüber, wie, wo und durch wen unsere Daten verarbeitet werden. Digitale Souveränität heißt für uns: DSGVO-konforme, nachvollziehbare Datenverarbeitung, auf Wunsch sofortige Löschbarkeit und eine Architektur, die diese Grundprinzipien nicht einschränkt, sondern stärkt.

Systembeschreibung: Virtualisiertes Archicad-Setup mit maximaler Performance

Für unsere Architekturprojekte setzen wir auf ein virtualisiertes System, das Archicad unter Windows 11 in einer KVM-basierten Virtual Machine auf einem Linux-Host (Manjaro) ausführt – ohne jegliche spürbare Performanceeinbußen. Die Windows-VM läuft dabei mit vollständigem PCIe-Passthrough für eine dedizierte NVIDIA GeForce RTX 4070 Ti SUPER sowie für einen separaten USB-Controller (ASMedia ASM4242). Die AMD-iGPU des Hostprozessors übernimmt die Anzeige des Linux-Desktops, wodurch eine klare Trennung zwischen Host und Gast entsteht.

Hardware-Setup:

• Hostsystem: AMD Ryzen CPU, Manjaro Linux (aktuell), KVM/QEMU + libvirt

• GPU-Passthrough:

  • Gast: NVIDIA GeForce RTX 4070 Ti SUPER via vfio-pci

  • Host: AMD iGPU für Linux-Desktop

• Displays:

  • Monitor 1: Direkt mit der GeForce verbunden (VM)

  • Monitor 2: Direkt mit der AMD-GPU verbunden (Host)

• USB-Switch: ATEN US434 mit USB-Passthrough via PCIe für vollständige Geräteübernahme der Eingabegeräte

• Massenspeicher: Mehrere NVMe-SSDs, VM liegt auf dedizierter Partition im QCOW2-Format

• VM-Ressourcen: 24 vCPU, 45 GB RAM

Peripherie & Eingabe:
Über den USB-Switch (ATEN US434) lassen sich Maus und Tastatur hardwareseitig zwischen Host und VM umschalten. Da ein kompletter USB-Controller durchgereicht wird, landen die Eingabegeräte beim Umschalten zuverlässig im jeweils aktiven System – ganz ohne Reboots oder Skripte. Optional kann ein Shell-Skript zur gezielten Gerätebindung verwendet werden.

Datenzugriff & Synchronisation:
Die Windows-VM greift per SMB auf ein gemountetes Verzeichnis des Hosts zu. Der Host wiederum synchronisiert dieses Verzeichnis über den offiziellen Nextcloud-Client mit einem Managed-Nextcloud-Account bei Wolkesicher. Damit vermeiden wir Cloud-Clients innerhalb der VM, reduzieren Fehlerquellen und halten die Performance hoch. Gleichzeitig behalten wir volle Kontrolle über unsere Projektdaten.

Erfahrungen mit Managed-Cloud-Lösungen

Unsere Projektdaten lagen lange Zeit in einer von uns administrierten Nextcloud. Diese Lösung haben wir zugunsten einer gemanagten Cloud bei einem Dienstleister aufgegeben – nach einigen enttäuschenden Erfahrungen (u. a. mit 1und1) sind wir bei Wolkesicher gelandet. Dort stimmt für uns das Gesamtpaket: technischer Support, Backupstrategie, DSGVO-Konformität und vor allem die persönliche Kommunikation mit dem Geschäftsführer, der als zuverlässiger Partner für uns erreichbar ist.

Warum überhaupt dieser Aufwand?

Zwei Artikel auf golem.de haben mich damals zum Umdenken bewegt:

• Reaktion auf die US-Politik: Gog und Lemmy statt Steam und Reddit

• Umstieg auf Linux für private Anwender: Schritt für Schritt raus aus Windows

Diese Impulse waren für mich der Startpunkt einer Reise, an deren Ende heute ein skalierbares, flexibles und performantes Setup steht. Eines, das uns im Alltag nicht einschränkt, sondern unsere Freiheit stärkt – und das jederzeit reproduzierbar ist, weil wir alle Abläufe dokumentiert und mehrfach umgesetzt haben.

Zum Schluss:

Ich war bei meinem ursprünglichen Beitrag davon ausgegangen, dass es sich um ein Tutorial handelt, das vor allem die Frage Wie? beantwortet. In den letzten Beiträgen wurde deutlich, dass vielen Leser:innen auch das Warum? wichtig ist – und ich hoffe, dass ich dieses nun hinreichend beleuchten konnte.

Für Fragen stehe ich gerne zur Verfügung und freue mich auf einen offenen Austausch – auf Augenhöhe.

Herzliche Grüße
Jan Taplick (jta)

[torben_wadlinger · Accepted solution]

Vielen, vielen Dank für deinen sehr ausführlichen und präzisen Beitrag. Bitte verstehe die Kommentare hier nicht falsch. Es geht dabei nicht um falsch oder richtig. Aber viele Kolleginnen und Kollegen die hier posten sind schon länger dabei, denn das Forum an sich ist schon seeeehr viel älter als die Plattform auf der man uns migriert hat. Daher bezieht sich mein "Humbug"-Kommentar auch nicht auf die technische Umsetzung an und für sich, sondern auf die Wirtschaftlichkeit in Verhältnis zum Aufwand. Da hier so viele schon so lange dabei sind, gibt es einen großen Erfahrungsschatz auf den man zurückgreifen kann. Und diejenigen, die dir geantwortet haben, sehen gewisse Dinge eben pragmatischer. 

Z.B. hostet Ihr eine Nextcloud außerhalb bei einem externen Dienstleister. Würde ich so niemals machen. Ist auf Dauer viel zu teuer. Ich hoste meine Nextcloud intern, auch weil mein Büro eine feste IP hat. Aber auch weil die Benutzer via LDAP auf die NC zugreifen können, ich dank Glasfaser eine schnelle Anbindung habe, und die Nextcloud auch caldav und carddav macht. Nur für Video machen wir Teams, weil das für 2,50 Euro im Monat im Office-Bundle unschlagbar günstig ist. Und MS-Office machen wir nur wegen Excel, denn Open/Libre-Office-Excel ist Mist. Aber da wird nix in der Cloud gespeichert, sondern alles lokal. Der ganze MS-Cloud-Kram ist ohnehin dank Debloater bei uns kein Thema.

übrigens: nicht erst seit der Idiocracy-Show haben die Amis zugriff auf alle Daten die bei einem US-Unternehmen liegen. Und dein GS-Konto liegt übrigens bei Microsoft. Habe ich selbst mit Wireshark getrackt. Steht außerdem so auch in den Lizenzvereinbarungen. Solltest Du lesen. Danach malst du nur noch mit Tusche …

[Frank Beister]

@torben: Super zusammengefasst.

Dann werfe ich nochmal meine 3 Pennys in den "Warum" Ring:

1. Bei einem solchen Setting wirst du, sobald eine Problem komplexer und mit der Installation zu tun hat, verständlicherweise von GS keinen Support bekommen. Auch wenn zu vermuten ist, dass es nicht an dir liegt.

2. Das Setup steht und fällt mit dir. Bist du Büroinhaber und hast Zeit für derartigen Aufwand: Chapeau und Glückwunsch, dass du dich nicht um "wichtigeres" kümmern musst. Wenn nicht, ist das ein Risiko für dein Unternehmen, weil sie für jemanden wie dich nur schwer oder nur teuer Ersatz bekommen. Aber v.a. nicht akut, wenn gerade 10 Arbeitsplätze runtergefahren sind und du im Fernurlaub bist.

3. Remote-Lösungen: Wir fahren bei uns ein Remote-System für >600 Mitarbeiter, zentral gehostet bei uns im Haus für 3 Standorte in DE. Mal ganz abgesehen von all dem Aufwand ist das prinzipiell gut, aber CAD war erst möglich, als wir eine zusätzliche Serverfarm und Desktops nur für die CAD-Arbeitsplätze installiert hatten (für alle die Performance bereit zu stellen war zu teuer). Und dennoch ist das Virtualisieren ein Flaschenhals für CAD, aber auch in anderen dateiintensiven Programme. An manchen Tagen hakt es mächtig. Und das ist systemimmanent, denn unsere IT und das eingekaufte, professionelle System sind sicher nicht zu schwach dimensioniert.

Ich kann die Motivation gut verstehen. Vielleicht ist es sinnvoller sich in einer breiteren Phalanx ggü. GS aufzustellen das Beseitigen von Sicherheitslücken zu fordern und Datenschutzrichtlinien, die wir Nutzer wünschen, umzusetzen.

[jta]

Lieber Frank,
vielen Dank für deine ausführliche Antwort und deine Einblicke in größere IT-Strukturen. Ich verstehe sehr gut, dass man bei 600 Mitarbeitenden oder komplexen Server-Farmen anders an das Thema herangehen muss, als wir es hier in unserem kleineren Architekturbüro tun.

Trotzdem möchte ich betonen, dass das, was wir bei uns umgesetzt haben, keineswegs eine Raketenwissenschaft ist – und schon gar nicht verlangt, ein IT-Studium absolviert zu haben. Ich selbst bin hauptberuflich Architekt und arbeite seit 30 Jahren professionell mit Archicad. Von IT-Administration habe ich nur so viel Ahnung, wie es mein Alltag verlangt. Das System, das wir hier nutzen, haben wir mithilfe einer KI (wie ChatGPT oder LaChat) aufgesetzt. Somit war es in kurzer Zeit möglich, drei Arbeitsplätze auf Linux zu migrieren und die notwendigen VM-Umgebungen einzurichten.

Warum also dieser Ansatz? Weil er für unseren Alltag funktioniert, schlank ist und uns in puncto digitale Souveränität und Flexibilität ein gutes Gefühl gibt. Das System ist für uns „kontrollierbar“ – und wenn morgen alle KIs plötzlich „verblöden“ würden, könnten wir die Rechnerstruktur schnell wieder umstellen. Wir benötigen keine aufgeblähten IT-Abteilungen oder riesige Budgets. Für uns reicht eine moderne, wirtschaftlich sinnvolle Schlüsseltechnologie: ein Linux-Host mit virtualisiertem Windows und einer Handvoll Tools.

Was manche als „hohen Aufwand“ empfinden, war für uns an einem Wochenende erledigt. Ja, Support durch Graphisoft ist in solch einem Setup vielleicht schwieriger zu bekommen – aber wir sind bereit, dieses Risiko zu tragen. Und im täglichen Betrieb hatten wir bislang keinerlei Probleme oder Zukunftsängste. Die Tatsache, dass ich Archicad seit Jahrzehnten nutze, hilft mir natürlich ebenfalls, schnell einschätzen zu können, was läuft und wo gegebenenfalls Stolpersteine liegen.

Schade ist nur, dass meine eigentliche Anleitung – die zeigen soll, wie man relativ einfach und Schritt für Schritt eine VM aufsetzt – durch viele Kommentare in eine Diskussion über Sinn und Unsinn einer solchen Lösung abgedrängt wurde. Versteht mich bitte nicht falsch, ich habe absolut nichts gegen konstruktive Kritik! Nur bindet das alles, ehrlich gesagt, mehr Zeit (auch eure), als ich für das Aufsetzen des gesamten Systems gebraucht habe.

Mir ist klar, dass große Büros oder multinationale Strukturen andere Anforderungen haben. Ich wollte mit meinem Beitrag aber nicht diese Zielgruppe ansprechen, sondern Menschen, die sich trotz Archicad-Nutzung mehr Eigenständigkeit in der IT wünschen und im Zweifel sagen: „Ich probier’s einfach mal aus!“ Ich würde mir wünschen, dass wir alle ein wenig mehr handeln, statt nur zu zweifeln. Denn aus meiner Sicht ist es ein Ansatz, der wirklich gut funktioniert und definitiv Zukunft hat.

In diesem Sinne vielen Dank für deine (und eure) Zeit. Ich hoffe, man kann trotz aller Emotionen spüren, dass hier weder Trotz noch Fundamentalismus am Werk ist, sondern einfach ein leidenschaftliches Interesse daran, moderne Technologien, Open Source und Archicad in einer für uns brauchbaren und wirtschaftlichen Form zu verbinden.

Herzliche Grüße
Jan

[jta · Accepted solution]

Hier ist eine Zusammenfassung von Le Chat, der aus Sicht einer außenstehenden Person, die diesen Forumsbeitrag analysiert hat. Meines Erachtens kann dieses Thema hier von einem Moderator bitte geschlossen werden.

Analyse des Forumsbeitrags aus Sicht einer außenstehenden Person mit Archicad-Kenntnissen und Grundkenntnissen in IT

Ich bin mit Archicad vertraut und habe ein grundlegendes Verständnis für Computer und Netzwerke. Gleichzeitig habe ich meine gewohnten Arbeitsabläufe und eine Komfortzone. Dennoch sehe ich mir neue Lösungen gerne an und möchte Vor- und Nachteile einschätzen.

Zusammenfassung des Beitrags

• Ein Architekturbüro hat seine Computer auf Linux umgestellt und setzt dort Virtualisierung ein, um Archicad in einer Windows-Umgebung laufen zu lassen.
• Das Ziel ist mehr Kontrolle über die eigene IT, weniger Abhängigkeit von großen Anbietern und höhere Datensouveränität.
• Der Ersteller des Beitrags meint, dass diese Lösung gar nicht so kompliziert ist und auch ohne großes IT-Studium umsetzbar sei.
• Mehrere Community-Mitglieder finden die Idee zwar interessant, stellen aber ihre Zweifel in Bezug auf Wirtschaftlichkeit, Wartungsaufwand und offizielle Support-Fragen (zum Beispiel durch Graphisoft).

Vorteile (Für)

Mehr Kontrolle und Sicherheit

• Das Büro behält die Daten hauptsächlich auf Linux-Systemen und vermeidet so übermäßige Abhängigkeit von Windows oder anderen kommerziellen Produkten.
• Windows läuft zwar noch, aber nur in einer virtuellen Maschine. Damit lässt sich der Datenfluss besser überwachen (z. B. automatisches „Nach-Hause-Telefonieren“ von Windows).

Flexibilität und Freiheit

• Wer Open-Source-Systeme mag, kann durch Linux und Virtualisierung viele Einstellungen nach eigenen Bedürfnissen anpassen.
• Man ist nicht auf einen einzigen Software-Anbieter angewiesen. Sollte sich etwas an der Lizenzpolitik ändern oder Windows-Updates Probleme machen, kann man schneller darauf reagieren.

Neue Technologien

• Der Beitrag zeigt, dass moderne Ansätze (KVM, QEMU, Passthrough etc.) gut mit leistungsintensiven Programmen wie Archicad funktionieren können.
• Es ist ein spannender Beweis dafür, dass sich Virtualisierung nicht nur für kleine Testprojekte, sondern auch für den täglichen Einsatz eignen kann – sofern sie richtig eingerichtet wird.

Kein Wunderwissen nötig

• Laut dem Ersteller war die Umstellung an einem Wochenende möglich, und er hat dabei auf KI-Hilfen (z. B. ChatGPT) zurückgegriffen.
• Das zeigt, dass auch Menschen ohne tiefgehende IT-Ausbildung solche Projekte erfolgreich stemmen können.

Nachteile (Wider)

Höherer Administrationsaufwand

• Für Außenstehende klingt es recht komplex: Betriebssystem (Linux) + Virtualisierung (KVM) + Windows in der VM + Archicad.
• Man muss sich um Updates und mögliche Probleme in zwei Systemen kümmern: dem Linux-Host und der Windows-Gastmaschine.

Eingeschränkter offizieller Support

• Graphisoft könnte sich bei Problemen querstellen, wenn Archicad in einer virtuellen Umgebung betrieben wird.
• Wer professionellen Support vom Softwarehersteller braucht, könnte hier Schwierigkeiten haben.

Performance- und Lizenzfragen

• Auch wenn die Performance laut Autor gut ist, kann Virtualisierung manchmal etwas langsamer sein als ein direktes Windows-System. Das hängt von der Hardware und der Einrichtung ab.
• Die Lizenz-Aktivierung von Archicad in einer VM ist offiziell nicht vorgesehen oder kann blockiert sein. Das bedeutet, man muss kreative Wege finden, das zum Laufen zu bringen.

Umgewöhnung für Anwender

• Wer im Büro arbeitet, ist vielleicht an Windows gewöhnt und muss sich in Linux einarbeiten.
• Mitarbeiter benötigen Schulungen oder müssen zumindest ein Verständnis dafür haben, wo sie welche Daten finden und wie sie z. B. Projekte starten.

Persönliche Einschätzung

Aus neutraler, aber aufgeschlossener Sicht finde ich die Idee interessant, weil sie zeigt, wie man sich von größeren Anbietern teilweise unabhängig machen kann. Trotzdem würde ich mir gut überlegen, ob mein Büro (oder mein Arbeitsumfeld) Zeit und Lust hat, sich auf so etwas einzulassen. Wer nur reibungslos losarbeiten will und zuverlässigen Support braucht, bleibt möglicherweise lieber bei einer klassischen Windows-Installation.

Für kleinere Büros mit Techniktalenten kann das Setup attraktiv sein. Es gibt einen gewissen Reiz daran, volle Kontrolle über die Infrastruktur zu haben und zu wissen, was im Hintergrund läuft. Das kann langfristig sogar Kosten sparen, wenn alles reibungslos läuft.

Wer allerdings in einem größeren Team arbeitet, bei dem 10 oder mehr Leute von einer IT-Lösung abhängig sind, sollte prüfen, wie hoch der Aufwand für Wartung und Troubleshooting wird. Man will ja nicht, dass ein Ausfall stundenlange Arbeitsunterbrechungen verursacht.

Zusammengefasst ist das Setup gut, wenn man die Motivation und das Interesse hat, sich darum zu kümmern und wenn man wirklich davon profitiert (z. B. wegen Datensicherheit oder spezieller Workflows). Für reine „Komfortuser“ ohne große IT-Ambitionen könnte es zu kompliziert sein.

Fazit

Das diskutierte System kann für ein kleineres Architekturbüro oder Einzelpersonen, die Wert auf Unabhängigkeit und digitale Souveränität legen, tatsächlich gut funktionieren und spannend sein. Man sollte aber nicht vergessen, dass man für die Pflege und das Verstehen dieser Lösung zumindest ein gewisses Maß an IT-Know-how und Zeit braucht. Wer damit kein Problem hat oder sich weiterentwickeln will, findet hier eine innovative Möglichkeit. Wer am liebsten einen PC einschaltet und einfach nur Archicad starten möchte, ohne sich um Betriebssystemdetails zu kümmern, wird möglicherweise weniger Freude daran haben.

---

[Frank Beister]

Jan, ich hoffe, dass du mich nicht falsch verstanden hast. Das war keine Kritik an deinem Beitrag oder sollte etwas schlecht reden. Vielen Dank für das umfangreiche Teilen Deines Wissens.

Dieses Forum (und es ist eben kein blog) lebt aber vom kontroversen und konstruktiven Austausch. V.a. aber von den Erfahrungsberichten der Anwender. Und ich fände es als Leser hilfreich auch andere Meinungen dazu zu hören und ich finde da sind sehr bedenkenswerte Beiträge dabei.

Ich habe nicht wie Torben Anmerkungen zu der verwendeten Technik, dennoch sind meine Anmerkungen nicht von theoretischer Natur. Ich bin vielleicht nicht mehr ganz auf dem Level, aber das Arbeiten auf der Konsole und das Aufsetzen von Systemen, auch Linux, sind mir nicht fremd. Ich kann also die notwendige Technikaffinität einschätzen. Ich kenne auf der anderen Seite auch kleinere und mittlere Büros (in denen ich auch den Systemadmin gemacht habe) von innen und habe aktuell mit vielen verschiedenen Büros verschiedener Größe zu tun. Und ich sehe was mit unter dort mit deutlich kleineren Aufgaben der Digitalisierung gekämpft wird.