Mmh, da hätte ich wohl 2 Ansätze.

1. VM erstellen, passtrough von der nvme auf die VM und als bootlaufwerk setzen. -> laufwerk wäre weiterhin in einem pc nutzbar

2. komplette nvme in ein virtuelles image konvertieren, mit disk2vhd z.B. -> laufwerk nur noch als vm nutzbar

noVNC kann in der tat keinen sound, gibt zwar einige Bastllösungen via api, websocks und ESound. Alles nicht wirklich brauchbar oder sinnvoll in meinen Augen. Wenns ne Windows 10 VM ist, was würde gegen RDP sprechen oder z.B. Anydesk (wäre auch für mac möglich)?

Für den zugriff auf eine Windows VM ist der hauseigene remote desktop der unkomplizierteste und einfachste.

Thema vGPU ist ein wenig umfangreicher, auch was die Hardware angeht.

Ganz einfach und kurz gesagt, beim pass through gibst du der VM die Grafikarte exklusiv weiter. Beim einem vGPU Konstruckt, gibst du Resourcen der Grafikkarte weiter, die aber in der VM als vollwertige Grafikkarte erkannt, behandelt und genutzt werden kann. Das wäre so ne ganz oberflächliche, stark vereinfachte Erklärung.

Die Grafikkarten werden werden zur vm weitergegeben (pass through), somit kann die vm auf eine vollwertige Grafikkarte zurückgreifen. Heist allerdings auch, das du nur eine Grafikkarte gleichzeitig mit einer laufenden vm nutzen kannst. Wenn du sagen wir 2 VM´s hast, aber nur eine Grafikkarte, kannst du zwar für beide vm einen pass through machen, es können aber nicht beide gleichzeitig laufen. Wenn deine VM´s jeweils dedizierte Grafikkarten nutzen sollen, musst pro vm eine Grafikkarte einbauen oder nutzt halt eine Virtualisierung, die vGPU unterstützt.

die github issue #379 zu heimdall hast probiert bzw. ist dir bekannt?

Falls nicht, guggst du hier:

https://github.com/linuxserver/Heimdall/issues/379

Wie schon gesagt, bei NDI kannst du die Netzwerkschnittstelle nicht auswählen. Die OBS NDI output settings sind Bestandteil der NDI-Tools und denen ist es erstmal herzlich egal, welchen Netzwerkadapter du im OBS auswählst.

Du könntest das ganze aber z.B. via application Firewall lösen oder du baust dir ein vlan samt routing.

Aber mal so ganz am Rande, wieviele NDI streams möchtest du den gleichzeitig fahren, das du eine 10Gb Karte brauchst? Wenn´s nur ein stream ist, reicht selbst bei 8k/60 die 1Gb. Allgemein, wenn du mehrere streams gleichzeitig fahren möchtest, lass die Finger von irgendwelchen Bastelösungen, da ist ein Tricaster die deutlich bessere wahl.

Dabei handelt es sich in der Tat um einen Fehler. Module mit E haben eine ECC Korrektur.

Wird´s vermutlich nicht verhindern aber Warn App.

Star Trek TOS oder TNG

Bevor ich mir die Finger wundtippe, guggst du hier:

https://www.bladeloop.com/2019…unbuffered-registerd-ram/

Edit: Ganz vergessen, ja du bräuchtest unbufferd oder ein anderes board.

Ok, wenn du von Hyper-V umgezogen bist, hast du die virtio netzwerktreiber in deinen VM´s gepackt? Wäre jetzt mal so meine idee.

ECC ja, registered nicht. Und da es sich bei deinem RAM um ecc registered handelt, wäre das schon mal ein Ansatz.

Kurze Version, nein. Du kannst den Netzwerkadapter nicht auswählen.

Falls das ganze mehr ein lokales Bastelprojekt sein sollte, versuche es mit mkcert, das wäre genau für diese Anwendung gedacht.

How-to mkcert

Ist für Ubuntu und nginx, bei anderen Konstellationen muss das natürlich angepasst werden.

Aber so ganz allgemein würde mich interessieren, wie du den certbot auf dem nextcloud docker installiert hast. Also webroot, standalone, manual, etc. und welchen webserver du auf dem docker hast und wie dieser konfiguriert ist. Denn die ganzen Probleme die du schilderst, sind echt ziemlich ungewöhnlich.

Wenn das Zertifikat auf einem anderen System erstellt wurde, macht das durchaus Sinn.

Der Nextcloud Webserver wurde aber neugestartet?

