QEMU KVM: fstrim ondersteuning

[frapex]

Ik ben bezig een QEMU KVM 1.1.1 server in te richten met als storage een SSD met ext4 als bestandssysteem. De discard optie (fstrim) werkt naar behoren (op zowel Linux 3.4.6 als Linux 3.5.0). Ook "hole punching" werkt bij gebruik van een raw image in combinatie met een /dev/loop device.

Binnen een VM werkt de fstrim / hole punching functionaliteit echter niet. Telkens krijg ik "FITRIM ioctl failed: Operation not supported".

Helaas kan ik geen oplossing vinden voor het probleem, ondanks een langdurige zoektocht. Inmiddels alle mogelijke storage backends geprobeerd (virtio-blk, virtio-scsi, ide, et cetera).

Kan iemand mij in de juiste richting wijzen hoe ik de fstrim ondersteuning in QEMU KVM aan de praat krijg? Het is de bedoeling dat fstrim in een live omgeving mogelijk is. Het offline uitvoeren van fstrim op een VM image is geen optie.

[matthijsln]

Als je de ssd op een aparte controller hebt dan waar je host schijven opstaat zou je pci passthrough kunnen doen (lijkt mij het makkelijkst), anders misschien het volgende pull request proberen:
http://osdir.com/ml/qemu-devel/2012-06/thrd5.html#03652 ("qemu-ga: add guest-fstrim command") ?

[frapex]

matthijsln schreef op maandag 30 juli 2012 @ 12:39:
Als je de ssd op een aparte controller hebt dan waar je host schijven opstaat zou je pci passthrough kunnen doen (lijkt mij het makkelijkst), anders misschien het volgende pull request proberen:
http://osdir.com/ml/qemu-devel/2012-06/thrd5.html#03652 ("qemu-ga: add guest-fstrim command") ?

pci passthrough werkt niet met mijn processor (geen VT-d ondersteuning).
qemu-ga is de guest agent. Deze kan je starten op een guest zodat je op afstand het trim commando kan afvuren. Niet wat ik zoek dus

Ik ben nu de git versie van qemu aan het compileren. Ik laat wel even weten of fstrim dan opeens wel werkt met deze versie. Wel vreemd als fstrim nu opeens wel gaat werken. Ik zag al fstrim patches voorbij komen uit 2010.

Update: FITRIM / fstrim / discard werkt nog steeds niet met de GIT pull van vandaag

[ Voor 13% gewijzigd door frapex op 30-07-2012 13:47 ]

[DutchNutcase]

Als ik heel eerlijk ben denk ik niet dat het gaat werken, omdat QEMU/KVM geen controle neemt over je schijf, maar gebruik maakt van een virtuele schijf, die op je SSD staat. Dus je host houdt controle over de hardware en een TRIM commando moet dan ook vanuit je host OS gegeven worden.

Ik kan dit natuurlijk verkeerd hebben gezien, omdat ik zelf (nog) niet werk met SSD's en dan word ik graag gecorrigeerd.

[matthijsln]

Inderdaad, qemu moet het trim commando ontvangen van de guest, dit vertalen om 'hole punching' te doen in het bestand waarin de virtuele schijf staat, wat het bestandssysteem dan ook weer moet ondersteunen. In al deze stappen kan er wat mis gaan of iets niet ondersteund worden...

[frapex]

De hole-punching functionaliteit zit sinds enige tijd ook in de loop driver. Dan krijg je dus dit idee:
1) truncate -s1G /mnt/ssd/image.raw
2) losetup -f /mnt/ssd/image.raw
3) mount -o discard /mnt/loop0 /mnt/image
4) hele /mnt/image vullen
5) hele /mnt/image weer schoonmaken

(bron: http://www.outflux.net/bl...d-hole-punching-and-trim/)


Resultaat van bovenstaande is dat de image file /mnt/ssd/image.raw weer net zo klein is als voor het vullen.

Maar helaas, als ik de QEMU VM laat verwijzen naar het /dev/loop0 device komen de TRIM acties niet door. Als je google-ed op trim support voor QEMU dan zit het er als het goed is al een tijdje in. Maar vind maar eens die tutorial die beschrijft hoe je een werkende setup kan maken. Die is er niet... (of toch wel, wie vind 'em? )

Als workaround gebruik ik nu tijdelijk VirtFS (9 Project). Een soort van NFS, maar dan sneller. Moet ik nog wel even de performance problemen oplossen: 120MB/sec lezen (140% cpu usage met 2 cores), 20MB/sec schrijven.

Referenties:
(*) http://www.h-online.com/o...-Xen-support-1321663.html ("QEMU's IDE emulation now supports ATA trim, which allows the system to inform storage media of newly available memory areas")
(*) http://comments.gmane.org/gmane.comp.emulators.qemu/155448 ("FITRIM is a mounted filesystem feature to discard (or "trim") blocks which are not in use by the filesystem. This is useful for solid-state drives (SSDs) and thinly-provisioned storage. Provide access to the feature from the host so that filesystems can be trimmed periodically or before migration")


(Ik was even uit de lucht vandaar mijn late reactie)

[ Voor 21% gewijzigd door frapex op 01-08-2012 22:25 ]

[frapex]

Ik heb het probleem zelfstandig opgelost. Zelfs de experts in de qemu irc chat wisten niet wat er fout was. Na een lange zoektocht ben ik er achtergekomen dat er een property "discard_granularity" bestaat. Deze property kan gezet worden met bijvoorbeeld de "-global" optie. De discard_granularity heeft alleen effect bij de ide, scsi en virtio-scsi block devices (dus de overige virtio devices niet).

Hoe vind je de juiste property:
1) ga naar de qemu_monitor (CTRL-ALT-2)
2) voer uit: info qtree
3) zoek het device waarvoor je discard wilt activeren. Voorbeelden:
* ide-hd.discard_granularity=512
* scsi-disk.discard_granularity=512
* scsi-hd.discard_granularity=512
4) zet nu de property in de command line (bijvoorbeeld):

code:

-global ide-hd.discard_granularity=512

Op deze wijze activeer je de discard functionaliteit. Helaas wordt je backing file hierdoor niet kleiner (het zogenaamde hole punching). Wil je ook een dynamische image, dan moet je een ISCSI target opzetten met thin provisioning (tgtd, recente versie).

code: /etc/tgt/conf.d/mytarget.conf

<target iqn.2012-08.net.tweakers:mytarget>
        <backing-store /srv/tgt/mytarget.img>
                params thin_provisioning=1
        </backing-store>
</target>