hawihoney

Was muss ich mir darunter vorstellen? Ist das eine Art Screensaver? Wenn ja, dann würde ich das auf einem Serverboard, wenn es denn eins ist, abschalten. Dieser Java Kram hat bei mir unter IPMI noch nie funktioniert. Ich werde immer mit einem Java-Update begrüßt, die eingeblendete Konsole funktioniert nicht, deshalb nutze ich nur die Power-Seite der Webseite (Power On, etc.) Alles andere über SSH.

Bei einer Unraid VM ist das anders. Host Unraid sowie Guest Unraid haben in den Einstellungen den Router eingetragen. Das Problem hat auch nur begrenzt mit NTP zu tun, da TSC ein Counter ist. Übrigens gibt es für Windows andere clock Einstellungen. Über die bin ich heute gestolpert. localtime statt utc und diverse andere. Der gemeinsame Nenner bei dem Ganzen ist, dass innerhalb einer VM die Timer drastisch abweichen können und das hat dann unterschiedliche Auswirkungen je nach Guest. Beim Einen ist es die falsche Uhrzeit, bei mir sorgt der Ersatz-Counter für eine Performance-Reduzierung um satte 75%. Wäre schön wenn das Problem etwas abgemildert werden könnte - wie auch immer.

Im Moment kann ich meine VMs nicht neu starten, da ein disk-rebuild läuft. Da will ich nicht reingrätschen. Ich habe aber Folgendes vor: 1.) Ich werde auf Host Seite in allen VM Konfigurationen in der <clock> section diesen zusätzlichen Timer aufnehmen: <timer name='tsc' tickpolicy='catchup' mode='auto'/> 2.) Wenn die VMs damit starten werde ich sie mal eine Zeit lang laufen lassen und prüfen ob der Fehler wieder auftritt. 3a.) Sollte der Fehler nochmals auftreten, werde ich auf dem Host in der Flash Konfiguration (syslinux) evtl. mal "tsc=reliable" hinzufügen. Wie bereits geschrieben weiß ich nicht ob Unraid diesen Kernel Parameter überhaupt unterstützt und ob das nicht doch negative Nebenwirkungen hat. 3b.) Als dämlichen Test könnte ich auch auf dem Host und allen VMs ein User Script einrichten, dass alle 5 Minuten ntptime ausführt. Keine Ahnung ob das hilft ... Unabhängig davon habe ich aber mal im VM Forum nachgefragt wie es sein kann, dass in einer VM ein Timer läuft, der überhaupt nicht in der Konfiguration aufgeführt ist (TSC). Ich erwarte dort keine Erklärung die uns weiter bringt da es doch sehr speziell ist. Als langer (2008), treuer (6 Pro Lizenzen) Unraid Kunde werde ich dann mal den Chef per Mail kontaktieren. Evtl. kann er uns ja weiter helfen. Nachtrag: Die beiden Befehle aus Deinem vorherigen Post laufen bei mir ins Leere.

So, if writing to a data disk, that's currently being reconstructed, Unraid will calculate the bits with the help of all other data disks and the parity disks, writes to all parity disks and writes to the reconstructed data disk? Sounds reasonable. Thanks.

First shutdown your VM. You can edit VMs if they are stopped only. In your screenshot I don't see the Primary VDisk. It's not set. Set that first. Now click on the + symbol behind the first Vdisk to add a second Disk. Now decide what you want to archive. Do you want to passthrough the complete disk or the partition only? If you don't need the disk in the host passthrough the complete disk. You have to enter the complete path for this disk then - e.g. /dev/disk/by-id/ata-xyz without the trailing "-partx". Within this disk section choose virtio as driver. It's possible to choose SATA, but that's up to you. I'm using Virtio because I had problems with SATA passthrough of complete disks. I had to add a <serial> parameter to get this working. Just test it with the default. If you switch to XML view of this VMs configuration, you will see two <disk> blocks then. One for the Vdisk and one for the passed through disk. It looks something like the following. Just start with the configuration the GUI sets and leave the difference to mine out: # This is the VDisk <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/mnt/cache/domains/VM/vdisk1.img' index='1'/> <backingStore/> <target dev='hdc' bus='virtio'/> <boot order='1'/> <alias name='virtio-disk1'/> <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/> </disk> # This is the passed through disk <disk type='block' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source dev='/dev/disk/by-id/ata-WDC_WD6003FFBX-68MU3N0_V8GDLSNR' index='2'/> <backingStore/> <target dev='hdd' bus='virtio'/> <serial>V8GDLSNR</serial> <alias name='virtio-disk2'/> <address type='pci' domain='0x0000' bus='0x06' slot='0x00' function='0x0'/> </disk>