Mir ergründet sich aktuell aber nicht so ganz, warum es nicht möglich ist, auf dem nextcloud docker via certbot ein zertifikat zu erstellen. Wenn das ganze im manuellen modus nicht funktioniert, ist da grundsätzlich was im argen. Hier würde ich ggf. das System überdenken oder auf rapid oder trust wildcards wechseln.

Dann versuch das ganze mal im manuellen modus, wenn das auch nicht funktionieren sollte, mmh.

certbot certonly -a manual -d subdomain.hauptdomain.de

danach muss der domainbesitz mit 2 dateien bestätig werden.

Ok, ich glaube ich weiß wo das hinführt. Du hast das Zertifikat über Cloudfire eingerichtet oder über den certbot? wenn ersteres der fall sein sollte, kannst du keine subdomain mit zertifikat versehen, zumindest nicht mit letsencrypt, außer es gibt da inzwischen ne automatisirte wildcard option von den hostern..

Wenn zweiteres der fall ist, geht folgendes:

Subdomain ist auf dem Selben physikalischen Server, mit der selben IP und certbot ist installiert dann das:

certbot -d beispiel.de,neuesubdomain.beispiel.de,www.beispiel.de --expand

Subdomain ist auf dem selben physikalischen server oder auf einem anderen und hat eine andere IP, dann das:

certbot certonly --authenticator standalone -d subdomain.hauptdomain.de

Fangen wir mal vorne an.

Die virtualisierungsoption deiner cpu hast du im Bios eingeschaltet?

Jetzt bin ich etwas verwirrt. Wie sprichst du deine Nextcloud den an, wenn deine Domain auf den gui geroutet ist?

Aber so grundsätzlich unter linux, egal ob unraid, docker oder was auch immer. Das Zertifikat out off the box ist erstmal nur für das, was du anlegst, also in der Regel für die Hauptdomain, einmal mit und ohne www.

Kommt jetzt ein Subdomain hinzu, muss die a) in den configs des Webservers eingetragen werden und b) zusätzlich ins Zertifikat aufgenommen werden.

In deinem Fall ist der Nextcloud Docker ja mehr oder weniger ein standalone Server, also müsstest du ihn auch als solchen behandeln. Heißt, Subdomain im DNS erstellen, auf den docker routen und da dann ein reguläres neues zertifikat mit der subdomain erstellen. (So wie du es auch mit der gui gemacht hast) Dann sollte das ganze eigentlich funktionieren.

Was bekommst du den für Fehlermeldungen? Normalerweise fügst du neue subdomains via expand hinzu, also z.B. so:

certbot -d beispiel.de,neuesubdomain.beispiel.de,www.beispiel.de --expand

Danach wie gehabt, die verifizierungsdateien erstellen und gut. Oder läuft dein Nexctcloud docker nicht auf einer eigenen Subdomain?

Ganz ok, allerdings was die Qualität der Schraubendreher und Steckschlüssel angeht, kann iFixit noch nicht mal ansatzweise mit z.B. Wiha oder Reca mithalten. Ich für meinen Teil bevorzuge lieber qualitativ hochwertiges Werkzeug.

Was den Controller angeht, ja ist die erste Version.

ECC geht zwar unter X570, aber ganz ehrlich, hat meiner Meinung nach nix in ner Consumer Plattform zu suchen. Und wenn es ECC benötigt wird, reden wir eh von anderen Plattformen. Was das board angeht, es gibt auch boards mit 8 SATA ports, dann kannst du auf den Controller verzichten. Wenn du unbedingt einen richtigen Hardware RAID aufbauen möchtest, kauf dir lieber eine aktuelle Karte, sonst reicht der onboard Software RAID der Mainboards.

Das Geld für den Shadow Rock, kannst du dir eigentlich auch schenken. Bei nem 4HE Gehäuse sollte der boxed Kühler wohl passen und von der Lautstärke und Kühlleistung ist der mehr als Ausreichend. (Sofern die CPU stock bleibt)

Ggf. würde ich noch den Arbeitsspeicher erhöhen bei den aktuellen Preisen, sofern du ihn brauchen kannst.

Der Chipsatz ansich spielt eher eine untergeordnete Rolle. Die Frage ist halt, wie sieht das nächste upgrade auf, nur CPU oder wieder CPU und board? Wenn nur CPU, würde ich ggf. auf einen 500er chipsatz gehen. Wenn beim nächsten mal beides ausgetauscht wird oder wir von 2-3 Jahren+ bis zum nächsten upgrade reden, ist es eigentlich ziemlich egal, dann muss es nur den jetzigen Bedürfnissen entsprechen.