Hello,
I played around with raw images now.
Megasas is not supported by libvirt. The default controller crashs
during installation while accessing to disk.
qemu-system-x86_64:
/build/qemu-j0uSxv/qemu-1.7.0+dfsg/hw/scsi/lsi53c895a.c:541:
lsi_do_dma: Assertion `s->current' failed.
So I took Debian Testing (Jessie with kernel 3.12) to use virtio-scsi
over following options.
-device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x4 \
-drive
file=/home/vm/trim.raw,if=none,id=drive-scsi0-0-0-0,format=raw,discard=unmap
\
-device
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=2
Result of this: fstrim works.
Take a look into lsblk -D: DISC-ZERO=0? I read DISC-ZERO has to be "1"
to propagate discard.
Switch back to my thin volume vm. DISC-ZERO=0 and fstrim works! Booting
from old kernel 3.2 - works too.
LVM recognize the increasing of thin volume after discard.
Conclusion of my issues:
Did I understand something wrong?
Yes!
Discard granularity (DISC-GRAN) of lsblk -D is the important number. It
must not be "0B".
I did so much the last weeks. Maybe the error of fstrim occurs before
getting thin volumes work.
Thanks a lot for your help (and hint to try it with an image)!
Bye Markus
Am 07.02.2014 17:36, schrieb Michael Tokarev:
07.02.2014 04:03, Paolo Bonzini wrote:
Michael, can you look at this?
Paolo
-------- Messaggio originale --------
From: chickenmarkus@xxxxxxxxxx
To: kvm@xxxxxxxxxxxxxxx
Hello,
after reading the "invitation" for some one-off questions without
subscribing excuse my disturbing, please.
At first my setup of host:
* in general Debian Wheezy
* Kernel: 3.11-0.bpo.2-amd64
(http://packages.debian.org/wheezy-backports/linux-image-3.11-0.bpo.2-amd64)
* LVM 2.02.98 (http://packages.debian.org/jessie/lvm2)
* thin-provisioning-tools 0.2.8-1
(http://packages.debian.org/jessie/thin-provisioning-tools)
* Qemu-KVM: 1.7.0 (http://packages.debian.org/jessie/qemu-kvm)
The new kernel and dirty things from Jessie are for working thin volumes
with discard on my ssd. Everything's fine up to this point.
Afterwards I start a guest (also Debian Wheezy) over the following
command (over libvirt) as root (for test only):
kvm [...] -drive
file=/dev/ssd0/sarabi,if=none,id=drive-scsi0-0-0-0,format=raw,discard=unmap -device
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=2
[...]
Neither lsblk -D nor the try of fstrim ends positive. Both say that
discard is not supported.
I read that guests need at least kernel 3.4 to support discard (and
virtio-scsi). But the same backports kernel 3.11 did not changed anything.
This is the first time I tried to deal with discard. I've no discard-capable
hardware, so never bothered to even look how it works (or not).
I fired up my sample linux guest here, using 3.10 kernel on host and 3.2 kernel
on guest, using something similar to what your command looks like:
-device megasas,id=scsi0 \
-drive file=test.raw,if=none,id=sd0,discard=unmap \
-device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=sd0
Note: this is a plain file (test.raw) on an ext4 filesystem on a device
without discard support (regular rotational hard drive).
In the guest, I can see discard granularity (4K) for that drive in lsblk -D
output.
fstrim does not error out, but I don't know if it actually does something or
not.
The same result can be observed with 3.10 kernel in guest, and with other
scsi devices/drivers (eg lsi53c895a).
However, when I export the same test.raw file using virtio, like this:
-drive file=test.raw,if=virtio,discard=unmap
it doesn't work: guest does not see the virtio drive as discardable.
Did I understand something wrong? Is the command wrong? Are any
requirements not met?
So I've no idea what's going on here... ;)
Thanks,
/mjt
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
