Beiträge von GIT

/doArchive/ ist ein Ordner auf der /vms-Freigabe wo die HDD1 enthalten ist.

Mod: Nicht deklariertes Zitat ohne Quellenangabe ... korrigiert! Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen

Zitat von Xydoc

Das Problem besteht mit VS4 Beta?

Kann ich dir nicht sagen, ich bin zwangsgeupdated worden.

Also der Freigabeordner /vms hat 1.88 TB belegt von 3 TB ingesamt. Aber die anzeigte Größe der HDD hat mit der img-Datei und dessen Auslegung zu tun. HDD2 und HDD3 sind zusätzliche Festplatten.

Mod: Nicht deklariertes Zitat ohne Quellenangabe ... korrigiert! Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen

Zitat von Becker2020

Wenn Du HDD1 nicht vergrößern kannst, kannst Du denn den Freigabeordner /vms vergrößern ?

sehe /vms anhand der freien 1.12 TB kein Problem.

Mod: Nicht deklariertes Zitat ohne Quellenangabe ... korrigiert! Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen

Zitat von Becker2020

Wenn auch dies nicht zum Erfolg führt, würde ich mich an den QNAP-Support wenden.

Ich kann dir aus Erfahrung sagen, dass ist wirklich das letzte, was du tun möchtest. Ein QNAP-Servicemitarbeiter versucht dann über den lokalen QNAP Helpdesk eine SSH/-Webinterface-Freigabe zu erwirken. Diese Freigabe soll dann aber auch 24/7 geöffnet sein (Firewall), damit die taiwanischen Techniker in einer Nacht (Zeitzonenverschiebung) dann im Prinzip alles auf deinem System machen können.

Der letzte Fall ging so über 3 Monate, der beste Service ist der, den du nicht benötigst

Solange die Snapshots vorhanden sind, lässt er keine Vergrößerung zu. Henne-Ei-Problem.

Mod: Zitat ohne Quellenangabe ... korrigiert! Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen

Zitat von Becker2020

Ich würde mal einen Neustart des NAS durchführen.

Seit gestern Abend, drei Stück. Keine positive Auswirkung auf den eigentlichen Prozess.

Im QuLog-Center findest du absolut nichts.

Hier das Bild was ich heute morgen gesehen habe:

pasted-from-clipboard.png

Zitat

Was ist mit der HDD1 ?

108 GB belegt aber die HDD ist nur 80 GB groß

Ich denke das kommt dadurch, dass hier HDD1 + dessen Snapshot 1 und Snapshot 2 addiert werden.

pasted-from-clipboard.png

Das Bild könnte dir weiterhelfen.

Es bringt jedoch nichts, in hatte die NAS die ganze Nacht wirklich auf Minimalbetrieb und habe nur den Prozess laufen lassen, es funktioniert nicht. Ich bekomme die Snapshots nicht gelöscht. Heute morgen war dann sogar die ganze VS aus bzw. hat nur bei Aufruf ERROR geschriehen.

Da die VM noch funktioniert, werde ich jetzt eine neue Identische VM aufsetzen lassen und die Inhalte "kopieren".

Danach gibt es absolutes Verbot bei uns diese Snapshot-Funktion zu nutzen; es gab damit nur Ärger. Zukünftig VM herunterfahren, IMG-Datei kopieren/backupen, verschlüsseln. Ende.

Beispielsweise bei Hetzner, welche für Ihre VPS ebenfalls auf qemu setzen, hatte ich solche Probleme noch nie.

Das ist die Info zur .img-Datei

SSH-Befehl: qemu-img info /share/doArchive-Data/doArchive-Data-HDD.img

image: /share/doArchive-Data/doArchive-Data-HDD.img
file format: qcow2
virtual size: 4.72 TiB (5188320493568 bytes)
disk size: 507 GiB
cluster_size: 65536
Format specific information:
    compat: 1.1
    compression type: zlib
    lazy refcounts: false
    refcount bits: 16
    corrupt: false
    extended l2: false

Mod: Nicht deklariertes Zitat ohne Quellenangabe ... korrigiert! Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen

Zitat von Becker2020

Du nutzt QuTS Hero ?

Ja, auf der TS-h1277XU-RP.

Zitat von Becker2020

Freigabe ist nur 0,5 TB groß ?

Nein, 5 TB.

Es ist überall noch massig Platz.

1.02 TB von 5.00 TB belegt

daran kann es "leider" auch nicht liegen.

Hab jetzt für heute Abend/Nacht geplant, alles herunterzufahren und rein dieses Prozess zu starten. Vorher noch aktuelles QuTS Hero und dann mal schauen.

Redest du von dem Volumen wo die Image-Dateien liegen oder der .img-Datei selbst?

image: /share/doArchive-Data/doArchive-Data-HDD.img
file format: qcow2
virtual size: 4.72 TiB (5188320493568 bytes)
disk size: 507 GiB
cluster_size: 65536
Format specific information:
compat: 1.1
compression type: zlib
lazy refcounts: false
refcount bits: 16
corrupt: false
extended l2: false

der /share/doArchive-Data/ - 1.02 TB von 5.00 TB belegt

Hallo in die Runde,

ich habe versucht einen Snapshot zu löschen, aber dieser Prozess zeigt im Webinterface dauerhaft 0% an (auch nach 12 Stunden). Laufen tut aktuell leider Version 4.0.0.219 (20230726).

Ich bin jetzt schon soweit, das ich den qemu-img decommit per ssh gestartet habe, aber auch hier passiert auf Dateiebene irgendwie nichts.

/usr/bin/qemu-img decommit -b /share/doArchive-Data/doArchive-Data-HDD.img -c /share/doArchive-Data/doArchive-Data-HDD.1699918204 --backup /share/doArchive-Data/.doArchive-Data-HDD.img.bk

