qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] How to handle feature regressions in new QEMU rel


From: Peter Lieven
Subject: Re: [Qemu-devel] [RFC] How to handle feature regressions in new QEMU releases
Date: Wed, 16 Jul 2014 19:36:20 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0

Am 16.07.2014 19:23, schrieb ronnie sahlberg:
> On Wed, Jul 16, 2014 at 10:11 AM, Stefan Weil <address@hidden> 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 configure will disable libiscsi.
>>> That's a packaging bug.
>> CC'ing Michael as he is the Debian maintainer of this package and
>> Aurélien who maintains QEMU for Debian.
>>
>> Michael, should I send a Debian bug report for libiscsi-dev? Would an
>> update of libiscsi for Debian stable be reasonable if versions older
>> than 1.9 are too buggy to be used?
> 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?

If someone from Ubuntu reads here, this is also for you. Your latest
LTS release does also contain 1.4.0.

>
> It contains new functionality, thanks to plieven, to better handle
> cases where active/passive storage arrays
> perform failover.

Yes and it fixes yet another bug in serial logic. Not a big one, but it
could cause protocol errors.

>
>
>> I must admit that I'm a little bit
>> surprised because iSCSI support worked for me quite well the last time I
>> used it with Debian wheezy.
> I think, and plieven please correct me if I am wrong, earlier version
> would work reasonably well for basic use
> but there were bugs and gaps in functionality that made it ill suited
> for enterprise environments.

It depends how you define basic use. It causes severe protocol violations 
especially
on reconnects and it will simply stop sending PDUs if CmdSN wraps from 
0xffffffff to 0x0.
Thats ok for try and mount an iSCSI volume and see if it works, but its
not usable for production use enterprise or not.

I mentioned the most critical bugs in the commit message to the libiscsi
version bump to 1.8.0 (which Paolo later increased to 1.9.0 to make the
BUSY handling possible).

Peter



reply via email to

[Prev in Thread] Current Thread [Next in Thread]