How does this work? There's currently a data disk rebuild running. Let's call it disk1. Now I do write to disk1. What happens? There's a high potential that's there not even a valid filesystem on that disk at the time of writing. My understanding is, that this new data becomes written to all other data disks and the parity disks instead. Ok, for now. But what happens after the disk rebuild is finished. The data is not on that disk. Is there something like a transaction buffer that becomes applied afterwards? I'm possibly totally blind, but this puzzles me since some time.

The default configuration for the Slackware VM does include the following <clock> definition: <clock offset='utc'> <timer name='rtc' tickpolicy='catchup'/> <timer name='pit' tickpolicy='delay'/> <timer name='hpet' present='no'/> </clock> Running a slackware (Unraid) VM I see the "tsc" and "acpi_pm" timers running instead. As I'm always experiencing timer problems with "tsc" how can I work around that? Should I add "tsc" to the <clock> element? Here's the error I see in a Unraid VM. Whenever this happens, performance of the VM degrades by 3/4: May 4 02:10:40 TowerVM01 kernel: clocksource: timekeeping watchdog on CPU2: Marking clocksource 'tsc' as unstable because the skew is too large: May 4 02:10:40 TowerVM01 kernel: clocksource: 'acpi_pm' wd_now: 70aa1c wd_last: 51d1b1 mask: ffffff May 4 02:10:40 TowerVM01 kernel: clocksource: 'tsc' cs_now: 5b65e65f2fb54 cs_last: 5b65e12de6c58 mask: ffffffffffffffff May 4 02:10:40 TowerVM01 kernel: tsc: Marking TSC unstable due to clocksource watchdog May 4 02:10:40 TowerVM01 kernel: clocksource: Switched to clocksource acpi_pm Question #1: Why is a timer running in my VMs that is not declared in the VM configuration? Question #2: Would it possibly help to add an additional "tsc" timer to the <clock>? <timer name='tsc' tickpolicy='catchup' mode='auto'/> Thanks in advance.

Vergangene Nacht ist etwas passiert, was in den letzten zwei Jahren, seit ich mit der aktuellen Anzahl von VMs arbeite, noch nie passiert ist. Eine zweite VM meldete den selben Fehler und schaltete zurück. Es ist wie verhext. Ich schreibe hier meine Theory und in der folgenden Nacht wird sie ad absurdum geführt. Arrggghhhh! Die libvirt Seite hatte ich schon in meinem Lesezeichen Allerdings beim erneuten Lesen fiel mir heute morgen auf, dass der "tsc" timer, der in meinen Unraid VMs zunächst läuft, überhaupt nicht in der </clock> Konfiguration aufgeführt ist. Es stehen in unseren Konfigurationen drei timer, von denen aber keiner bei mir läuft. Bei mir laufen zunächst "tsc" und später, nach dem Fehler, wird auf "acpi_pm" zurückgeschaltet. Vielleicht sollte ich spaßeshalber den "tsc" in der VM Konfiguration aufführen ... <timer name='tsc' tickpolicy='catchup' mode='auto'/>