Habe mittlerweile sogar den -p Parameter mit dran, dort kommt zumindest eine Prozentangabe (8.00/100%). Diese verändert sich aber nur sehr sehr sehr träge. Hab dem Prozess schon per renice die höchste Prio verliehen und auch per taskset alle CPUs erlaubt.

Die --backup /share/doArchive-Data/.doArchive-Data-HDD.img.bk - Datei wurde beim Start geschrieben und hat stolze 267 KB. Seitdem Funkstille.

/share/doArchive-Data/doArchive-Data-HDD.img ist 1.055 GB groß und die doArchive-Data-HDD.1699918204 nur 267 KB.

Hat jemand irgendeine Idee? Und was genau macht er dort und vor allem was da so lange dauert?

Nach nun fast zwei Monaten Austausch mit den QNAP Support in Taiwan, hab ich die Lösung für mein Problem.

Damit man Remotebackups (und auch die Ansicht der Remoteordner) wieder anständig nutzen kann, müssen auf allen NAS-Systemen die irgendwie damit zu tun haben, also zumindest local und remote, die QVS_4.0.0.219 oder neuer installiert sein. Zusätzlich müssen die Zugangsdaten auf der Remote-NAS von dem jeweiligen User, als auch in der QVS nochmal neu hinterlegt werden.

Danach geht bei mir nun alles, trotzdem habe ich ein mulmiges Gefühl, auf Produktivsystemen eine Beta der QVS einzusetzen. Muss aber auch anmerken, dann ich sonst keine Probleme mit der Beta bemerkt habe.

Also weder zur TS-h1277XU-RP (QuTS hero h5.1.0.2466 Build 20230721) noch zur TVS-682 (QTS 5.1.0.2466 Build 20230721) geht irgendwas. Ordnerauswahl bleibt blank; auch nach Minuten.

Von den anderen beiden (TS-h1277XU-RP und TVS-682) mit VirtualizationStation Version 3.6.41 zur TVS-1282 (QTS 5.1.0.2466 Build 20230721) keine Probleme.

Bleibt wohl nur abwarten.

Ich habe weiterhin das Problem, dass ich keine Verbindungen zu externen Sicherungsplätzen bekomme. Auch beim Anlegen/Editieren im "Datenschutz-Plan" werden mir keine Ordner geladen. Hat jemand ähnliche Probleme?

Ich verstehe auch nicht warum er nach dem Upgrade auf 5.1 bei der TVS-1282 einfach die Public Beta der Virtualization Station eigenständig installiert hat. Bei den anderen Systemen hat er das nicht gemacht. Ein Downgrade verweigert er leider. Und Beta-Teilname ist für die Hauptfirmware auch nicht aktiviert.

Guten Morgen zusammen,

Mod: Unnötiges Volltext-/Direktzitat entfernt! Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen

spannenderweise hatte ich genau den gleichen Plan und zwar den E-POSTSCAN für Geschäftskunden per SFTP abzurufen. Möglich wäre hier sogar das SSH Public-Key-Authentifizierung.

Die App HybridMount kann Moints über SFTP einbinden, aber diese kann ich mit HBS leider nicht abgreifen/nutzen. Eventuell hier mal einen Feature-Request einreichen? Ich würde ungern am vorbei System/Oberfläche irgendwas einrichten.

Hallo in die Runde,

ich hatte eben die TVS-682 auf die 5.0.0.1808(20211001) aktualisiert und jetzt kann ich in VirtualizationStation 3 Version 3.5.57 (2021-04-29) die VMs nicht mehr starten. Also ich würde vorerst raten, die Finger bei Produktivssystemen davon zu lassen.

Zusätzlich hängt sich meiner Meinung nach auch das "System" zumindest die Weboberfläche auf und ist ausgelastet.

War auch kurz per SSH auf der QNAP eingeloggt, nach der Suche nach ein paar Logs und öffnen von /share/CACHEDEV1_DATA friert mir sogar die SSH-Verbindung ein.

Die CPU-Auslastung liegt dabei immer bei 0.9% also ich bin gerade mehr als begeistert

Bin zurück auf die TS-X82_20210923-4.5.4.1800, ging ohne Probleme nachdem ich den SSD-Cache vorab deaktiviert habe.

TS-h1277XU-RP

1x 10 Gbps Adapter - 192.168.0.80 - standardgateway

1x 1 Gbps Adapter - 192.168.0.81 - failover

TVS-1282

1x 10 Gbps Adapter - 192.168.0.70 - standardgateway

1x 1 Gbps Adapter - 192.168.0.71 - failover

TVS-682

1x 10 Gbps Adapter - 192.168.0.100 - standardgateway

1x 1 Gbps Adapter - 192.168.0.101 - failover

Nein, drei verschiedene NAS-Systeme

192.168.0.80 - TS-h1277XU-RP

192.168.0.70 - TVS-1282

192.168.0.100 - TVS-682

jeweils mit immer mindestens 1x 10 Gbps Adapter und 1x 1 Gbps Adapter

dem ist so

sieht wie folgt aus:

192.168.0.80

192.168.0.90

192.168.0.100

Was verstehst du unter Netzwerksegment? Alle drei NAS-Systeme befinden sich im gleichen Klasse C-Netz und sind über 10 Gbps-Switche angebunden bzw. verbunden.

Hallo in die Runde,

die Virtualization Station stoppt beim Mounten eines verschlüsselten Freigabeordners und versetzt die VMs in den "Halte"-Status.

Hat jemand eine Idee wieso das so ist und ob man das irgendwie umgehen kann? Die Software als auch die VMs liegen auf einem ganz anderen Speicherpool, aber kommt es dazu.