Am 03.09.2015 um 18:59 schrieb Stefan Hajnoczi:
> On Thu, Aug 20, 2015 at 10:14:08AM +0200, Peter Lieven wrote:
>> the blk_drain_all() that is executed if the guest issues a DMA cancel
>> leads to a stuck main loop if the storage backend (e.g. a NFS share)
>> is unresponsive
PIO read requests on the ATAPI interface used to be sync blk requests.
This has to siginificant drawbacks. First the main loop hangs util an
I/O request is completed and secondly if the I/O request does not
complete (e.g. due to an unresponsive storage) Qemu hangs completely.
Signed-off-by: Peter
Am 21.08.2015 um 08:12 schrieb Eric Blake:
On 08/20/2015 01:14 AM, Peter Lieven wrote:
If the backend storage is unresponsive and we cancel a request due to
a timeout we cannot immediately destroy the AIOCB because the storage
might complete the original request laster if it is responsive again
Am 14.08.2015 um 13:33 schrieb Peter Lieven:
It has been reported that at least tgtd returns a block size of 0
for LUN 0. To avoid running into divide by zero later on and protect
against other problematic block sizes validate the block size right
at connection time.
Cc: qemu-sta...@nongnu.org
Am 27.08.2015 um 17:23 schrieb Paolo Bonzini:
i was debugging increased memory footprint of qemu over the past time and
found that the coroutine pool heap usage can grow up to 70MB by just booting
an Ubuntu Live CD. And those 70MB are never freed.
Is this expected? Wouldn't it make sense to
If the file is readonly its not expected to grow so
save the blocking call to nfs_fstat_async and use
the value saved at connection time. Also important
the monitor (and thus the main loop) will not hang
if block device info is queried and the NFS share
is unresponsive.
Signed-off-by: Peter
Hi,
i was debugging increased memory footprint of qemu over the past time and found
that the coroutine
pool heap usage can grow up to 70MB by just booting an Ubuntu Live CD. And
those 70MB are never
freed.
Is this expected? Wouldn't it make sense to asynchronically throw some
coroutines (or
Am 26.08.2015 um 17:31 schrieb Jeff Cody:
On Mon, Aug 24, 2015 at 10:13:16PM +0200, Max Reitz wrote:
On 24.08.2015 21:34, Peter Lieven wrote:
Am 24.08.2015 um 20:39 schrieb Max Reitz:
On 24.08.2015 10:06, Peter Lieven wrote:
If the file is readonly its not expected to grow so
save
If the file is readonly its not expected to grow so
save the blocking call to nfs_fstat_async and use
the value saved at connection time. Also important
the monitor (and thus the main loop) will not hang
if block device info is queried and the NFS share
is unresponsive.
Signed-off-by: Peter
Am 24.08.2015 um 20:39 schrieb Max Reitz:
On 24.08.2015 10:06, Peter Lieven wrote:
If the file is readonly its not expected to grow so
save the blocking call to nfs_fstat_async and use
the value saved at connection time. Also important
the monitor (and thus the main loop) will not hang
Am 21.08.2015 um 18:46 schrieb Max Reitz:
On 2015-08-21 at 00:49, Peter Lieven wrote:
If the file is readonly its not expected to grow so
save the blocking call to nfs_fstat_async and use
the value saved at connection time. Also important
the monitor (and thus the main loop) will not hang
If the file is readonly its not expected to grow so
save the blocking call to nfs_fstat_async and use
the value saved at connection time. Also important
the monitor (and thus the main loop) will not hang
if block device info is queried and the NFS share
is unresponsive.
Signed-off-by: Peter
if the mounted CDROM is not used and was just not
unmounted after usage.
This approach avoids the blk_drain_all for read-only media and
cancelles the AIO locally and makes the callback a NOP if the
original request is completed after the NFS share is responsive
again.
Peter Lieven (2):
block/io
-off-by: Peter Lieven p...@kamp.de
---
block/io.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/block/io.c b/block/io.c
index d4bc83b..e628581 100644
--- a/block/io.c
+++ b/block/io.c
@@ -2007,7 +2007,9 @@ static void bdrv_aio_bh_cb(void *opaque
Am 14.08.2015 um 16:45 schrieb Peter Lieven:
Am 14.08.2015 um 16:08 schrieb Kevin Wolf:
Am 14.08.2015 um 15:43 hat Peter Lieven geschrieben:
Am 22.06.2015 um 23:54 schrieb John Snow:
On 06/22/2015 09:09 AM, Peter Lieven wrote:
Am 22.06.2015 um 11:25 schrieb Stefan Hajnoczi:
On Fri, Jun 19
Signed-off-by: Peter Lieven p...@kamp.de
---
block/iscsi.c | 4
dtc | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/block/iscsi.c b/block/iscsi.c
index 5002916..fac3a7a 100644
--- a/block/iscsi.c
+++ b/block/iscsi.c
@@ -1214,6 +1214,10 @@ static void
Am 22.06.2015 um 23:54 schrieb John Snow:
On 06/22/2015 09:09 AM, Peter Lieven wrote:
Am 22.06.2015 um 11:25 schrieb Stefan Hajnoczi:
On Fri, Jun 19, 2015 at 2:14 PM, Peter Lieven p...@kamp.de wrote:
Am 18.06.2015 um 11:36 schrieb Stefan Hajnoczi:
On Thu, Jun 18, 2015 at 10:29 AM, Peter
Am 14.08.2015 um 16:08 schrieb Kevin Wolf:
Am 14.08.2015 um 15:43 hat Peter Lieven geschrieben:
Am 22.06.2015 um 23:54 schrieb John Snow:
On 06/22/2015 09:09 AM, Peter Lieven wrote:
Am 22.06.2015 um 11:25 schrieb Stefan Hajnoczi:
On Fri, Jun 19, 2015 at 2:14 PM, Peter Lieven p...@kamp.de
Am 27.07.2015 um 16:30 schrieb Stefan Hajnoczi:
On Mon, Jul 27, 2015 at 2:58 PM, Peter Lieven p...@kamp.de wrote:
I was experimenting a little with optimized zlib versions (like zlib-ng) to
optimize the speed of compressed qcow2 generation.
I found out that chaning the windowBits from -12
Hi,
I was experimenting a little with optimized zlib versions (like zlib-ng) to
optimize the speed of compressed qcow2 generation.
I found out that chaning the windowBits from -12 to -15 alone increases
compression speed by about 15% while lowering
the compressed size by about 6%. As a test
Hi,
I was experimenting a little with optimized zlib versions (like zlib-ng) to
optimize the speed of compressed qcow2 generation.
I found out that chaning the windowBits from -12 to -15 alone increases
compression speed by about 15% while lowering
the compressed size by about 6%. As a test
upcoming libnfs versions will support logging debug messages. Add
support for it in qemu through a per-drive option.
Examples:
qemu -drive if=virtio,file=nfs://...,file.debug=2
qemu-img create -o debug=2 nfs://... 10G
Signed-off-by: Peter Lieven p...@kamp.de
---
v2-v3: use a per-drive option
RHEL7 and others are stuck with libiscsi 1.9.0 since there
unfortunately was an ABI breakage after that release.
Signed-off-by: Peter Lieven p...@kamp.de
---
block/iscsi.c | 31 ++-
configure |6 +++---
qemu-options.hx |3 ++-
3 files changed, 31
Am 26.06.2015 um 11:14 schrieb Stefan Hajnoczi:
On Thu, Jun 25, 2015 at 03:26:46PM +0200, Peter Lieven wrote:
Am 25.06.2015 um 15:18 schrieb Stefan Hajnoczi:
On Tue, Jun 23, 2015 at 10:12:15AM +0200, Peter Lieven wrote:
upcoming libnfs versions will support logging debug messages. Add
support
RHEL7 and others are stuck with libiscsi 1.9.0 since there
unfortunately was an ABI breakage after that release.
Signed-off-by: Peter Lieven p...@kamp.de
---
v1-v2: - do not use reserved macro names [Paolo]
- change text in qemu-options.hx to libiscsi 1.15.0 or greater
block/iscsi.c
upcoming libnfs versions will support logging debug messages. Add
support for it in qemu through a cmdline parameter.
Example
qemu -nfs debug=99 -cdrom nfs://...
Signed-off-by: Peter Lieven p...@kamp.de
---
v1-v2: reworked patch to accept the debug level as a cmdline
parameter instead
a malicious caller could otherwise specify a very
large value via the URI and force libnfs to allocate
a large amount of memory for the readahead buffer.
Cc: qemu-sta...@nongnu.org
Signed-off-by: Peter Lieven p...@kamp.de
---
block/nfs.c |7 +++
1 file changed, 7 insertions(+)
diff
Am 25.06.2015 um 15:18 schrieb Stefan Hajnoczi:
On Tue, Jun 23, 2015 at 10:12:15AM +0200, Peter Lieven wrote:
upcoming libnfs versions will support logging debug messages. Add
support for it in qemu through an URL parameter.
Signed-off-by: Peter Lieven p...@kamp.de
---
block/nfs.c | 4
Am 25.06.2015 um 23:08 schrieb Paolo Bonzini:
On 16/06/2015 13:45, Peter Lieven wrote:
libiscsi starting with 1.15 will properly support timeout of iscsi
commands. The default will remain no timeout, but this can
be changed via cmdline parameters, e.g.:
qemu -iscsi timeout=30 -drive file
Am 23.06.2015 um 01:03 schrieb ronnie sahlberg:
LGTM
It is good to finally have timeouts that work in libiscsi, and a consumer that
can use and benefit from it.
Paolo, Kevin, Stefan, do you think this is sth for 2.4?
Peter
upcoming libnfs versions will support logging debug messages. Add
support for it in qemu through an URL parameter.
Signed-off-by: Peter Lieven p...@kamp.de
---
block/nfs.c | 4
1 file changed, 4 insertions(+)
diff --git a/block/nfs.c b/block/nfs.c
index ca9e24e..f7388a3 100644
--- a/block
Am 22.06.2015 um 11:25 schrieb Stefan Hajnoczi:
On Fri, Jun 19, 2015 at 2:14 PM, Peter Lieven p...@kamp.de wrote:
Am 18.06.2015 um 11:36 schrieb Stefan Hajnoczi:
On Thu, Jun 18, 2015 at 10:29 AM, Peter Lieven p...@kamp.de wrote:
Am 18.06.2015 um 10:42 schrieb Kevin Wolf:
Am 18.06.2015 um 10
Am 18.06.2015 um 08:59 schrieb Paolo Bonzini:
On 18/06/2015 08:39, Peter Lieven wrote:
It seems like the mainloop is waiting here:
#0 0x7606c89c in __lll_lock_wait ()
from /lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#1 0x76068065 in _L_lock_858
Am 18.06.2015 um 09:03 schrieb Peter Lieven:
Am 18.06.2015 um 08:59 schrieb Paolo Bonzini:
On 18/06/2015 08:39, Peter Lieven wrote:
It seems like the mainloop is waiting here:
#0 0x7606c89c in __lll_lock_wait ()
from /lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info
Am 18.06.2015 um 11:36 schrieb Stefan Hajnoczi:
On Thu, Jun 18, 2015 at 10:29 AM, Peter Lieven p...@kamp.de wrote:
Am 18.06.2015 um 10:42 schrieb Kevin Wolf:
Am 18.06.2015 um 10:30 hat Peter Lieven geschrieben:
Am 18.06.2015 um 09:45 schrieb Kevin Wolf:
Am 18.06.2015 um 09:12 hat Peter
Am 18.06.2015 um 09:45 schrieb Kevin Wolf:
Am 18.06.2015 um 09:12 hat Peter Lieven geschrieben:
Thread 2 (Thread 0x75550700 (LWP 2636)):
#0 0x75d87aa3 in ppoll () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1 0x55955d91 in qemu_poll_ns (fds
Am 18.06.2015 um 10:42 schrieb Kevin Wolf:
Am 18.06.2015 um 10:30 hat Peter Lieven geschrieben:
Am 18.06.2015 um 09:45 schrieb Kevin Wolf:
Am 18.06.2015 um 09:12 hat Peter Lieven geschrieben:
Thread 2 (Thread 0x75550700 (LWP 2636)):
#0 0x75d87aa3 in ppoll () from /lib/x86_64
Am 17.06.2015 um 10:35 schrieb Kevin Wolf:
Am 16.06.2015 um 17:34 hat Stefan Hajnoczi geschrieben:
On Tue, Jun 16, 2015 at 3:44 PM, Peter Lieven p...@kamp.de wrote:
I wonder how difficult it would be to have the IDE CDROM run in its own
thread?
We usually have ISOs mounted on an NFS share
Hi,
I wonder how difficult it would be to have the IDE CDROM run in its own thread?
We usually have ISOs mounted on an NFS share as CDROM. Problem: If the NFS Share
goes down, it takes down monitor, qmp, vnc etc. with it.
Maybe its already possible to do this via cmdline args?
Any ideas,
Am 26.05.2015 um 12:21 schrieb Paolo Bonzini:
On 26/05/2015 12:06, Kevin Wolf wrote:
Am 26.05.2015 um 11:44 hat Paolo Bonzini geschrieben:
On 26/05/2015 11:37, Kevin Wolf wrote:
If we run into a timeout we theoretically have the following options:
- reconnect
- retry
- error
I would
Am 22.05.2015 um 14:22 schrieb ronnie sahlberg:
On Fri, May 22, 2015 at 12:30 AM, Peter Lieven p...@kamp.de
mailto:p...@kamp.de wrote:
Hi,
next libiscsi version will allow to define command timeouts. At least for
sync commands this
was in fact possible since somewhen in 2013
Am 26.05.2015 um 11:01 schrieb Kevin Wolf:
Am 22.05.2015 um 09:30 hat Peter Lieven geschrieben:
Hi,
next libiscsi version will allow to define command timeouts. At least for sync
commands this
was in fact possible since somewhen in 2013. Per default this timeout is
disabled.
I would like
Hi,
next libiscsi version will allow to define command timeouts. At least for sync
commands this
was in fact possible since somewhen in 2013. Per default this timeout is
disabled.
I would like to at least define a timeout for the sync commands (login,
readcapacity, inquiry, logout etc)
of
Am 27.04.2015 um 12:47 schrieb Paolo Bonzini:
On 16/04/2015 10:46, Peter Lieven wrote:
I just run tests with the new libiscsi branch that allows async
reconnects. I found that
I cannot quit qemu while qemu is waiting for a reconnect to the storage.
E.g.
I start qemu and then shut down
Am 27.04.2015 um 14:11 schrieb Paolo Bonzini:
On 27/04/2015 13:51, Peter Lieven wrote:
The reason to do this, is that while I/O is pending you do not know if
the I/O has been completed or not.
But if I consider a raw image, quitting without a clean shutdown can
also leave an inconsistent
Am 16.04.2015 um 14:33 schrieb Paolo Bonzini:
On 16/04/2015 14:18, Peter Lieven wrote:
We need this to support SCSI_STATUS_TASK_SET_FULL.
Any reason apart from the missing constant?
No, but I wanted to avoid starting checking for constants that were added
shortly after this.
You can't
Signed-off-by: Peter Lieven p...@kamp.de
---
block/iscsi.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/block/iscsi.c b/block/iscsi.c
index 6cf7e99..221c9fc 100644
--- a/block/iscsi.c
+++ b/block/iscsi.c
@@ -1253,11 +1253,11 @@ static void
Am 16.04.2015 um 14:42 schrieb Paolo Bonzini:
On 16/04/2015 14:18, Peter Lieven wrote:
SCSI allowes to tell the target to not return from a write command
if the date is not written to the disk. Use this so called FUA
bit if it is supported to optimize WRITE commands if writeback is
not allowed
Signed-off-by: Peter Lieven p...@kamp.de
---
block/iscsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/iscsi.c b/block/iscsi.c
index 3d0ffeb..04c1309 100644
--- a/block/iscsi.c
+++ b/block/iscsi.c
@@ -2,7 +2,7 @@
* QEMU Block driver for iSCSI images
. If we set the FUA bit we can ignore the
following FLUSH.
Signed-off-by: Peter Lieven p...@kamp.de
---
block/iscsi.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/block/iscsi.c b/block/iscsi.c
index 237faa1..600 100644
--- a/block/iscsi.c
+++ b/block
v1-v2: - removed the requirement for libiscsi 1.10.0 [Paolo]
- reworked to force_next_flush logic [Paolo]
Peter Lieven (9):
block/iscsi: do not forget to logout from target
block/iscsi: change all iscsilun properties from uint8_t to bool
block/iscsi: rename iscsi_write_protected
-by: Peter Lieven p...@kamp.de
---
block/iscsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/iscsi.c b/block/iscsi.c
index 8364f97..8fca1d3 100644
--- a/block/iscsi.c
+++ b/block/iscsi.c
@@ -1499,7 +1499,7 @@ static int iscsi_open(BlockDriverState *bs, QDict
*options, int
Hi,
Ronnie came up with an idea to reduce latency if !bs-enable_write_cache for an
iSCSI device.
If !bs-enable_write_cache Qemu sends a flush after every single write. What
could be done is
the following:
if (!bs-enable_write_cache)
set FUA (force unit access) and DPO (disable page out)
We actually were always impolitely dropping the connection and
not cleanly logging out.
Cc: qemu-sta...@nongnu.org
Signed-off-by: Peter Lieven p...@kamp.de
---
block/iscsi.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/block/iscsi.c b/block/iscsi.c
index ab20e4d..0b6d3dd 100644
Am 14.04.2015 um 11:04 schrieb Stefan Hajnoczi:
On Tue, Apr 14, 2015 at 7:49 AM, Peter Lieven p...@kamp.de wrote:
Ronnie came up with an idea to reduce latency if !bs-enable_write_cache for
an iSCSI device.
If !bs-enable_write_cache Qemu sends a flush after every single write. What
could
Am 11.04.2015 um 17:00 schrieb Peter Lieven:
Am 11.04.2015 um 15:11 schrieb Peter Lieven:
Am 09.04.2015 um 17:17 schrieb Paolo Bonzini:
On 09/04/2015 16:54, Peter Lieven wrote:
#define BM_MIGRATION_COMPAT_STATUS_BITS \
(IDE_RETRY_DMA | IDE_RETRY_PIO | \
IDE_RETRY_READ
Am 07.04.2015 um 21:13 schrieb John Snow:
On 04/07/2015 03:02 PM, Peter Lieven wrote:
Am 07.04.2015 um 20:56 schrieb John Snow:
On 04/07/2015 02:44 PM, Peter Lieven wrote:
Am 07.04.2015 um 17:29 schrieb Dr. David Alan Gilbert:
* Peter Lieven (p...@kamp.de) wrote:
Hi David,
Am
Am 07.04.2015 um 21:13 schrieb John Snow:
On 04/07/2015 03:02 PM, Peter Lieven wrote:
Am 07.04.2015 um 20:56 schrieb John Snow:
On 04/07/2015 02:44 PM, Peter Lieven wrote:
Am 07.04.2015 um 17:29 schrieb Dr. David Alan Gilbert:
* Peter Lieven (p...@kamp.de) wrote:
Hi David,
Am
Am 07.04.2015 um 21:01 schrieb Dr. David Alan Gilbert:
* Peter Lieven (p...@kamp.de) wrote:
Am 07.04.2015 um 17:29 schrieb Dr. David Alan Gilbert:
* Peter Lieven (p...@kamp.de) wrote:
Hi David,
Am 07.04.2015 um 10:43 schrieb Dr. David Alan Gilbert:
Any particular workload or reproducer
Am 07.04.2015 um 17:29 schrieb Dr. David Alan Gilbert:
* Peter Lieven (p...@kamp.de) wrote:
Hi David,
Am 07.04.2015 um 10:43 schrieb Dr. David Alan Gilbert:
Any particular workload or reproducer?
Workload is almost zero. I try to figure out if there is a way to trigger
it.
Maybe playing
iscsi_which_events for changed events.
Next libiscsi version will introduce async reconnects and zero events
are returned while libiscsi is waiting for a reconnect retry.
Signed-off-by: Peter Lieven p...@kamp.de
---
block/iscsi.c | 33 +++--
1 file changed, 27
Am 06.04.2015 um 21:02 schrieb Peter Lieven:
Am 06.04.2015 um 20:50 schrieb John Snow:
On 04/06/2015 02:47 PM, Peter Lieven wrote:
Hi all,
is there a known issue in Qemu 2.2.1 where IDE stalls sometimes after a
migration with Qemu 2.2.1?
The migration succeeds, but it seems
Am 06.04.2015 um 20:50 schrieb John Snow:
On 04/06/2015 02:47 PM, Peter Lieven wrote:
Hi all,
is there a known issue in Qemu 2.2.1 where IDE stalls sometimes after a
migration with Qemu 2.2.1?
The migration succeeds, but it seems that the complete I/O is hanging. This
happens only
Hi Block people,
we recently observed some strange I/O stalls on some vServers. I suspect a bug
in the target and
already added some debugging output to libiscsi that could have helped to track
the issue.
However, to enable this debugging I would need to call
iscsi_set_log_level
during
501 - 564 of 564 matches
Mail list logo