Das scheint wohl Standard zu sein. Hier meine VM Konfiguration zur Clock: <clock offset='utc'> <timer name='rtc' tickpolicy='catchup'/> <timer name='pit' tickpolicy='delay'/> <timer name='hpet' present='no'/> </clock> Ich bin mir sehr sicher, dass es ein Fehler im KVM, o.ä. ist, aber das kann ich nicht beweisen. Meine VMs sind Unraid VMs - geclont aus dem Bare-Metal Unraid. Mehrere Unraid VMs laufen auf Unraid: 1.) Das Bare-Metal Unraid hat nie ein Problem mit der Clock. 2.) Es ist immer nur die erste gestartete VM die dieses Problem bekommt. Die als zweite oder dritte gestartete VM hat das Problem nie. Wenn ich die VMs in umgekehrter Reihenfolge starte, ist es wieder die erste gestartete VM die das Problem bekommt. 3.) Das Problem nennt immer einen Core, der abweicht, aber es ist immer ein anderer Core. Ich habe VMs schon anderen CPUs oder anderen Cores zugewiesen. Es bleibt immer bei 2.) Der Fehler in der betroffenen Unraid VM lautet dann: May 4 02:10:40 TowerVM01 kernel: clocksource: timekeeping watchdog on CPU2: Marking clocksource 'tsc' as unstable because the skew is too large: May 4 02:10:40 TowerVM01 kernel: clocksource: 'acpi_pm' wd_now: 70aa1c wd_last: 51d1b1 mask: ffffff May 4 02:10:40 TowerVM01 kernel: clocksource: 'tsc' cs_now: 5b65e65f2fb54 cs_last: 5b65e12de6c58 mask: ffffffffffffffff May 4 02:10:40 TowerVM01 kernel: tsc: Marking TSC unstable due to clocksource watchdog May 4 02:10:40 TowerVM01 kernel: clocksource: Switched to clocksource acpi_pm Dazu muss man wissen, dass diese Clock für das Handling im Multithreading benötigt wird, kann sich Linux nicht auf eine saubere Synchronisaion verlassen, dann schaltet es einen Gang runter. In meinem Fall wird um 3/4 runtergeschaltet. Ein laufender 60 MB/s Parity Sync knallt von einer Sekunde auf die andere auf 15 MB/s runter. Im Moment ist VM01 die leidtragende. Angeblich kann man in der syslinux der VMs die folgenden Kernel-Parameter eintragen: clocksource=tsc tsc=reliable Ich habe aber bis zum heutigen Tag nicht herausgefunden ob Unraid diese Parameter unterstützt und habe mich nicht getraut sie zu verwenden. Statt dessen starte ich eine Dummy VM als erstes und dann erst die produktiven VMs.

YES! Seit einiger Zeit kämpfe ich damit, dass meine VMs kurz nach dem Start die Clocksource wegen abweichender Zeit wechseln und die Performance auf 1/4 fällt. Nichts hat geholfen bisher: Wechsel der zugewiesenen Cores (bei 2 CPUs, 20 Cores, 40 Threads) etc. irgendein Cores meldete immer als einziger die Abweichung. Bisher nicht getraut habe ich mich die Abschaltung bzw. die Vertrauensstellung des Zeitgebers zu markieren. Das geht angeblich über die syslinux. Ich glaube nicht, dass es mit NTP zu tun hat. Bei mir trat das erst durch den Wechsel auf die 6.9.x Versionen auf, was mich eher an den 5er Kernel denken lässt. Hast Du die Möglichkeit in Deiner VM System Log nach dem Text Clocksource zu durchsuchen.

For Docker we "have" it already (Container XML configuration files stored on flash). Why not for VMs as well (VM XML configuration files stored on flash)? IMHO a system should act identical wherever possible. It makes it better for users to understand. This change does not make Backup/Restore obsolet. Backup of appdata (Docker Container) and vdisk images (VMs) is still neccessary. But it helps to recreate Container/VMs or create Container/VMs based on existing Containers/VMs.

