Ich habe einen 32-Bit-Windows 2k3r3-Gast (Terminalserver) mit 4 GB Gast-RAM und Swapping.
Ich habe ein separates Disk-Image für den Gast-Swapping und die temporären Verzeichnisse der Benutzer erstellt.
Ich habe genügend RAM im Hostsystem und möchte Festplatten-E/A sparen, indem ich dieses Image nach tmpfs verschiebe, aber der Gast startet nicht mit dieser Fehlermeldung:
qemu-kvm: -drive file=/mnt/tmpfs/vh1-tmp.qcow2,if=none,id=drive-ide0-1-1,format=qcow2,cache=none: Disk-Imag konnte nicht geöffnet werden│ 4098 qemu 20 0 4949M 4146M 5496 S 28.5 17.2 1h00:31 /usr/bin/qemu-kvm -name vh1 -S -M pc-1.3 -cpu kvm64 -enable- e /mnt/tmpfs/vh1-tmp.qcow2: Ungültiges Argument
Host-System:
#uname -a
Linux srv-vh1.su.local 3.7.10-1.16-default #1 SMP Freitag, 31. Mai 2013, 20:21:23 UTC x86_64 x86_64 x86_64 GNU/Linux
srv-vh1:/mnt/tmpfs # virsh-Version
Kompiliert mit der Bibliothek: libvirt 1.0.2
Verwendete Bibliothek: libvirt 1.0.2
API verwenden: QEMU 1.0.2
Ausführender Hypervisor: QEMU 1.3.0
srv-vh1:/mnt/tmpfs # frei
insgesamt genutzte freie gemeinsam genutzte Puffer im Cache
Speicher: 24627548 5084724 19542824 0 60640 138792
-/+ Puffer/Cache: 4885292 19742256
Tausch: 8384444 0 8384444
srv-vh1:/mnt/tmpfs # cat /etc/mtab | grep tmpfs
devtmpfs /dev devtmpfs rw, Relatime, Größe = 12296608k, Nr. Inodes = 3074152, Modus = 755 0 0
tmpfs /dev/shm tmpfs rw,relative Zeit 0 0
tmpfs /run tmpfs rw,nosuid,nodev,relatime,mode=755 0 0
tmpfs /sys/fs/cgroup tmpfs rw,nosuid,nodev,noexec,mode=755 0 0
tmpfs /mnt/tmpfs tmpfs rw,relative Zeit 0 0
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
tmpfs /tmp tmpfs rw,relative Zeit 0 0
tmpfs /var/lock tmpfs rw,nosuid,nodev,relatime,mode=755 0 0
tmpfs /var/run tmpfs rw,nosuid,nodev,relatime,mode=755 0 0
srv-vh1:/mnt/tmpfs # df
Dateisystem 1K-Blöcke verwendet Verfügbar Verwendet% Einhängepunkt
devtmpfs 12296608 68 12296540 1% /Entwickler
tmpfs 12313772 0 12313772 0% /dev/shm
tmpfs 12313772 6772 12307000 1 % /Lauf
/dev/md1 454131992 218835836 212227596 51% /
tmpfs 12313772 0 12313772 0% /sys/fs/cgroup
tmpfs 12313772 192 12313580 1% /mnt/tmpfs
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
tmpfs 12313772 20 12313752 1% /tmp
tmpfs 12313772 6772 12307000 1% /var/Sperre
tmpfs 12313772 6772 12307000 1 % /var/Lauf
srv-vh1:/mnt/tmpfs # virsh pool-info tmpfs
Name: tmpfs
UUID: 6287028a-9faf-f762-20de-d36d63657be3
Status: in Arbeit
Persistent: ja
Autostart: ja
Kapazität: 11,74 GiB
Anzahl der Teilnehmer: 0,00
Verfügbar: 11,74 GiB
srv-vh1:/mnt/tmpfs # ls -la
insgesamt 196
drwxrwxrwt 2 root root 60. Sept. 9, 11:42 .
drwxrwxr-x 4 qemu qemu 4096 8. Sept. 19:39 ..
-rw-rw-rw- 1 root root 197120 9. Sept. 11:42 tserver-tmp.qcow2
Was mache ich falsch ?
Antwort1
Wenn Sie cache=NONE für eine Disk-Image-Datei auf einem Host-Dateisystem festlegen, das Direct IO nicht unterstützt, gibt Virt-Manager derzeit anscheinend eine nicht sehr hilfreiche Fehlermeldung aus, die besagt: „Irgendwas, irgendwas ... Ungültiges Argument“ und weigert sich, die Gast-VM zu starten.
Ein Beispiel für ein solches Dateisystem, das Direct IO nicht unterstützt, ist tmpfs. Ein anderes Dateisystem, bei dem Sie Direct IO optional deaktivieren können, ist GlusterFS (von dem ich noch nie gehört hatte, bevor ich auf dasselbe Problem wie Sergei stieß und den Fehler untersuchte). Bei tmpfs scheint die fehlende Unterstützung von Direct IO derzeit eine technische Einschränkung oder ein Designkonflikt zu sein, und ich weiß nicht, ob dies in Zukunft behoben werden kann/wird.
In meinem Fall hatte ich eine 3,6 GB große Ramdisk für eine Win7Pro-Gast-VM unter CentOS7 eingerichtet und im Virt-Manager cache=NONE für die Ramdisk eingestellt. Die anderen Optionen, die das tmpfs-img verwendete, waren virtio und raw. Die VM weigerte sich, mit demselben/ähnlichen Fehler zu starten, der besagte: „... Ungültiges Argument“.
Technische Einzelheiten und Anmerkungen direkt vom Redhat-Ingenieur und -Entwickler, der den Patch für die Funktion cache=NONE codiert und Virt-Manager (Daniel Berrange) verwaltet (?), finden Sie in der Diskussion unter dem folgenden Link:
https://bugs.launchpad.net/nova/+bug/959637
Um Daniel von der URL oben zu zitieren: " > konnte Disk-Image /mnt/vmstore/instances/instance-0000001a/disk nicht öffnen: Ungültiges Argument
bedeutet wahrscheinlich, dass das Dateisystem kein Direct IO unterstützt. Soweit ich weiß, sollten alle Dateisysteme außer tmpfs dies unterstützen.."
Außerdem fährt Daniel fort: „- Was wir dann also tun wollen, ist, [....] zu prüfen, ob das Speichervolumen Direct IO unterstützt. Wenn ja, verwenden Sie cache=none, andernfalls greifen Sie auf cache=writethrough zurück, das kein Direct I/O verwendet, aber dennoch absturzsicher ist.“
In meinem Fall konnte ich überprüfen, dass die Einstellung cache=NONE für die tmpfs-img-Datei die VM NICHT startete und den Fehler wie besprochen anzeigte. Die VM konnte erfolgreich gestartet werden, wenn der Cache entweder auf „Standard“ oder explizit auf „Write-through“ eingestellt war. „Write-back“ macht keinen Sinn, da dieses Dateisystem sowohl entbehrlich ist als auch sich sowieso vollständig im RAM befand, also habe ich Write-back offensichtlich nicht verwendet.
Hoffentlich hilft das!
Antwort2
Warum geben Sie dem Gast nicht einfach mehr RAM, sodass er nicht tauschen muss?
srv-vh1:/mnt/tmpfs # ls -la
total 196
drwxrwxrwt 2 root root 60 сен 9 11:42 .
drwxrwxr-x 4 qemu qemu 4096 сен 8 19:39 ..
-rw-rw-rw- 1 root root 197120 сен 9 11:42 tserver-tmp.qcow2
Ich stelle fest, dass Sie den Ordnerbesitzer auf qemu:qemu eingestellt haben. Wenn Sie qemu als anderer Benutzer ausführen, möchten Sie möglicherweise den Besitzer der Image-Datei von root auf qemu ändern.
Antwort3
Es ist ein Fehler. tmpfs unterstützt dies nicht cache=none.