Hi Paolo,
Am 10.08.2012 14:39, schrieb Paolo Bonzini:
Il 10/08/2012 14:35, Stefan Priebe - Profihost AG ha scritto:
One way to activate passthough is via scsi-generic:
Example:
-device lsi -device scsi-generic,drive=MyISCSI \
-drive file=iscsi://10.1.1.125/iqn.ronnie.
Il 10/08/2012 14:35, Stefan Priebe - Profihost AG ha scritto:
>>
>> One way to activate passthough is via scsi-generic:
>> Example:
>> -device lsi -device scsi-generic,drive=MyISCSI \
>> -drive file=iscsi://10.1.1.125/iqn.ronnie.test/1,if=none,id=MyI
>
> When i do this the g
never used this tool. Output is:
This looks like this:
# sg_unmap --lba=0x1000 --num=1 /dev/sde
# sg_get_lba_status --lba=0x1000 /dev/sde
get LBA status: transport: Host_status=0x10 is invalid
Driver_status=0x08 [DRIVER_SENSE, SUGGEST_OK]
Get LBA Status command failed
try '-v' option for mo
Am 10.08.2012 14:24, schrieb ronnie sahlberg:
On Fri, Aug 10, 2012 at 10:14 PM, Stefan Priebe - Profihost AG
wrote:
I dont know the kvm version numbers.
They're the same as qemu.
But you can check the file
block/iscsi.c for the version you use for this :
.bdrv_aio_discard = iscsi_aio_dis
On Fri, Aug 10, 2012 at 10:14 PM, Stefan Priebe - Profihost AG
wrote:
> Am 10.08.2012 14:04, schrieb ronnie sahlberg:
>
>> On Fri, Aug 10, 2012 at 9:57 PM, Stefan Priebe - Profihost AG
>> wrote:
>>>
>>> Am 10.08.2012 13:12, schrieb ronnie sahlberg:
>>>
You want discard to work?
>>>
>>>
>>> Y
Am 10.08.2012 14:04, schrieb ronnie sahlberg:
On Fri, Aug 10, 2012 at 9:57 PM, Stefan Priebe - Profihost AG
wrote:
Am 10.08.2012 13:12, schrieb ronnie sahlberg:
You want discard to work?
Yes
You are using qemu 1.0 ?
actual qemu-kvm git
So you dont have the qemu support for scsi-gene
On Fri, Aug 10, 2012 at 9:57 PM, Stefan Priebe - Profihost AG
wrote:
> Am 10.08.2012 13:12, schrieb ronnie sahlberg:
>
>> You want discard to work?
>
> Yes
>
>
>> You are using qemu 1.0 ?
>
> actual qemu-kvm git
>
>
>> So you dont have the qemu support for scsi-generic passthrough to iscsi
>> devi
You can easily verify if your target supports thin-provisioning via
the UNMAP command.
Download the sg3-utils package
and either mount the LUN locally via the kernel open-iscsi or apply
the libiscsi patch to sg3-utils to make it iscsi-aware
then use the commands"sg_unmap" to try to unmap re
Am 10.08.2012 13:12, schrieb ronnie sahlberg:
You want discard to work?
Yes
You are using qemu 1.0 ?
actual qemu-kvm git
So you dont have the qemu support for scsi-generic passthrough to iscsi devices.
Why?
I think you need to run the target on linux 3.2 or later kernels using
ext4/xfs f
http://www.nexenta.com/corp/products/what-is-openstorage/nexentastor
tells me:
"SCSI UNMAP as a client-side feature frees up storage in the back end,
in the context of thin provisioning (a 100-to-one reduction in space for
VDI when using NexentaStor)."
So i would say nexenta supports it. But
Hi,
i tried that but i then get:
kvm: -device
scsi-block,bus=scsihw0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0,id=scsi0:
scsi-block: INQUIRY failed
kvm: -device
scsi-block,bus=scsihw0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0,id=scsi0:
Device 'scsi-block' could not be initialized
VM
On Fri, Aug 10, 2012 at 8:30 PM, Paolo Bonzini wrote:
> Il 10/08/2012 12:28, Stefan Priebe - Profihost AG ha scritto:
>> I'm using iscsi. So no raw or qcow2.
>
> Ok, then you need to use scsi-block as your device instead of scsi-disk
> or scsi-hd. This will disable the QEMU SCSI emulation and let
You want discard to work?
That should not be a problem with iscsi.
You are using qemu 1.0 ?
So you dont have the qemu support for scsi-generic passthrough to iscsi devices.
This should though work without too much trouble
First you need an iscsi target that supports SBC UNMAP command.
STGT
Il 10/08/2012 12:28, Stefan Priebe - Profihost AG ha scritto:
> I'm using iscsi. So no raw or qcow2.
Ok, then you need to use scsi-block as your device instead of scsi-disk
or scsi-hd. This will disable the QEMU SCSI emulation and let your VM
talk directly to the NAS.
CCing Ronnie who may be int
I'm using iscsi. So no raw or qcow2. XFS as FS.
Thanks,
Stefan
Am 10.08.2012 12:20, schrieb Paolo Bonzini:
Il 10/08/2012 11:22, Stefan Priebe - Profihost AG ha scritto:
virtio-scsi is now working fine. Could you please help me to get discard
/ trim running? I can't find any information what i
Il 10/08/2012 11:22, Stefan Priebe - Profihost AG ha scritto:
> virtio-scsi is now working fine. Could you please help me to get discard
> / trim running? I can't find any information what is needed to get
> discard / trim working.
You need to add discard_granularity=NNN, where NNN is usually 512
virtio-scsi is now working fine. Could you please help me to get discard
/ trim running? I can't find any information what is needed to get
discard / trim working.
Thanks,
Stefan
Am 09.08.2012 12:17, schrieb Stefan Priebe - Profihost AG:
That looks better - thanks for the hint. But now network
OK VMs do work fine now. Sorry for missing the patch after switching to
qemu-kvm.
Am 09.08.2012 14:44, schrieb Paolo Bonzini:
Ok, try deadline in the guest then. Using noop amplifies bad
performance, because you lose request merging. With no host scheduler,
as is the case with libiscsi, noop
Am 09.08.2012 15:15, schrieb Paolo Bonzini:
Il 09/08/2012 14:52, ronnie sahlberg ha scritto:
guest uses noop right now. Disk Host is nexentastor running open solaris. I
use libiscsi right now so the disks are not visible in both cases
(virtio-blk and virtio-scsi) to the host right now.
And i
Il 09/08/2012 15:52, Stefan Priebe - Profihost AG ha scritto:
>
> Am 09.08.2012 15:42, schrieb Paolo Bonzini:
>> Il 09/08/2012 15:39, Stefan Priebe - Profihost AG ha scritto:
scsi-generic would indeed incur some overhead because it does not do
scatter/gather I/O directly, but scsi-hd/scs
Am 09.08.2012 15:42, schrieb Paolo Bonzini:
Il 09/08/2012 15:39, Stefan Priebe - Profihost AG ha scritto:
scsi-generic would indeed incur some overhead because it does not do
scatter/gather I/O directly, but scsi-hd/scsi-block do not have this
overhead. In any case, that should be visible thro
Am 09.08.2012 15:42, schrieb Paolo Bonzini:
Il 09/08/2012 15:39, Stefan Priebe - Profihost AG ha scritto:
scsi-generic would indeed incur some overhead because it does not do
scatter/gather I/O directly, but scsi-hd/scsi-block do not have this
overhead. In any case, that should be visible thro
Il 09/08/2012 15:39, Stefan Priebe - Profihost AG ha scritto:
>> scsi-generic would indeed incur some overhead because it does not do
>> scatter/gather I/O directly, but scsi-hd/scsi-block do not have this
>> overhead. In any case, that should be visible through the output of
>> perf if it is sign
Il 09/08/2012 14:52, ronnie sahlberg ha scritto:
>> >
>> > guest uses noop right now. Disk Host is nexentastor running open solaris. I
>> > use libiscsi right now so the disks are not visible in both cases
>> > (virtio-blk and virtio-scsi) to the host right now.
>> >
> And if you mount the disks lo
On Thu, Aug 9, 2012 at 10:31 PM, Stefan Priebe - Profihost AG
wrote:
> Am 09.08.2012 14:19, schrieb Paolo Bonzini:
>
>> Il 09/08/2012 14:08, Stefan Priebe - Profihost AG ha scritto:
>>>
>>>
>>> virtio-scsi:
>>> rand 4k:
>>>write: io=822448KB, bw=82228KB/s, iops=20557, runt= 10002msec
>>>re
Il 09/08/2012 14:31, Stefan Priebe - Profihost AG ha scritto:
> Am 09.08.2012 14:19, schrieb Paolo Bonzini:
>> Il 09/08/2012 14:08, Stefan Priebe - Profihost AG ha scritto:
>>>
>>> virtio-scsi:
>>> rand 4k:
>>>write: io=822448KB, bw=82228KB/s, iops=20557, runt= 10002msec
>>>read : io=950920
Am 09.08.2012 14:19, schrieb Paolo Bonzini:
Il 09/08/2012 14:08, Stefan Priebe - Profihost AG ha scritto:
virtio-scsi:
rand 4k:
write: io=822448KB, bw=82228KB/s, iops=20557, runt= 10002msec
read : io=950920KB, bw=94694KB/s, iops=23673, runt= 10042msec
seq:
write: io=2436MB, bw=231312KB
Il 09/08/2012 14:08, Stefan Priebe - Profihost AG ha scritto:
>
> virtio-scsi:
> rand 4k:
> write: io=822448KB, bw=82228KB/s, iops=20557, runt= 10002msec
> read : io=950920KB, bw=94694KB/s, iops=23673, runt= 10042msec
> seq:
> write: io=2436MB, bw=231312KB/s, iops=56, runt= 10784msec
> rea
sorry guys i mixed qemu vs. qemu-kvm. Network is now working fine.
but still virtio-scsi vs. virtio-blk:
virtio-scsi:
rand 4k:
write: io=822448KB, bw=82228KB/s, iops=20557, runt= 10002msec
read : io=950920KB, bw=94694KB/s, iops=23673, runt= 10042msec
seq:
write: io=2436MB, bw=231312KB/s, i
Am 09.08.2012 13:04, schrieb Stefan Hajnoczi:
On Thu, Aug 9, 2012 at 11:17 AM, Stefan Priebe - Profihost AG
wrote:
That looks better - thanks for the hint. But now network isn't working at
all ;-(
You need to have commit 26b9b5fe17cc1b6be2e8bf8b9d16094f420bb8ad
("virtio: fix vhost handling")
Il 09/08/2012 13:04, Stefan Hajnoczi ha scritto:
>> > That looks better - thanks for the hint. But now network isn't working at
>> > all ;-(
> You need to have commit 26b9b5fe17cc1b6be2e8bf8b9d16094f420bb8ad
> ("virtio: fix vhost handling"). Pull the latest qemu.git/master
> changes if you don't h
On Thu, Aug 9, 2012 at 11:17 AM, Stefan Priebe - Profihost AG
wrote:
> That looks better - thanks for the hint. But now network isn't working at
> all ;-(
You need to have commit 26b9b5fe17cc1b6be2e8bf8b9d16094f420bb8ad
("virtio: fix vhost handling"). Pull the latest qemu.git/master
changes if y
That looks better - thanks for the hint. But now network isn't working
at all ;-(
Stefan
Am 09.08.2012 11:18, schrieb Stefan Hajnoczi:
On Thu, Aug 9, 2012 at 8:41 AM, Stefan Priebe wrote:
starting line:
/usr/bin/qemu-x86_64 -chardev
socket,id=qmp,path=/var/run/qemu-server/103.qmp,server,nowai
On Thu, Aug 9, 2012 at 8:41 AM, Stefan Priebe wrote:
> starting line:
> /usr/bin/qemu-x86_64 -chardev
> socket,id=qmp,path=/var/run/qemu-server/103.qmp,server,nowait -mon
> chardev=qmp,mode=control -pidfile /var/run/qemu-server/103.pid -daemonize
> -usbdevice tablet -name kvmcrash -smp sockets=1,c
Il 09/08/2012 10:00, Stefan Priebe ha scritto:
> @writethrough: why not?
Because it's slow, and unnecessary if you're running kernel >= 2.6.32 or
recent RHEL/CentOS.
> @libiscsi Same speed problem with cache=none and with just local lvm disks.
Cool, please use these settings while bisecting.
P
@writethrough: why not?
@libiscsi Same speed problem with cache=none and with just local lvm disks.
Stefan
Am 09.08.2012 um 09:53 schrieb Paolo Bonzini :
> Il 09/08/2012 09:41, Stefan Priebe ha scritto:
>> -drive
>> file=iscsi://10.0.255.100/iqn.1986-03.com.sun:02:8a9019a4-4aa3-cd8a-f723-f05d
Il 09/08/2012 09:41, Stefan Priebe ha scritto:
> -drive
> file=iscsi://10.0.255.100/iqn.1986-03.com.sun:02:8a9019a4-4aa3-cd8a-f723-f05db9085ef9/0,if=none,id=drive-scsi1,cache=writethrough,aio=native
Are you sure you want cache=writethrough here?
Also, please try either updating libiscsi to the l
starting line:
/usr/bin/qemu-x86_64 -chardev
socket,id=qmp,path=/var/run/qemu-server/103.qmp,server,nowait -mon
chardev=qmp,mode=control -pidfile /var/run/qemu-server/103.pid
-daemonize -usbdevice tablet -name kvmcrash -smp sockets=1,cores=8
-nodefaults -boot menu=on -vga cirrus -k de -device
Il 09/08/2012 09:07, Stefan Priebe ha scritto:
> Yes should be possible. guest is Debian or Ubuntu. I couldn't find a
> tag for V1.1.1 which I ran from source. So where to start bisect?
You can start from the v1.1.0 tag.
Can you give the command line, perhaps it is enough to reproduce?
Paolo
>
Yes should be possible. guest is Debian or Ubuntu. I couldn't find a tag for
V1.1.1 which I ran from source. So where to start bisect?
Stefan
Am 09.08.2012 um 09:01 schrieb Paolo Bonzini :
> Il 09/08/2012 08:13, Stefan Priebe ha scritto:
>> i really would like to test with actual git. But my VM
Il 09/08/2012 08:13, Stefan Priebe ha scritto:
> i really would like to test with actual git. But my VMs run awfully SLOW
> with actual git version. Boot process prints one line every two seconds.
> So i can't test. Is there a patch or backport for this problem?
Hmm, no, I haven't seen it reported
i really would like to test with actual git. But my VMs run awfully SLOW
with actual git version. Boot process prints one line every two seconds.
So i can't test. Is there a patch or backport for this problem?
Thanks,
Stefan
Am 08.08.2012 18:17, schrieb Paolo Bonzini:
Il 08/08/2012 17:21, St
Il 08/08/2012 19:12, Stefan Priebe ha scritto:
> Yes cache none. Is there a bugfix for 1.1.1?
It's not fixed in 1.1.1, but it's fixed in git.
Paolo
Yes cache none. Is there a bugfix for 1.1.1?
Stefan
Am 08.08.2012 um 18:17 schrieb Paolo Bonzini :
> Il 08/08/2012 17:21, Stefan Priebe ha scritto:
>> Hello list,
>>
>> i wanted to start using virtio-scsi instead of virtio-blk, cause it
>> offers the possibility to use discard / trim support.
>
Il 08/08/2012 17:21, Stefan Priebe ha scritto:
> Hello list,
>
> i wanted to start using virtio-scsi instead of virtio-blk, cause it
> offers the possibility to use discard / trim support.
>
> Kernel: 3.5.0 on host and guest
> Qemu-kvm: 1.1.1 stable
>
> But i'm not seeing the same or nearly the
Hello list,
i wanted to start using virtio-scsi instead of virtio-blk, cause it
offers the possibility to use discard / trim support.
Kernel: 3.5.0 on host and guest
Qemu-kvm: 1.1.1 stable
But i'm not seeing the same or nearly the same speed:
virtio-scsi:
rand. 4k:
write: io=677628KB, bw=6
46 matches
Mail list logo