Currently the docker container configuration files are saved to the following location on the flash disk: /boot/config/plugins/dockerMan/templates-user/ With these stored container configuration files I can recreate a docker container, and it's previously configured options, even without the docker.img file: Page "Docker" > "Add container" > "Select a template" > "User templates" This does not work the same way with VMs. Here's my feature request: 1.) Add a new folder: /boot/config/plugins/dynamix.kvm.manager/templates-user/ 2.) Store the XML configuration files of all VMs into that folder with "virsh dumpxml <VM name>". 3.) At the top of the "Add VM" page, add a dropdown list like that from the "Add container". Populate the dropdown list with the stored VM configuration names (see above). Put a label "Template:" in front of the dropdown list, put the header "User templates" above the list of names of the stored VM configuration files. 4.) After the user selected an entry from the dropdown list, the Create/Edit window should be shown in XML view. This view will contain the previously stored XML of the VM. With these stored VM configuration files I can recreate a VM, and it's previously configured options, even without the libvirt.img file. However, the domain image files (e.g. vdisk1.img) are needed as well. But these files are all I need to backup, and I can backup these files savely without shutting down the docker/KVM subsystem. To backup docker.img, libvirt.img I need to shutdown both subsystems as well. With this additional feature, it's no longer required. Thanks for listening.

1.) Docker Container kannst Du wunderbar sichern, sobald Du den jeweiligen Container gestoppt hast. 2.) VMs (Domains) kannst Du wunderbar sichern, sobald Du die jeweiligen VM heruntergefahren hast. 3.) docker.img (bzw. docker-xfs.img, bzw. docker/) und libvirt.img sind die Verwaltungsdateien (ich nenne sie mal so) der beiden Subsysteme. Die kannst Du zwar einfach kopieren, besser ist aber eine Sicherung nachdem Du die Subsysteme selbst heruntergefahren hast. Aber wer macht das schon? 4.) Die Konfigurationsdaten der Docker Container liegen auf dem Flash. Wundert mich, dass die Container-Settings bei Dir nicht mehr vorhanden waren. Sobald Du auf Add klickst, kannst Du oben die gespeicherten User Docker Container auswählen. Hier liegen die Container Konfigurationsdateien. Mit diesen kann es Dir eigentlich egal sein, ob die docker.img et. al. Datei existiert: /boot/config/plugins/dockerMan/templates-user Nachtrag 5.) Solange Du die VM images noch besitzt verhält es sich bei der libvirt.img ähnlich. Die kann man jederzeit wieder aufbauen lassen. Also wichtig: Die Container Konfigurationsdateien auf dem Flash (s.o.) sowie die appdata Sicherung der jeweiligen Container helfen Dir jederzeit das Docker System wieder aufzubauen. Gleiches bei den VMs: Die <DeinVMName>/vdisk1.img Dateien und die VM XML Konfigurationsdaten (virsh dumpxml <DeinVMName>) zusammen helfen Dir das VM System wieder aufzubauen. CA Backup/Restore nutze ich nicht.

Wenn Du die Platte nur in der WIndows VM nutzen willst gibt es zwei Möglichkeiten: 1.) In Unraid auf der Konsole mit "wipefs". 2.) Im Admin CMD der Windows VM mit der Hilfe von "diskpart" (list disk, select disk x, list partition, select partition x, delete partition, clean disk, ...). Guck Dir den korrekten Ablauf lieber vorher im Web an. Achtung: Beides löscht die Platte komplett. Bei 1.) lieber doppelt und dreifach prüfen ob die korrekte /dev/sdX gelöscht wird.

Schade, viel Glück bei Deiner weiteren Suche.

Das ist mir letztens beim Stöbern über den Weg gelaufen:

OMG, I need to move to your country. Triple that for Germany.

Ich meine das ganz normale Unraid Array. In den oben gezeigten drei Gehäusen läuft ein Unraid Server mit zwei Unraid VMs, insgesamt drei Unraid Arrays. Ein LSI 9300-8i HBA, drei mit Expander bestückte Supermicro BPN-SAS2-EL1 Backplanes. Benötigt werden insgesamt drei Unraid Lizenzen und drei USB-Sticks. Die Platten sind derzeit individuell an die VMs durchgereicht. Für normale Dateioperationen ist das ok. Parity Check/Rebuld ist allerdings ca. 25% langsamer als mit durchgereichten HBAs pro VM. Dafür würde man dann aber auch zwei weitere Steckplätze fur HBAs benötigen. Auf dem Host erzeugt das Durchreichen individueller Festplatten hohe IOWAiTs durch die QEMU Emulationsschicht bei Parity Check/Rebuild. Ich kann damit leben. Bei solchen Systemen gilt es die Vorteile/Nachteile abzuwägen. Die bewertet jeder anders. Shares löse ich array-übergreifend mit eigenen Mount/Unmount Skripten im User Scripts plugin. Diese Installtion läuft seit 2019 mehr oder weniger fehlerfrei.

