On Wed, Sep 11, 2019 at 5:48 PM Max Reitz wrote:
>
> On 10.09.19 17:41, Peter Lieven wrote:
> > libnfs recently added support for unmounting. Add support
> > in Qemu too.
> >
> > Signed-off-by: Peter Lieven
> > ---
> > block/nfs.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a
On Thu, Sep 5, 2019 at 8:16 PM Peter Lieven wrote:
>
> Am 05.09.19 um 12:05 schrieb ronnie sahlberg:
> > On Thu, Sep 5, 2019 at 7:43 PM Peter Lieven wrote:
> >> Am 04.09.19 um 11:34 schrieb Kevin Wolf:
> >>> Am 03.09.2019 um 21:52 hat Peter Lieven geschriebe
nfs->fh filedescriptor from your eventsystem.
Because the fd is about to be closed so there is great chance it will
be recycled for a completely different purpose if you open any other
files from qemu.
3, call nfs_umount() Internally this will close the socket to the
NFS server, then go through thr process to open a new socket to the
portmapper to discover the mount server, then close that socket and
reconnect a new socket again to the mount server and perform the UMNT
call.
ronnie sahlberg
> Peter
>
>
U
passes this URL to libiscsi, it allows the library to decide on
whether to use normal iSCSI or whether it should use iSER.
I think RDMA would be a less good name for this as RDMA is not only
used to transport iSCSI but is also used for NFS as well as SMB.
regards
ronnie sahlberg
On Fri, Dec 8,
mu-doc and in
>> qemu.1.
>>
>> There's substantial overlap with the existing qemu-doc section "Disk
>> Images". Mark with a TODO comment.
>>
>> Output of --help will be fixed next.
>>
>> Cc: Ronnie Sahlberg
>> Cc: Kevin
Reviewed-by: Ronnie Sahlberg
Would be nice if this died at some stage :
[,password=password]
But that is for a different patch.
On Wed, Oct 4, 2017 at 8:12 PM, Marc-André Lureau
wrote:
> On Mon, Oct 2, 2017 at 4:03 PM, Markus Armbruster wrote:
>> -iscsi ended up under the "Dev
Reviewed-by: Ronnie Sahlberg
On Tue, Oct 3, 2017 at 12:03 AM, Markus Armbruster wrote:
> Cc: Ronnie Sahlberg
> Cc: Kevin Wolf
> Cc: Max Reitz
> Cc: qemu-bl...@nongnu.org
> Signed-off-by: Markus Armbruster
> ---
> qemu-options.hx | 6 ++
> 1 file changed, 6 inse
Congratulation to a fantastic presentation Roy.
Very impressive data!
On Wed, Sep 21, 2016 at 11:39 AM, Roy Shterman wrote:
> Hi all,
>
>
>
> Attached presentation was presented in SDC 2016 in Santa-Clara and actually
> summaries the iSER implementation inside Libiscsi/QEMU.
>
>
>
> You can find
It is never too late.
I can start working on a patch to add "iser://" URL support to
libiscsi right now. It should be a trivial change.
I think I would prefer iser:// instead of iscsi+iser:// but it is not
religiusly. Let me know if you rather want iscsi+iser.
But you would still need some chang
MMC devices:
READ CAPACITY 10 support is mandatory.
No support for READ CAPACITY 16
SBC devices:
READ CAPACITY 10 is mandatory
READ CAPACITY 16 support is only required when you have thin provisioning
or protection information (or if the device is >2^32 blocks)
Almost all, but apparently not all,
On Fri, Sep 11, 2015 at 8:20 AM, Eric Blake wrote:
> On 09/11/2015 12:00 AM, Fam Zheng wrote:
>> Previously we use "-iscsi id=target-iqn,user=foo,password=bar,..." to
>> specify iscsi connection parameters, unfortunately it doesn't work with
>> qemu-img.
>>
>> This patch adds per drive options to
On Tue, Aug 4, 2015 at 5:53 AM, Peter Lieven wrote:
> Am 04.08.2015 um 14:29 schrieb Peter Lieven:
>
>> Am 04.08.2015 um 14:09 schrieb Paolo Bonzini:
>>
>>>
>>> On 04/08/2015 13:57, Peter Lieven wrote:
>>>
Okay, what I found out is that in aio_poll I get revents = POLLIN for
the nfs fil
LGTM
It is good to finally have timeouts that work in libiscsi, and a consumer
that can use and benefit from it.
On Tue, Jun 16, 2015 at 4:45 AM, Peter Lieven wrote:
> libiscsi starting with 1.15 will properly support timeout of iscsi
> commands. The default will remain no timeout, but this ca
Reviewed-By: Ronnie Sahlberg
On Tue, Apr 14, 2015 at 1:37 AM, Peter Lieven wrote:
> We actually were always impolitely dropping the connection and
> not cleanly logging out.
>
> Cc: qemu-sta...@nongnu.org
> Signed-off-by: Peter Lieven
> ---
> block/iscsi.c | 6 ++
On Wed, Apr 8, 2015 at 1:38 AM, Stefan Hajnoczi wrote:
> On Tue, Apr 7, 2015 at 9:08 PM, Peter Lieven wrote:
>
> Please CC qemu-devel@nongnu.org in the future. All patches must be on
> the qemu-devel mailing list so they can be merged (for transparency).
> I have added qemu-devel to CC.
>
>> +
On Mon, Sep 8, 2014 at 7:42 AM, Paolo Bonzini wrote:
> Il 08/09/2014 16:35, Peter Lieven ha scritto:
>
> messages. :)
So you would not throw an error msg here?
>>> No, though a trace could be useful.
>>
>> Is there a howto somewhere how to implement that?
>
> Try commit 4ac4458076e1aa
Feel free to add a
Reviewed-by: Ronnie Sahlberg
to the patches.
On Fri, Sep 5, 2014 at 12:52 PM, Peter Lieven wrote:
> Am 05.09.2014 um 19:05 schrieb ronnie sahlberg:
>> Looks good to me.
>>
>> (minor question is just why not let default max be 0x for both 10
>>
Looks good to me.
(minor question is just why not let default max be 0x for both 10
and 16 CDBs ?)
On Fri, Sep 5, 2014 at 9:51 AM, Peter Lieven wrote:
> This series adds the basics for introducing a maximum transfer length
> to the block layer. Its main purpose is currently avoiding that
> a
On Wed, Sep 3, 2014 at 7:18 AM, Paolo Bonzini wrote:
> Il 03/09/2014 16:17, ronnie sahlberg ha scritto:
>> I think (a) would be best.
>> But I would suggest some small modifications:
>>
>> Set the default max to something even smaller, like 256 sectors. This
>&g
On Wed, Sep 3, 2014 at 1:09 AM, Peter Lieven wrote:
>
>
>> Am 02.09.2014 um 21:30 schrieb Peter Lieven :
>>
>> Looking at the code, is it possible that not the guest is causing trouble
>> here, but
>> multiwrite_merge code?
>>
>> From what I see the only limit it has when merging requests is the
etically there could be targets that support really huge
MaxBurstLengths > 32MB. For those you probably want to switch to
WRITE16 when the SCSI transfer length goes > 0x.
- if (iscsilun->use_16_for_rw) {
+ if (iscsilun->use_16_for_rw || num_sectors > 0x) {
regards
ronnie sa
On Wed, Jul 16, 2014 at 10:29 AM, Michael Tokarev wrote:
> 16.07.2014 21:23, ronnie sahlberg wrote:
>
>> If you ask debian to upgrade. Could you ask them to wait and upgrade after I
>> have release the next version, hopefully if all goes well, at the end
>> of this week?
&
On Wed, Jul 16, 2014 at 10:11 AM, Stefan Weil wrote:
> Am 16.07.2014 18:49, schrieb Paolo Bonzini:
>> Il 16/07/2014 18:28, Stefan Weil ha scritto:
>>> Debian testing includes a brand new libiscsi, but it
>>> does not include libiscsi.pc, so pkg-config won't know that it is
>>> available and config
On Wed, Jun 18, 2014 at 8:57 AM, Paolo Bonzini wrote:
> Il 18/06/2014 17:53, Peter Maydell ha scritto:
>
>> Then you probably need to fix the configure test ;-) This is
>> Ubuntu Trusty so really pretty recent (it's my main x86 build
>> machine, not some oddball platform); libiscsi-dev 1.4.0-3.
>
On Wed, Jun 4, 2014 at 7:43 AM, Peter Lieven wrote:
> Am 04.06.2014 16:00, schrieb ronnie sahlberg:
>> Looks good.
>>
>> As an alternative, you could do the 10 vs 16 decision based on the LBA
>> instead of the size of the device :
>>
>> -if (use_16_
Looks good.
As an alternative, you could do the 10 vs 16 decision based on the LBA
instead of the size of the device :
-if (use_16_for_ws) {
+ if (lba >= 0x1) {
iTask.task = iscsi_writesame16_task(iscsilun->iscsi, iscsilun->lun, lba,
For this case and for the iscsi case, isn't it likely that once this
happens the guest is pretty much doomed since I/O to the disk will no
longer work ?
Should we also change the block layer so that IF *_readv/_writev fails
with -ENOMEM
then it should try again but break the request up into a chai
On Thu, May 8, 2014 at 4:33 AM, Stefan Hajnoczi wrote:
> On Wed, May 07, 2014 at 04:09:27PM +0200, Peter Lieven wrote:
>> On 07.05.2014 12:29, Paolo Bonzini wrote:
>> >Il 07/05/2014 12:07, Stefan Hajnoczi ha scritto:
>> >>On Fri, May 02, 2014 at 12:39:06AM +0200, Peter Lieven wrote:
>> +static
Please try to sync libnfs again. Autotools is still a bit of a mystery for me.
On Tue, Jan 28, 2014 at 2:16 AM, Stefan Hajnoczi wrote:
> On Mon, Jan 27, 2014 at 07:28:07PM +0100, Peter Lieven wrote:
>> Am 27.01.2014 17:11, schrieb Stefan Hajnoczi:
>> > On Mon, Jan 13, 2014 at 11:21:52AM +0100,
On Fri, Jan 10, 2014 at 8:10 AM, Peter Lieven wrote:
>
> Ronnie, can you also give a short advise on Kevin's question about short
> reads.
> I think they can happen if we read beyond past EOF or not?
>
Short reads should normally not happen in libnfs itself since servers
are often careful always
nfs context so that it will use these
values when it fills in the rpc header to send to the server.
But if you want to parse the url yourself, you can do that too, by
just calling nfs_set_auth(nfs, libnfs_authunix_create(..., 10, 10,
...
Regards
Ronnie Sahlberg
On Thu, Jan 2, 2014 at 7:41 AM, Alexander Graf wrote:
>
> On 02.01.2014, at 16:31, Alexander Graf wrote:
>
>>
>> On 18.10.2013, at 14:33, Nathan Whitehorn wrote:
>>
>>> Intercept REPORT_LUNS commands addressed either to SRP LUN 0 or the
>>> well-known
>>> LUN for REPORT_LUNS commands. This is r
can simply be specified by an url of the form:
>> nfs:
>>
>> For example:
>> qemu-img create -f qcow2 nfs://10.0.0.1/qemu-images/test.qcow2
>>
>> You need LibNFS from Ronnie Sahlberg available at:
>> git://github.com/sahlberg/libnfs.git
>> f
Looks good.
Reviewed-by: Ronnie Sahlberg
On Fri, Dec 20, 2013 at 1:02 AM, Peter Lieven wrote:
> if an async libiscsi call fails directly it can only be due
> to an out of memory condition. All other errors are returned
> through the callback.
>
> Signed-off-by: Peter Lieven
The sync calls uses a trivial eventloop built into libnfs using poll().
Mixing the _async() and _sync() interfaces in libnfs means you may
risk running nested eventloops. Pain and tears lie behind that door.
On Fri, Dec 20, 2013 at 6:43 AM, Peter Lieven wrote:
> On 20.12.2013 15:38, Stefan Hajno
On Wed, Dec 18, 2013 at 9:42 AM, Peter Lieven wrote:
>
> Am 18.12.2013 um 18:33 schrieb ronnie sahlberg :
>
>> On Wed, Dec 18, 2013 at 8:59 AM, Peter Lieven wrote:
>>>
>>> Am 18.12.2013 um 15:42 schrieb ronnie sahlberg :
>>>
>>>> On Wed
On Wed, Dec 18, 2013 at 8:59 AM, Peter Lieven wrote:
>
> Am 18.12.2013 um 15:42 schrieb ronnie sahlberg :
>
>> On Wed, Dec 18, 2013 at 2:00 AM, Orit Wasserman wrote:
>>> On 12/18/2013 01:03 AM, Peter Lieven wrote:
>>>>
>>>>
>>>&
On Wed, Dec 18, 2013 at 2:00 AM, Orit Wasserman wrote:
> On 12/18/2013 01:03 AM, Peter Lieven wrote:
>>
>>
>>
>>> Am 17.12.2013 um 18:32 schrieb "Daniel P. Berrange"
>>> :
>>>
On Tue, Dec 17, 2013 at 10:15:25AM +0100, Peter Lieven wrote:
This patch adds native support for accessing image
On Tue, Dec 17, 2013 at 2:36 PM, Peter Lieven wrote:
>
>
>> Am 17.12.2013 um 18:13 schrieb ronnie sahlberg :
>>
>>> On Tue, Dec 17, 2013 at 9:03 AM, Peter Lieven wrote:
>>> On 17.12.2013 17:47, Stefan Hajnoczi wrote:
>> ...
>>>> Which
On Tue, Dec 17, 2013 at 9:03 AM, Peter Lieven wrote:
> On 17.12.2013 17:47, Stefan Hajnoczi wrote:
>>
>> On Tue, Dec 17, 2013 at 10:15:25AM +0100, Peter Lieven wrote:
...
>>> +if (nfs_pwrite_async(client->context, client->fh,
>>> + sector_num * BDRV_SECTOR_SIZE,
>>> +
On Tue, Dec 17, 2013 at 9:03 AM, Peter Lieven wrote:
> On 17.12.2013 17:47, Stefan Hajnoczi wrote:
...
>> Which NFS protocol versions are supported by current libnfs?
>
> Will check that out. Ronnie?
>
It uses NFS v3 only.
S Images can simply be specified by an url of the form:
> nfs:
>
> For example:
> qemu-img create -f qcow2 nfs://10.0.0.1/qemu-images/test.qcow2
>
> You need libnfs from Ronnie Sahlberg available at:
>git://github.com/sahlberg/libnfs.git
> for this to work.
>
> Durin
; For example:
> qemu-img create -f qcow2 nfs://10.0.0.1/qemu-images/test.qcow2
>
> You need libnfs from Ronnie Sahlberg available at:
>git://github.com/sahlberg/libnfs.git
> for this to work.
>
> During configure it is automatically probed for libnfs and support
> is
s can simply be specified by an url of the form:
> nfs:
>
> For example:
> qemu-img create -f qcow2 nfs://10.0.0.1/qemu-images/test.qcow2
>
> You need libnfs from Ronnie Sahlberg available at:
>git://github.com/sahlberg/libnfs.git
> for this to work.
>
> Durin
That means the initiator will do the "split into smaller manageable
chunks" for you and you get a 1-to-1 mapping between WS10/16 that the
initiator issues to qemu and the write-same calls that qemu generates.
On Tue, Nov 19, 2013 at 9:23 AM, ronnie sahlberg
wrote:
> +#define SCSI_W
+#define SCSI_WRITE_SAME_MAX 524288
...
+data->iov.iov_len = MIN(data->nb_sectors * 512, SCSI_WRITE_SAME_MAX);
I don't think you should just clamp the data to 512k, instead I think
you should report the 512k max write same size through
BlockLimitsVPD/MaximumWriteSameLength to the init
It would mean that any version of libiscsi from 1.1 or later would
work and there would not be the issues such as
UNMAP is only available from 1.2 and forward, WRITESAME* is only
availabel from 1.3.
SANITIZE only being available from 1.9 ...
On Fri, Nov 8, 2013 at 9:52 AM, ronnie sahlberg
For better support for older versions of libiscsi
I think it would be good to convert all the
iscsi_unmap_task/iscsi_writesame*_task/iscsi_*_task functions with
calls to the much more genric iscsi_scsi_command_sync().
iscsi_scsi_command_sync() and iscsi_scsi_command_async() have been
available s
On Fri, Jul 19, 2013 at 6:49 AM, Peter Lieven wrote:
> On 19.07.2013 15:25, ronnie sahlberg wrote:
>>
>> On Thu, Jul 18, 2013 at 11:08 PM, Peter Lieven wrote:
>>>
>>> On 19.07.2013 07:58, Paolo Bonzini wrote:
>>>>
>>>> Il 18/07/2013 2
On Thu, Jul 18, 2013 at 11:43 AM, Peter Lieven wrote:
>
> Am 18.07.2013 um 16:35 schrieb Paolo Bonzini :
>
>> Il 18/07/2013 16:32, Peter Lieven ha scritto:
>
(Mis)alignment and granularity can be handled later. We can ignore them
for now. Later, if we decide the best way to support
On Thu, Jul 18, 2013 at 11:08 PM, Peter Lieven wrote:
> On 19.07.2013 07:58, Paolo Bonzini wrote:
>>
>> Il 18/07/2013 21:28, Peter Lieven ha scritto:
>>>
>>> thanks for the details. I think to have optimal performance and best
>>> change for unmapping in qemu-img convert
>>> it might be best to ex
BlockLimitsVPD OptimalUnmapGranularity also applies to unmapping with
writesame16 :
An OPTIMAL UNMAP GRANULARITY field set to a non-zero value indicates
the optimal granularity in logical blocks
for unmap requests (e.g., an UNMAP command or a WRITE SAME (16)
command with the UNMAP bit set to
one)
On Thu, Jul 18, 2013 at 6:29 AM, Peter Lieven wrote:
> On 18.07.2013 14:31, Paolo Bonzini wrote:
>>
>> Il 18/07/2013 13:04, Peter Lieven ha scritto:
But if you set BDRV_DISCARD_WRITE_ZEROES, then you always need a
fallback to bdrv_write_zeroes. Why not just call bdrv_write_zeroes t
On Wed, Jul 17, 2013 at 10:02 AM, Peter Lieven wrote:
> For Disks we always use read/write16 so i think we Should also use
> writesame16. Or not?
Sounds good.
>
> Von meinem iPhone gesendet
>
> Am 17.07.2013 um 18:31 schrieb ronnie sahlberg :
>
>> On Wed, Jul
On Wed, Jul 17, 2013 at 9:27 AM, Paolo Bonzini wrote:
> Il 17/07/2013 17:54, ronnie sahlberg ha scritto:
>> I think it is reasonable to assume that IF LBPRZ==1 and IF it is an
>> "optimal unmap request" then the blocks will become unmapped and they
>> will read ba
is (n * OUG) + UGA and that the number of blocks
is a multiple of OUG then you should be fine.
Those unmaps should not silently fail.
I think it is reasonable to assume that IF LBPRZ==1 and IF it is an
"optimal unmap request" then the blocks will become unmapped and they
will
read back as 0.
(
Using this check should also make it safe with UNMAP for 4k block
devices that emulate 512b blocks.
Those devices should report OUG==8 accordingly so you dont need to
check what LogicalBlocksPerPhysicalBlockExponent is.
)
regards
ronnie sahlberg
itesame16 and sent a zero block. this would
> allow
> an optimization also if lbprz == 0. in this case i would not set the unmap
> bit.
>
> peter
>
>
> Am 05.07.2013 um 09:11 schrieb ronnie sahlberg :
>
>> The device MIGHT map or anchor the blocks after the unma
The device MIGHT map or anchor the blocks after the unmap but it may
only do so if the blocks that become mapped are all zero.
So I think you can safely assume that if lbprz==1 then it will always
read back as zero no matter what happens internally in the target.
Either the block becomes unmapp
max_unmap :
If the target does not return an explicit limit for max_unmap it will
return 0x which means "no limit".
I think you should add a check for max_unmap and clamp it down to
something sane.
Maybe a maximum of 128M ?
Same for bdc, that should also be checked and clamped down to sa
Don't assume that SG_IO is always invoked with a simple buffer,
check the iovec_count and if it is >= 1 then we need to pass an array
of iovectors to libiscsi instead of just a plain buffer.
Signed-off-by: Ronnie Sahlberg
---
block/iscsi.
List,
Please find a new version of the patch to fix the iSCSI crash when ioctl with
iovector is sent.
Updated to fix the commit message as per lerseks suggestion.
Also added an explicit cast to suppress a compiler warning when we dont have
iovector support available.
Don't assume that SG_IO is always invoked with a simple buffer,
check the iovec_count and if it is > 1 then we need to pass an array
of iovectors to libiscsi instead of just a plain buffer.
Signed-off-by: Ronnie Sahlberg
---
block/iscsi.
.
If not we fall back to either lots of datain buffers or a serialization dataout
buffer.
regards
ronnie sahlberg
On Fri, Jun 21, 2013 at 10:06 AM, Peter Lieven wrote:
> Am 21.06.2013 18:31, schrieb Paolo Bonzini:
>> Il 21/06/2013 13:07, Kevin Wolf ha scritto:
>>> Note that you're blocking here. The preferred way would be something
>>> involving a yield from the coroutine and a reenter as soon as all
Should we really mix co-routines and AIO in the same backend?
Would it not be better to instead add a new bdrb_aio_is_allocaed and
use non-blocking async calls to libiscsi ?
On Fri, Jun 21, 2013 at 2:18 AM, Kevin Wolf wrote:
> Am 20.06.2013 um 20:20 hat Peter Lieven geschrieben:
>> Signed-off-b
I can add the checks and resubmit.
On Fri, Jun 21, 2013 at 12:38 AM, Paolo Bonzini wrote:
> Il 21/06/2013 04:32, Ronnie Sahlberg ha scritto:
>> Stefan, List
>>
>> Please find a patch that fixes the crashes for using virtio with libiscsi.
>> The problem was that bloc
Don't assume that SG_IO is always invoked with a simple buffer,
check the iovec_count and if it is > 1 then we need to pass an array
of iovectors to libiscsi instead of just a plain buffer.
Signed-off-by: Ronnie Sahlberg
---
block/iscsi.c | 31 ---
1 files
against a current libiscsi.
I will send patches later to remove the current (LIBISCSI_FEATURE_IOVECTOR)
checks in the rest of the file.
regards
ronnie sahlberg
On Thu, Jun 20, 2013 at 7:47 AM, Laszlo Ersek wrote:
> On 06/20/13 15:33, ronnie sahlberg wrote:
>> http://pastebin.com/EuwZPna1
>>
>> Last few thousand lines from the log with your patch.
>>
>>
>> The crash happens immediately after qemu has called out t
comment out SG_IO in iscsi_ioctl then the crash does not happen
(but the qemu does nto get serial number either)
I will look more into it tonight.
On Wed, Jun 19, 2013 at 2:17 AM, Laszlo Ersek wrote:
> On 06/19/13 06:34, ronnie sahlberg wrote:
>> I can reproduce with current QEMU.
>&g
I can reproduce with current QEMU.
Ubuntu 13 crashes with if=virtio but if=ide is fine.
But it seems dependent on the guest/kernel.
For example Fedora-18-x86_64-Live-Desktop.iso installs and runs just
fine, even with virtio
But both ubuntu-12.04-desktop-amd64.iso or
ubuntu-13.04-desktop-amd64.
Julian,
Stefan's concerns are valid.
(Hopefully, kernel is harder to exploit and more carefully audited.)
On Wed, May 29, 2013 at 9:02 AM, Julian Stecklina
wrote:
> On 05/29/2013 04:21 PM, Stefan Hajnoczi wrote:
>> The fact that a single switch process has shared memory access to all
>> gues
box with QEMU right now,
but I would check if it is something similar to this patch :
http://lists.gnu.org/archive/html/qemu-devel/2012-04/msg04130.html
regards
ronnie sahlberg
On Mon, Apr 8, 2013 at 8:53 AM, Stefan Hajnoczi wrote:
> On Fri, Apr 05, 2013 at 11:30:00AM -0700, Venkat
Even more efficient might be to do bitwise instead of logical or
>if (tmp | d1 | d2 | d3) {
that should remove 3 of the 4 conditional jumps
and should become 3 bitwise ors and one conditional jump
On Mon, Mar 11, 2013 at 8:58 AM, Paolo Bonzini wrote:
> Il 11/03/2013 16:37, Peter Lieven
On Wed, Jan 2, 2013 at 11:18 AM, Troy Benjegerdes wrote:
> If you do get a hash collision, it's a rather exceptional event, so I'd
> say every effort should be made to log the event and the data that created
> it in multiple places.
>
> There are three questions I'd ask on a hash collision:
>
> 1)
Do you really need to resolve the conflicts?
It might be easier and sufficient to just flag those hashes where a
conflict has been detected as : "dont dedup this hash anymore,
collissions have been seen."
On Wed, Jan 2, 2013 at 10:40 AM, Benoît Canet wrote:
> Le Wednesday 02 Jan 2013 à 12:26:37
Acked-By: ronniesahlb...@gmail.com (Ronnie Sahlberg)
This verified that the service is actually operational and is much
more reliable than TCP-KEEPALIVES.
This is the proper way to monitor that the iscsi target is alive.
We should as a later patch add the ability to configure this via the
qemu
On Mon, Nov 19, 2012 at 7:18 AM, Paolo Bonzini wrote:
> Il 19/11/2012 15:58, Peter Lieven ha scritto:
>>
>> -/* XXX we should pass the iovec to write16 to avoid the extra copy */
>> -/* this will allow us to get rid of 'buf' completely */
>> size = nb_sectors * BDRV_SECTOR_SIZE;
>> -
On Thu, Nov 15, 2012 at 7:54 AM, Paolo Bonzini wrote:
> Il 15/11/2012 15:57, ronnie sahlberg ha scritto:
>> I dont know if we should switch to use synchronous code here.
>> It is much nicer if all code is async.
>
> bdrv_open is generally synchronous, so I think Peter&
I dont know if we should switch to use synchronous code here.
It is much nicer if all code is async.
Is it possible to add a timeout instead that would break out if the
connect/login has not completed within a certain amount of time?
regards
ronnie sahlberg
On Thu, Nov 15, 2012 at 6:50 AM
Acked-By: ronniesahlb...@gmail.com
On Thu, Nov 15, 2012 at 6:42 AM, Peter Lieven wrote:
> If an invalid URL is specified iscsi_get_error(iscsi) is called
> with iscsi == NULL.
>
> Signed-off-by: Peter Lieven
> ---
> block/iscsi.c |3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
>
On Tue, Oct 30, 2012 at 10:48 PM, Stefan Hajnoczi wrote:
> On Tue, Oct 30, 2012 at 10:09 PM, ronnie sahlberg
> wrote:
>> About half a year there was an issue where recent kernels had added
>> support to start using new scsi opcodes, but the qemu functions that
>> d
be this is something
similar ? I.e. does the guest send an "unusual" scsi opcode just
before the crash ?
regards
ronnie sahlberg
On Tue, Oct 30, 2012 at 12:37 PM, Peter Lieven wrote:
> Am 30.10.2012 19:27, schrieb Stefan Hajnoczi:
>
>> On Tue, Oct 30, 2012 at 4:56 PM,
On Thu, Oct 25, 2012 at 6:58 AM, Paolo Bonzini wrote:
> Il 25/10/2012 15:41, ronnie sahlberg ha scritto:
>> On Thu, Oct 25, 2012 at 1:02 AM, Kevin Wolf wrote:
>>> Am 25.10.2012 09:52, schrieb Paolo Bonzini:
>>>> Il 25/10/2012 09:46, Kevin Wolf ha scritto:
>>
already preexisting luns.
In that case I think requiring a .bdrv_create feels wrong. We are not
creating a new LUN here but just opening an already existing LUN.
What about changing bdrv_create() so that IF there is no .bdrv_create
method, then assume it might be a pre-existing file in which case we
fallback to use .bdrv_open instead.
regards
ronnie sahlberg
the scope of this standard.
Signed-off-by: Ronnie Sahlberg
---
hw/scsi-disk.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c
index 1585683..52bc062 100644
--- a/hw/scsi-disk.c
+++ b/hw/scsi-disk.c
@@ -678,7 +678,7 @@ static
Paolo, List
Please find a trivial patch that make SCSI-DISK set the HISUP bit in the INQ
data.
Since I think all LUN numbers are reported as SAM4 describes, we should set
this bit.
Its already sed in SCSI-BUS
regards
ronnie sahlberg
ping?
On Thu, Aug 30, 2012 at 5:28 PM, Ronnie Sahlberg
wrote:
> We need to support SG_IO from the synchronous iscsi_ioctl() since
> scsi-block uses this to do an INQ to the device to discover its properties
> This patch makes scsi-block work with iscsi.
>
> Signed-off-by:
Ping?
On Thu, Aug 30, 2012 at 4:56 PM, Ronnie Sahlberg
wrote:
> We no longer need to explicitely call qemu_notify_event() any more since this
> is now done automatically any time the filehandles we listen to change.
>
> Signed-off-by: Ronnie Sahlberg
> ---
> block/iscsi.c
ll gross. URIs already have a well defined way to provide
> multiple parameters, dealing with escaping of special characters. ie query
> parameters. The whole benefit of using URI syntax is to let apps process
> the URIs using standard APIs. We should not be trying to define some extra
> magic encoding to let us stuff 2 separate parameters into the path
> component
> since that means apps have to now write custom parsing code again. Either
> the UNIX socket path, or the volume path should be in the URI path, not
> both. The other part should be a URI parameter. I'd really expect us to
> use:
>
> gluster:///volname/image?transport=unix&sockpath=/path/to/unix/sock
>
>
+1
ronnie sahlberg
We need to support SG_IO from the synchronous iscsi_ioctl() since
scsi-block uses this to do an INQ to the device to discover its properties
This patch makes scsi-block work with iscsi.
Signed-off-by: Ronnie Sahlberg
---
block/iscsi.c | 20 +++-
1 files changed, 19 insertions
Paolo, List
Please find a small patch that adds support for SG_IO to the synchronous
iscsi_ioctl() function.
This is needed to make scsi-block work with iscsi.
regards
ronnie sahlberg
We no longer need to explicitely call qemu_notify_event() any more since this
is now done automatically any time the filehandles we listen to change.
Signed-off-by: Ronnie Sahlberg
---
block/iscsi.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/block/iscsi.c b
Paolo, List
Please find a trivial patch to iscsi that removes the call to
qemu_notify_event()
We do not need to call this any more since a recent patch that made
qemu_aio_set_fd_handler() and friends invoke this call automatically when
required.
regards
ronnie sahlberg
In
net_socket_update_fd_handler()
shouldnt you call qemu_notify_event() if any of the handlers have
changed from NULL to non-NULL ?
or else it might take a while before the change takes effect.
regards
ronnie sahlberg
On Wed, Aug 22, 2012 at 1:52 AM, Stefan Hajnoczi
wrote:
> The net/socke
We need to support SG_IO in the synchronous bdrv_ioctl() since this
is used by scsi-block
Signed-off-by: Ronnie Sahlberg
---
block/iscsi.c | 109 -
1 files changed, 108 insertions(+), 1 deletions(-)
diff --git a/block/iscsi.c b/block
adding support for SG_IO to iscsi_ioctl() this makes scsi-block and
scsi-disk work too.
Since scsi-block/scsi-disk never worked with iscsi, and only scsi-generic
worked, this is not a new regression. So whether this should go in now or wait
until post 1.2 is for your disgression.
regards
ronnie
On Mon, Aug 20, 2012 at 6:12 PM, Stefan Priebe - Profihost AG
wrote:
> Hi Ronnie,
>
> Am 20.08.2012 10:08, schrieb Paolo Bonzini:
>
>> That's because the "big QEMU lock" is held by the thread that called
>> qemu_aio_cancel.
>>
>>> and i also see
>>> no cancellation message in kernel log.
>>
>>
>>
On Sun, Aug 19, 2012 at 8:20 AM, Paolo Bonzini wrote:
> Il 19/08/2012 00:02, ronnie sahlberg ha scritto:
>> On Sun, Aug 19, 2012 at 7:58 AM, Paolo Bonzini wrote:
>>> Il 17/08/2012 04:36, Ronnie Sahlberg ha scritto:
>>>> There is no bdrv_* API for the commands for bu
On Sun, Aug 19, 2012 at 8:16 AM, Paolo Bonzini wrote:
> Il 19/08/2012 00:02, ronnie sahlberg ha scritto:
>> Neither of them work, basically because in
>> block.c:find_image_format()
>>
>> if bs->sg is not set in
>>
>> if (bs->sg || !bdrv_is_inserted
1 - 100 of 289 matches
Mail list logo
