Beiträge von knebb

    Moin,


    ja, das mit der "Ersatzleitung" war so auch gedacht. Aber naja, dann geht es halt auch ohne....


    Hatte jetzt einen zweiten Switch gebaut und ihm auch eine IP aus dem gleichen NEtzwerk gegeben. Dummerweise scheint der SMB-Domain-Controller damit nicht so super klar zu kommen. Die Clients veruchten teilweise auf diese zweite Adresse zuzugreifen und sind gescheitert. Habe das jetzt nicht weiter geprüft, musste schnell handeln- der zweite Switch hat jetzt keine IP mehr :\


    Du hast schon recht, das der wenige Traffic die 10er Leitung kaum belastet. Aber an der 10er Leitung hängt ein Mac dran, der als Server fungiert- und der braucht "eigentlich" Thunderbold. Da ist die 10er schon etwas "langssam" ;) Und deshalb allen Traffic, der nicht gebraucht wird, einfach auf den zweiten Switch legen, apsst.


    /KNEBB

    Moin,


    ja, aus reiner PErformanz-Sicht ist es am besten, nur die 10er zu verwenden.... aber dann habe ich keien Ausfallsicherheit. Naja, wenn die 10er mal ausfällt ist sowieso Land unter, da bringen die beiden kleinen dann auch nix mehr.


    Ihr habt recht, ich lasse nur die eine 10er dran. Und baue einen zweiten Switch mit einer zweiten IP, der dann die "kleinen, unwichtigen Clients" versorgt ;)


    BTW: Jau, nutze auch OPNSense ;)


    /KNEBB

    Moin,


    ich habe eine TS473A (2x2,5Gbit NIC) mit einer zusätzlichen 10Gbit QNAP-NIC. Die NICs funktionieren soweit wunderbar.

    Es ist ein virtueller Switch konfiguriert, mit einer fixen IP-Adresse.

    Es läuft eine VM in der Virtualization Station, ansonsten reine und direkte SMB-Zugriffe auf die Freigaben.


    Meine Frage ist jetzt, wie ich meine NICs an den Switch am besten konfiguriere?

    Variante 1:

    vSwitch ------ NIC1 2,5Gbit

    |

    | ------ NIC2 2,5GBit

    |

    | ------ NIC3 10Gbit


    Das ist die einfachste Variante. Bzgl. Ausfallsicherheit gehe ich davon aus, wenn eine Verbindung gekappt wird, dass die anderen weiter für Netzwerkfunktionalität gerade stehen, richtig? Aber wie sieht es mit der Performanz aus? Macht der da ein "Round-Robin" und nutzt alle Netzwerkkarten oder bevorzugt er die 10er (was ja Sinn machen würde)?


    Variante2:

    vSwitch ------ Portbündelung LACP. ------ NIC1 2,5Gbit

    | |

    | | ------ NIC2 2,5GBit

    |

    | ------ NIC3 10Gbit


    Wie sieht das jetzt aus bzgl. Geschwindigkeiten/ Ausfallsicherheit?


    Ich habe einen Client, der braucht volle Geschwindigkeit, ich vermute ich kann nur über eine andere IP-Adresse sicherstellen, dass dieser IMMER via 10Gbit zugreift, richtig? Dann habe ich aber keine Ausfallsicherheit :(


    Ach, es ist kompoliziert.... jemand IDeen/ Ergänzungen/ Links zu Dokus?


    /KNEBB

    Hmm... das würde erklären, warum ich auf der einen Kiste die 4.xer drauf hatte.

    Aber nicht, warum ich die aktuelle 3.xer jetzt nicht mehr installieren kann :(


    So, ich bin zwar nicht weiter, kann aber weitere Informationen liefern.

    suche ich das Paket mittels qpkgcli zu installieren finde ich das Folgende in /var/log/log.qpkg (gekürzt. volles log im Anhang):

    Leider keinen konkreten Hinweis, WARUM der Install fehlschlägt.

    Mist!

    Jemand eine Idee?


    /KNEBB


    Hi,


    ich bin jetzt selbst auf die Lösung gekommen und berichte hier, falls es anderen genauso geht.


    Die Installation ist ja immer fehlgeschlagen (auch via qpkg_cli), die Installation von anderen Paketen hat aber problemlos funktioniert. Es konnte also nur ein Problem mit dem Paket sein, nicht mit QuTS hero allgemein.


    Ich habe einen Blick in das Zielverzeichnis geworfen (/share/ZFS530_DATA/.qpkg) und habe dort ein verstecktes Verzeichnis namens .QKVM gefunden. Das ist wohl so eine Art "Backup, dass die Konfigdaten der VirtStation behält, falls man sie wieder installieren will. Dort sind vermutlich auch irgendwelche Versionsnummern gespeichert. Also die v4.x. Und beim Installieren wird geprüft, ob die zu installierende Version (3.x) zu den gesicherten Konfigurationen (v4.x) kompatibel ist. Ist sie natürlich nicht. Deshalb schlägt die Installation fehl.


    Ich habe also das .QKVM-Verzeichnis mal ganz cool woanders hingeschoben und dann erneut installiert. Und siehe da:


    Es funktionierte!


    Mene VirtStation v3.x ist installiert und startet wieder. Allerdings ohne irgendwelche Konfigurationen oder VMs. Aber das ist nicht schlimm, das kriege ich hingefummelt.


    Damit gelöst!


    /KNEBB

    Moin,


    heute ist wohl mein "ich prüfe mein NAS und stelle Probleme fest"-Tag? :/


    Ich wollte gerade auf der Konsole etwas machen, bekomme aber ienen Fehler:


    Code
    [~] # /QVS/usr/bin/qemu-img info hoas.img
    /QVS/usr/bin/qemu-img: error while loading shared libraries: libgnutls.so.30: cannot open shared object file: No such file or directory

    Ich habe das QuTS hero gerade auf die neueste Version aktualisiert (QuTS hero h5.1.3.2578), der Fehler war aber wahrscheinlich schon vorher. Ist mir nur nicht aufgefallen.



    Das Paket selbst ist wohl lokal vorhanden, aber eben nicht installiert:

    Code
    [~] # find / -name libgnutls.so.30
    /share/ZFS530_DATA/.qpkg/QKVM/usr/lib/libgnutls.so.30


    Sonst merke ich auch keinerlei Ausfälle oder Probleme. Nur diese eine Library scheint zu fehlen. Warum auch immer.


    Wie kriege ich die wieder installiert?

    Auf meinem zweiten NAs ist die drauuf und auch der Befehl funktioniert einwandfrei! Allerdingsist dort die 64bit VErsion ionstalliert:

    /share/ZFS530_DATA/.qpkg/QKVM/usr/lib64/libgnutls.so.30



    Danke& Grüße


    /KNEBB


    Moin,


    das lag daran, dass ich die falsche Version von VirtSt installiert bekommen hatte (v4.x vs v3.6). Das war wohl mal ein Fehler bei QNAP. Habe die 4xer runtergeworfen, jetzt meckert er allerdings, dass die eigentlich vorgesehene Version sich nicht installieren läßt wg. Inkompatibilitäten oder so :(

    Siehe dazu auch anderen Thread, hier das kann zugemacht werden.

    Moin,


    ich muss Euch heute nochmal nerven.


    Ich habe zwei identische NAS (TS-473A). Beide sind auf dem gleichen Firmwarestand (QuTS hero 5.1.2578). Unter den Firmwareeinstellungen nehme ich NICHT an dem Beta-Programm teil. Bei beiden Systemen nicht. Das war auch nie aktivert. Sicher nicht!


    Im AppStore sind keine Aktualisierungen verfügbar.


    Aber ich habe dennoch zwei verschiedene Version der VirtStation:


    Ein NAS hat Version 4.0.0.226 (20231013)

    Das zweite hat Version 3.6.52 (2023-09-25)


    Kann mir das einer erklären?


    Warum geht er bei dem zweiten NAS nicht auf v4?


    Danke!


    /KNEBB


    Jetztr habe ich auf dem System, auf dem v4 installiert war, dei VirtStation deinstalliert, um sie neu zu installieren.


    Deinstallation klappte.


    Im AppStore zeigt er mir weiterhin nur v3.x an.


    Versuche ich diese Version zu installieren kriege ich:

    Code
    Fehler	2023-11-18	20:11:02	admin	App Center	App Installation	[App Center] Failed to install Virtualization Station. The installation package is incompatible. Use the compatible package.

    Jo, hier auch unverzichtbar.


    An zwei Standorten (via WireguardVPN) stehen je eine TS-473A. Auf der einen läuft eine Debian12 mit BackupPC zur Datensicherung der anderen Systeme. Diese VM sichert auf ein DRBD-Volume (NetzwerkRAID1), das als "Partner" eine Debian12-VM auf dem zweiten NAS hat. Falls also ein NAS mal abraucht, kann ich mit der anderen immer noch ein Restore machen und habe alle Daten da! JA, theoretisch kann das NAS das auch, aber für solch wichtige Sachen gilt bei mir: KISS! (Keep It Simple and Stupid).

    Zusätzlich läuft auf einer noch HomeAssistant als Hausautomation, auch auf Debian12 Basis.


    Irgendwann muss ich mir mal eine Windows-VM installieren, damit ich diverse Tools (Firmwareupdater etc.) laufen lassen kann, denn sonst gibt es hier nur MacOS und Debian. Bin allerdings nicht bereit, für diese max. zweimalige Nutzung pro Jahr die Gebühren für das Windows zu bezahlen.

    Zur den TS-473A:

    je 2xm.2 SSD als Cache, 4xSSD (bzw. 2xSSD und 2xHDD), 64G RAM.

    Moin!


    Wenn Du mutig bist, mache es so wie ich. Ich hatte ein ähnliches Problem.


    VirtSt 3.x, aber einen Snapshot vergessen- jetzt ca. 580G an Snapshotgröße ;(


    Das "decommit" erstellt wohl nur eine BackupDatei, um irgendwie wieder zurückrollen zu können, wenn etwas schiefgeht (wie das gehen soll, ist mir schleierhaft).

    D.h. er kopiert zuerst den Snapshot, bei müssen dafür 580G frei sein, ich habe aber nur 413G frei. X( Wird also so oder so nie funktionieren.


    Ich mache jetzt einfach ein

    /QVS/usr/bin/qemu-img commit -b vdb.img -d -p vdb.1686556

    Das dauert zwar auch, weil die Konsole bei QTS heror wohl nur geringe Prio hat, aber es geht dennoch voran. (aktuell nach 10Minuten 1%).

    Wenn er damit durch ist, sind alle Daten des Snapshots in das Basis-Image integriert und ich lösche den Snapshot. Danach erstelle ich mit

    /QVS/usr/bin/qemu-img create -b vdb.img -f qcow2 vdb.1686556

    wieder einen neuen Snapshot, damit die VirtSt mit ihrer "Buchhaltung" nicht durcheinander kommt.


    Ist das alles fertig, kann ich den Snapshot via Web-GUI löschen, das geht dann ja fix.


    Hilft dir das?

    Anmerkung: sind alles nur Vermutungen, leider ist der "decommit" Befehl nirgendwo dokumentiert. QEMU scheint mir allgemein sowieso schlecht dokumentiert zu sein :(

    Wie auch immer: Auf eigene Gefahr!


    /KNEBB

    Moin,


    hmmm... wofür braucht man die Versionen, um mir zu erklären, was der "decommit" Befehl macht? Aber sei es drum: Aktuellstes QTS hero, VirtStaation ebenfalls (3.x, nicht beta).


    Und nein, ich habe nicht das gleiche Problem, wie in dem anderen Thread geschildert, den hatte ich gesehen.


    Wenn ich das richtig intergpretiere, macht der "decommit" Befehl nichts anderes, als eine Kopie des Snapshots als Rückfallmöglichkeit zu ertellen (--backup). Das macht die VirtsStation für beide VirtDisks. Ist die VirtStation damit fertig, wird sie vermutlich die Snapshots mittels "commit" auf die Base-Platte einspielen und bei Erfolg die Snapshot-Disk als auch das Backup löschen. Es werden also massiv Daten hin- und hergeschoben. Ist kein Problem bei den üblichen kleinen Snapshots. Hier macht der decommit mit den Backup-Dateien aber 38G+550G= 538G zusätzlichen HDD-Platz "locker". Aktuell sind "nur" 413G frei. Selbst wenn ich es laufen lasse, wird das später schief gehen.


    Deshalb mache ich das jetzt manuell und direkt mittels "commit" und hoffe, dass es funktioniert.


    Gibt es irgend etwas, was ich dabei beachten muss?


    /KNEBB


    So, auch hier wieder eine Lösung.


    Eine , die ich selbst herausgefunden habe.


    Wichtig ist, zu überprüfen, dass man die richtigen Dateien zusammenfügt. Das habe ich mit "info" festgestellt und auf das "backing_file" geachtet. Mit diesem dann den folgenden commit-Befehl gefüttert.

    Wie gesagt habe ich dann einfach den commit-Befehl gestartet:

    /QVS/usr/bin/qemu-img commit -b backuppc42_vdb.img -d -p backuppc42_vdb.1686556047

    Der hat eine schöne Prozentausgabe gemacht und danach hatte ich alle Änderungen des Snapshots im eigenlichen Base-Image.

    Die Snapshot Datei gelöscht:

    rm backuppc42_vdb.1686556047

    Dann nur noch einen neuen (Dummy-) Snapshot erstellt, damit die Buchführung von QuTS nicht durcheinanderkommt. Auf den gleichen Namen setzen, wie die gerade gelöschte Datei! Und auf der Web-GUI dann den Snapshot gelöscht. Fertig.

    /QVS/usr/bin/qemu-img create -b backuppc42_vdb.img -f qcow2 backuppc42_vdb.1686556047

    Schwupps! Alles Snapshots weg und es läuft alles wieder einwandfrei.


    /KNEBB

    Moin,


    ich kämpfe auch gerade mit dem Thema Snapshots. leider hatte ich vor einigen Monaten vergessen, einen Snapshot zu löschen.

    Die VM hat zwei virtuelleDisks (64G und 1.600G), die Snapshots sind mittlerweise 38G und 550G =O


    Lösche ich den Snapshot in der Virtualization Szation steht der Ewigkeiten auf 0%, auch nach Stunden.


    Jetzt hatte ich auf der Konsole nachgeschaut, was die Kiste denn eigentlich macht.

    Der qemu-img Prozess läuft und schreibt die ".bk" Datei solange, bis sie genau groß ist wie die Snapshot-Datei. Und arbeitet dann an vdb.


    /QVS//usr/bin/qemu-img decommit -b /share/VMs/debianvm/debianvm_vda.img -c /share/VMs/debianvm/debianvm_vda.1235549876 --backup /share/VMs/debianvm/debianvm_vda.img.bk


    Jetzt habe ich versucht, Informationen über den Parameter "decommit" zu bekommen, bin aber nirgendwo fündig geworden. Ist das eine Besonderheit des QNap Hero OS :?:


    Nun würde ich gerne die Snapshots manuell einspielen, eigenlich ist ja der "commit" dafür gedacht (nicht "decommit"). Ich denke, den kann ich einfach so einsetzen oder sind da Probleme zu erwarten?


    IDeen?


    /KNEBB

    Mod: :handbuch::arrow: Die Zitat Funktion des Forums richtig nutzen

    Nope. Nix externe Disks. Habe zwischenzeitlich rausgefunden, dass libvirt wohl zwei Snapshot-Typen hat. "extern" und "intern". Mit den externen gibt es wohl so einige Probleme. Siehe hier.. Bleibt die Frage, warum die Virtualization Station "externe" Snapshots anlegt, wenn sie diese nicht mehr löschen kann. Erstellt wurden diese Snapshots alle über Zeitplan, nicht manuell.


    Aber es steht immer noch die Frage im Raum, ob die Snapshots der VM2 denn überhaupt etwas mit dem angeblich vorhandenen Snapshots der VM1 zu tun haben...


    /K

    Ok, gefunden. Aaaaber:


    Es sind also keine Snapshots, die ich löschen könnte.


    Nur die andere VM hat welche:

    Ich hatte erwartet, dass sich das Problem auf der Kommandozeile löst. Sieht aber nicht so aus. Fragen:

    1. Warum kann ich bei der ausgeschalteten VMs die Festplatten nicht vergrößern, obwohl bei dieser kein Snapshot existiert?
    2. Warum finde ich zwei Festplatten im Verzeichnis dieser VM, obwohl kein Snapshot existieren soll?
    3. 3. Warum kann ich bei der anderen VM die Snapshots nicht löschen?

    Danke für Lösungsversuche!


    /K

    Moin,


    ich möchte die Festplatte einer VM erweitern. VM ist ausgeschaltet, ich kriege aber imemr die Info, dass ich zuerst alle Snapshots löschen muss, bevor ich die Platte vergrößere. Nur: In der Übersicht sind keine Snapshots! Ich kann also keine löschen :(


    Schaue ich mir das VM-Verzeichnis auf der Platte an, sieht das so aus:

    Code
    drwxrwxrwx 3 admin administrators 4.0K 2019-05-10 08:46 .35705e55-e7c4-4ca6-974f-60c3d1d024d6.meta/
    -rw-r--r-- 1 admin administrators 1.7T 2019-05-20 07:18 backuppc_1.1557648070
    -rw-r--r-- 1 admin administrators 348M 2019-05-20 07:18 backuppc.1557648070
    -rw-r--r-- 1 admin administrators 1.8T 2019-05-12 10:00 backuppc_1.img
    -rw-r--r-- 1 admin administrators 1.8G 2019-05-12 10:00 backuppc.img

    Da scheint also doch etwas zu existieren, oder? Aber wie kriege ich den Snapshot gelöscht? virsh gibt es hier nicht :(


    Jemand eine Idee? Ohne die ganzen 1.7TB zu kopieren?


    Danke!


    /K

    Hallo,


    musste mein Volume wegen eines Problems neu aufsetzen. Von der Virtualisierung sind die Einträge der VMs noch vorhanden, lediglich der Link zu den Festplatten fehlt. BEi einer der beiden VMs war es kein Problem, ihr wieder ihre Festplatte zu geben.


    Bei der anderen VM kann ich leider garnichts machen :(
    Egal, welche Einstellungen ich vornehmen will (löschen der VM, ändern von Konfigurationen der VM), ich bekomme immer: "Ausführen des Vorgangs bei angehaltener VM fehlgeschlagen (253)". :cursing:
    Ich kann ihr also die richtige Festplatte nicht geben und auch nicht starten oder ausschalten oder löschen. Immer diese Fehlermeldung.


    Wie kann ich die VM (gerne via ssh) komplett de-registrieren?


    Danke!


    /KNEBB

    Hallo Leute,


    ein ganz merkwürdiges Problem, aus dem ich noch nicht wirklich schlauf werde. Meiner Meinung nach ist das entweder ein Bug oder schlichtweg sch.... programmiert.


    Ich habe hier eine 4x2TB RAID5, das 6TB an Speicherplatz bietet. Darauf habe ich einen Spiecherpool gebastelt und darin wiederum ein Thin-Volume. Dem Thin-Volume habe ich die Kapazität des Speicherpools gegeben (brauche nicht mehrere Volumes).


    Nun wuchsen die Daten auf dem Thin Volume etwas an, hatte aber immer noch ca. 1TB freien Platz.


    Offenbar hat QOS nun aber das Thin Volume auf max erweitert, so das im Speicherpool nichts mehr frei ist (genauer: 16GB noch frei). Das Bild sieht also so aus:
    qnap1.png


    Und jetzt meckert QOS rum, dass der Speicherpool voll sei und die Snapshotfunktionalität beeinträchtig sein könnte und verweigert den Schreibzugriff auf das Volume! Als Status steht "Lesen/ Löschen" und in der Shell sagt er "Read only Filesystem".


    Das ist doch Schwachsinn! ich brauche die Funktionalität von Snapshots nicht und habe auch keinen angelegt. Es sind noch 1TB an Platz verfügbar, aber er sagt, dass das Volume schreibgeschützt sein muss?


    Bin irgendwie stinksauer über so einen Mist... :cursing::cursing:
    Denke ich falsch? Hat jemand eine Idee, was das soll oder wie ich es ohne Zurücksetzen wieder hin bekomme? Oder wie ich das Teil konfigurieren kann, dass ich problemlos meinen verfügbaren Platz auch nutzen kann?


    Daaaanke!

    Hallo,


    die von mir gefundene Doku zeigt mir keinen Weg. Ich vermute deshalb, dass es nicht geht. Dennoch die Frage in die Runde:


    Unterstützt der virtuelle Switch (bei mir derzeit in 4.3.3) die Möglichkeit, mit VLANs nach 802.1q zu arbeiten? Und damit meine ich nicht nur, dass die IP-Adresse ein VLAN-Tag bekommt, sondern man auch den virtuellen Maschinen virtuelle Netzwerke zuweisen kann, die dann entsprechend getaggt über einen externen Switch korrekt zugeordnet werden können.


    /KNEBB

    Damn! :cursing:


    Ja, ich hatte SMB mit Samba verwechselt. Und da steht immer nur was von Version 3.x. Und mit Samba 3.x geht kein AD- deshalb war ich der irrigen Annahme, das sei veraltet!


    Sorry! :whistling:

    Hallo Leute,


    den Artikel "Fall(e) SMB" habe ich gelesen. Leider ist er nicht mehr ganz aktuell- wie viele andere Postingszu dem Theme.


    Deshalb kurze Frage:
    Auf meinem QNAP TS-451 läuft die aktuelle Firmware (4.3.3), als Samba 4:

    Code
    [~] # smb2status
    
    
    smbd (samba daemon) Version 4.0.25
    smbd (samba daemon) is running.
    max protocol SMB 2.1 enabled.


    Derzeit nutze ich einen virtualisierten Univention UCS als DC, der auch die restlichen Aufgaben (Freigabe, DHCP, DNS) übernimmt. Aber grundsätzlich kann das QNAP ja auch. Nur bei der AD-Funktionalität bin ich mir nicht sicher.
    So habe ich es z.B. nicht hinbekommen, die QNAP als Member-Server am UCS-DC einzubinden.


    Also, gibt es Erfahrungen (hier insbesondere Zuverlässigkeit!) einen QNAP als AD einzusetzen?


    Danke!


    /KNEBB