Nur zum Verständnis: Du hast ein Gehäuse (oder mehrere) in denen mehr als 30 (28+2) Festplatten angesteuert werden könnten? Also zum Beispiel 2x 30 Festplatten (2x 28+2)? Dazu gibt es tatsächlich eine Lösung die bei mir seit Jahren hervorragend funktioniert. Unraid läuft problemlos in einer VM die wiederum auf Unraid läuft. Die Vorteile: Du könntest mehrere (jeweils bis zu 28+2) Arrays in einem Server betreiben. Du nutzt die in meinen Augen absolut stabile Unraid Array Technik und keine noch (wiederum meiner Meinung nach) experimentellen BTRFS Features. Wenn alles glatt läuft kannst Du diese zusätzlichen Unraid Arrays aus den VMs weiternutzen sobald multiple Arrays in Unraid implementiert wurden. Die Festplatten können individuell "passed-through" werden oder, was performance-technik besser ist, an zusätzlichen HBAs durchgereicht werden. Beides habe ich in den vergangenen Jahren schon produktiv genutzt. Die Nachteile (wenn man in diesen Dimensionen überhaupt von Nachteil spricht): Du benötigst pro Unraid Array in einer VM eine weitere Unraid Lizenz sowie einen weiteren USB-Stick. Die Einrichtung ist relativ simpel. Das Ganze geht natürlich nicht nur in einem Gehäuse sondern auch über mehrere Gehäuse hinweg. Im Bild ist ein einzelner Unraid Server zu sehen:

--> Array --> Pool Kenne mich damit nicht aus. Würde einen zweiten Pool verwenden. Da Du aber nur zwei NVMe's besitzt würden beide Pools nur jeweils aus einem Device bestehen. Die wären dann aber ungesichert. Wenn beides hingegen auf einem Pool läuft könnten sie sich gegenseitig behindern.

After looking at Github and the Main page again I see what's the problem: In english the header is called Reads/Writes for both displays (Toogle reads/writes display). So it seems there is only one translation possible for both displays. @ich777 Please forget my change request I wrote here. Sorry about that.

Ich habe gerade im deutschen Forum einen Screenshot der Main Page in Deutsch gesehen. Auf dem Screenshot war die Einstellung der Schreibrate zu sehen. Also 0 B/s und nicht die Summe der Lese-/Schreibaktivitäten. Die Header hierzu lauten "Gelesen" bzw. "Geschrieben" was meines Erachtens nicht korrekt ist. Gelesen/Geschrieben passt zur anderen Darstellung mit den Summen, aber nicht zur aktuellen Schreib-/Leseaktivität. Meiner Meinung nach müssten die Header z.B. "Leserate" bzw. "Schreibrate" lauten, oder? Alternativ "Lesen" und "Schreiben".

Ich mochte die nicht alle als jeweilige Root-Ordner/-Shares neben meinen eigenen. Einen - system - kann ich akzeptieren. Im Übrigen gibt es alte Videos in denen das von anderen ebenfalls so abgewandelt genutzt wird - die haben mich inspiriert.

Meinem eigenen Verständnis nach ist nicht alles appdata - deswegen habe ich das bei mir leicht abgeändert. Apps bekomme ich über den tab Apps system/appdata/nextcloud/config ist der config Ordner von Nextcloud, das ist klar appdata system/appdata/nextcloud/data ist der data Ordner von Nextcloud, das ist klar appdata system/docker/docker.img bzw. system/docker/ ist m.V.n. nicht appdata system/VM/libvirt.img ist m.V.n. ebenfalls kein appdata system/domains/VM01/VM01.img - über das habe ich mit mir selbst gerungen. Könnte auch unter system/VM. Treu nach dem Motto: Think big. Evtl splitte ich das alles später mal auf mehrere Pools. Meine Struktur gibt das auf jeden Fall her.