Il 23/07/2013 16:14, Daniel P. Berrange ha scritto:
On Tue, Jul 23, 2013 at 03:52:56PM +0200, Paolo Bonzini wrote:
> Il 23/07/2013 15:36, Daniel P. Berrange ha scritto:
>> On Tue, Jul 23, 2013 at 03:29:40PM +0200, Paolo Bonzini wrote:
>>> Il 23/07/2013 15:26, Daniel P. Berrange ha scritto:
>>>>>>
>>>>>> Ok, this answers my question. :)
>>>>>>
>>>>>> I think the default mode should be direct, because otherwise
things such
>>>>>> as persistent reservations do not work.
>>>> No, the default has to be host mode, because that is the only mode that
>>>> is guaranteed to be usable with any QEMU. The direct mode requires a
>>>> QEMU that is new enough, and a distro to have enabled it. We can't
>>>> rely on that as a default choice.
>>>
>>> Volume sources are also new enough that you can assume a good QEMU.
>>
>> No we can't assume that. New libvirt is frequently used with old QEMU
>> and we want to have good default behaviour there.
>
> New libvirt, yes. But can't new libvirt features also assume a new QEMU
> if the old one causes more trouble than anything?
I've no problem with new features requiring new QEMU but that's not
the issue here. This is a question about what the default configuration
should be. For default configuration we aim for maximum compatibility
not the latest possible features.
Shouldn't default configuration be simply "what makes the most sense"?
> If you use host mode and the guest issues reservation commands,
you may
> get data corruption. That is the brokenness.
So be it, that's been the case for every version of libvirt and QEMU
in existance up until iscsi protocol support was added, so it is not
a new issue. That doesn't justify choosing a default that is guaranteed
to not work at all.
I started adding iSCSI support to ensure that iSCSI LUNs would work.
This makes them _not_ work by default. It makes me regret asking to add
support for volumes as a disk source.
Paolo