QEMU IO performance
Mam dotaz ohledne QEMU IO vykonu, primo ve vps dostavam pri nasledujicim testu time dd if=/dev/zero of=/test oflag=direct bs=64k count=16000 nasledujici vysledek 16000+0 records in 16000+0 records out 1048576000 bytes (1.0 GB, 1000 MiB) copied, 4.11019 s, 255 MB/s real 0m4.112s user 0m0.012s sys 0m0.720s Nicmene kdyz to pustim v QEMU na disku typu raw, dostanu 16000+0 records in 16000+0 records out 1048576000 bytes (1.0 GB, 1000 MiB) copied, 13.6918 s, 76.6 MB/s real 0m4.112s user 0m0.012s sys 0m0.720s QEMU spoustim takto: qemu-system-x86_64 -cpu host -cdrom archlinux-2016.04.01-dual.iso -drive file=test,format=raw,cache=writeback -boot order=d -m 1024M -enable-kvm Disk je naformatovan primo uvnitr QEMU na ext4. Vykon je tedy vyrazne mensi nez primo ve VPS. Je to maximum, jak blizko se jde dostat? Nebo mam nekde chybu v tom, jak to pouzivam? Diky za pomoc, T. -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.
Cau, proc nepouzivas libvirt? Nejsem si jistej, ale tipoval bych, ze pokud nezminis typ toho storage, tak default bude neco safe, cemu kazdej OS rozumi, ie. urcite to nebude virtio. Tim padem nechavas QEMU emulovat realnej hardware a to je uber pomaly. Pouzij libvirt, klikni si jako storage virtio (btw, sitovku taky) a pak to zkus znova. QEMU bez libvirtu - jakkoliv libvirt nemam rad - nedava moc smyslu, leda ze by se ti chtelo ucit vsechny specifika QEMU a vsechny jeho prepinace. Pak ale stejne narazis na veci, co nevyresis - jako je live zmena konfigurace, nebo hloupy poslani ACPI shutdown signalu do virtualu pro proper vypnuti; QEMU na to ma fancy TCP socket s JSON protokolem, to myslim ani silenec nebude psat znova, kdyz uz to libvirt umi. /snajpa On 04/04/2016 01:11 AM, Wolf wrote:
Mam dotaz ohledne QEMU IO vykonu,
primo ve vps dostavam pri nasledujicim testu
time dd if=/dev/zero of=/test oflag=direct bs=64k count=16000
nasledujici vysledek
16000+0 records in 16000+0 records out 1048576000 bytes (1.0 GB, 1000 MiB) copied, 4.11019 s, 255 MB/s
real 0m4.112s user 0m0.012s sys 0m0.720s
Nicmene kdyz to pustim v QEMU na disku typu raw, dostanu
16000+0 records in 16000+0 records out 1048576000 bytes (1.0 GB, 1000 MiB) copied, 13.6918 s, 76.6 MB/s
real 0m4.112s user 0m0.012s sys 0m0.720s
QEMU spoustim takto:
qemu-system-x86_64 -cpu host -cdrom archlinux-2016.04.01-dual.iso -drive file=test,format=raw,cache=writeback -boot order=d -m 1024M -enable-kvm
Disk je naformatovan primo uvnitr QEMU na ext4.
Vykon je tedy vyrazne mensi nez primo ve VPS. Je to maximum, jak blizko se jde dostat? Nebo mam nekde chybu v tom, jak to pouzivam?
Diky za pomoc, T.
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
On , Pavel Snajdr wrote:
proc nepouzivas libvirt?
Protoze jsem o ni nevedel :) Do ted byl vrchol me virtualizace windows ve virtualboxu, takze se porad ucim. Nicmene kdyz se ji snazim zprovoznit, tak mi to nefunguje. 2016-04-03 23:49:50.624+0000: 1955: info : libvirt version: 1.3.1, package: 2 (Guido Günther <agx@sigxcpu.org> Fri, 19 Feb 2016 17:29:27 +0100) 2016-04-03 23:49:50.624+0000: 1955: info : hostname: wolfsden 2016-04-03 23:49:50.624+0000: 1955: error : udevGetDMIData:1578 : Failed to get udev device for syspath '/sys/devices/virtual/dmi/id' or '/sys/class/dmi/id' 2016-04-03 23:49:50.627+0000: 1955: error : udevEnumerateDevices:1456 : udev scan devices returned -2 2016-04-03 23:49:50.627+0000: 1955: error : virStateInitialize:783 : Initialization of udev state driver failed: Unknown problem 2016-04-03 23:49:50.627+0000: 1955: error : daemonRunStateInit:950 : Driver state initialization failed Zkousel jsem hledat co by mohlo byt pricinou, ale nenasel jsem nic jak to opravit. Zname na to nejaky workaround? Nebo mam proste moc novou/starou/spatnou verzi? T. -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.
Cau, jeste krome samotnyho pouzivani libvirtu je spousta dalsich doporuceni: 1. pouzit pro disky virtio-blk nebo virtio-scsi 2. pokud je pouzit pro ulozeni obrazu disku soubor ve filesystemu, zapnout iothreads. Pokud block-device tak native io. 3. pouzit virtio pro sitovou kartu 4. pokud nepredpokladas veci jako live migrace, nepouzivat abstrakci CPU (cpu mode passthru) 5. na COW filesystemech (coz je pripad i ZFS na vpsfree) bych se asi vyhnul pouzivani nekterejch formatu virtualniho disku jako jsou qcow, qcow2, qed, atd. Idealne by tam mel bejt raw file (klidne jako sparsed file) 6. uvnitr openvz a nad ZFS bych asi uplne vypnul cachovani disku No a pak si samozrejme muzes zacit hrat s velikosti bloku zarizeni, atd... -- Stanislav Petr glux@glux.org
4. 4. 2016 v 1:18, Pavel Snajdr <snajpa@snajpa.net>:
Cau,
proc nepouzivas libvirt?
Nejsem si jistej, ale tipoval bych, ze pokud nezminis typ toho storage, tak default bude neco safe, cemu kazdej OS rozumi, ie. urcite to nebude virtio. Tim padem nechavas QEMU emulovat realnej hardware a to je uber pomaly.
Pouzij libvirt, klikni si jako storage virtio (btw, sitovku taky) a pak to zkus znova.
QEMU bez libvirtu - jakkoliv libvirt nemam rad - nedava moc smyslu, leda ze by se ti chtelo ucit vsechny specifika QEMU a vsechny jeho prepinace. Pak ale stejne narazis na veci, co nevyresis - jako je live zmena konfigurace, nebo hloupy poslani ACPI shutdown signalu do virtualu pro proper vypnuti; QEMU na to ma fancy TCP socket s JSON protokolem, to myslim ani silenec nebude psat znova, kdyz uz to libvirt umi.
/snajpa
On 04/04/2016 01:11 AM, Wolf wrote:
Mam dotaz ohledne QEMU IO vykonu,
primo ve vps dostavam pri nasledujicim testu
time dd if=/dev/zero of=/test oflag=direct bs=64k count=16000
nasledujici vysledek
16000+0 records in 16000+0 records out 1048576000 bytes (1.0 GB, 1000 MiB) copied, 4.11019 s, 255 MB/s
real 0m4.112s user 0m0.012s sys 0m0.720s
Nicmene kdyz to pustim v QEMU na disku typu raw, dostanu
16000+0 records in 16000+0 records out 1048576000 bytes (1.0 GB, 1000 MiB) copied, 13.6918 s, 76.6 MB/s
real 0m4.112s user 0m0.012s sys 0m0.720s
QEMU spoustim takto:
qemu-system-x86_64 -cpu host -cdrom archlinux-2016.04.01-dual.iso -drive file=test,format=raw,cache=writeback -boot order=d -m 1024M -enable-kvm
Disk je naformatovan primo uvnitr QEMU na ext4.
Vykon je tedy vyrazne mensi nez primo ve VPS. Je to maximum, jak blizko se jde dostat? Nebo mam nekde chybu v tom, jak to pouzivam?
Diky za pomoc, T.
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Ahoj, podarilo sa ti kvm rozbehat pod ubuntu distrom na vpsfree, ci pouzivas debian ? arty On 4. 4. 2016, at 8:09, Stanislav Petr <glux@glux.org> wrote: Cau, jeste krome samotnyho pouzivani libvirtu je spousta dalsich doporuceni: 1. pouzit pro disky virtio-blk nebo virtio-scsi 2. pokud je pouzit pro ulozeni obrazu disku soubor ve filesystemu, zapnout iothreads. Pokud block-device tak native io. 3. pouzit virtio pro sitovou kartu 4. pokud nepredpokladas veci jako live migrace, nepouzivat abstrakci CPU (cpu mode passthru) 5. na COW filesystemech (coz je pripad i ZFS na vpsfree) bych se asi vyhnul pouzivani nekterejch formatu virtualniho disku jako jsou qcow, qcow2, qed, atd. Idealne by tam mel bejt raw file (klidne jako sparsed file) 6. uvnitr openvz a nad ZFS bych asi uplne vypnul cachovani disku No a pak si samozrejme muzes zacit hrat s velikosti bloku zarizeni, atd... -- Stanislav Petr glux@glux.org
4. 4. 2016 v 1:18, Pavel Snajdr <snajpa@snajpa.net>:
Cau,
proc nepouzivas libvirt?
Nejsem si jistej, ale tipoval bych, ze pokud nezminis typ toho storage, tak default bude neco safe, cemu kazdej OS rozumi, ie. urcite to nebude virtio. Tim padem nechavas QEMU emulovat realnej hardware a to je uber pomaly.
Pouzij libvirt, klikni si jako storage virtio (btw, sitovku taky) a pak to zkus znova.
QEMU bez libvirtu - jakkoliv libvirt nemam rad - nedava moc smyslu, leda ze by se ti chtelo ucit vsechny specifika QEMU a vsechny jeho prepinace. Pak ale stejne narazis na veci, co nevyresis - jako je live zmena konfigurace, nebo hloupy poslani ACPI shutdown signalu do virtualu pro proper vypnuti; QEMU na to ma fancy TCP socket s JSON protokolem, to myslim ani silenec nebude psat znova, kdyz uz to libvirt umi.
/snajpa
On 04/04/2016 01:11 AM, Wolf wrote:
Mam dotaz ohledne QEMU IO vykonu,
primo ve vps dostavam pri nasledujicim testu
time dd if=/dev/zero of=/test oflag=direct bs=64k count=16000
nasledujici vysledek
16000+0 records in 16000+0 records out 1048576000 bytes (1.0 GB, 1000 MiB) copied, 4.11019 s, 255 MB/s
real 0m4.112s user 0m0.012s sys 0m0.720s
Nicmene kdyz to pustim v QEMU na disku typu raw, dostanu
16000+0 records in 16000+0 records out 1048576000 bytes (1.0 GB, 1000 MiB) copied, 13.6918 s, 76.6 MB/s
real 0m4.112s user 0m0.012s sys 0m0.720s
QEMU spoustim takto:
qemu-system-x86_64 -cpu host -cdrom archlinux-2016.04.01-dual.iso -drive file=test,format=raw,cache=writeback -boot order=d -m 1024M -enable-kvm
Disk je naformatovan primo uvnitr QEMU na ext4.
Vykon je tedy vyrazne mensi nez primo ve VPS. Je to maximum, jak blizko se jde dostat? Nebo mam nekde chybu v tom, jak to pouzivam?
Diky za pomoc, T.
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Ahoj, On , Tomas Meszaros wrote:
podarilo sa ti kvm rozbehat pod ubuntu distrom na vpsfree, ci pouzivas debian ?
debian pouzivam, testing. KVM + qemu jsem rozchodil, libvirt zatim ne, s tim blbnu dale. W. -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.
participants (4)
-
Pavel Snajdr -
Stanislav Petr -
Tomas Meszaros -
Wolf