On Wed, Jul 24, 2013 at 11:12:18AM +0800, Osier Yang wrote:
On 24/07/13 01:11, Paolo Bonzini wrote:
>Il 23/07/2013 18:47, John Ferlan ha scritto:
>>On 07/23/2013 12:18 PM, Paolo Bonzini wrote:
>>>Il 23/07/2013 18:01, Daniel P. Berrange ha scritto:
>>>>On Tue, Jul 23, 2013 at 05:35:57PM +0200, Paolo Bonzini wrote:
>>>>>Il 23/07/2013 16:14, Daniel P. Berrange ha scritto:
>>>>>>>>Perhaps the default could be specified in a configuration
file (and the
>>>>>>>>default should be the safe one).
>>>>>>No, that is even worse because now the default is not
predictable..
>>>>>>
>>>>>>We simply default to host mode and if applications want to use
the
>>>>>>other mode they can configure the XML as desired.
>>>>>Can we just forbid mode='default' for iSCSI and force the
user to
>>>>>specify host vs. direct?
>>>>That would mean that apps cannot simply configure a guest volume
>>>>without first checking to find out what type of pool it is, and
>>>>then specifying this extra arg for iSCSI. IMHO the value of the
>>>><volume> XML is that you don't have to know anything about the
>>>>pool to be able to configure it - we're completely decoupled.
>>>Thinking more about it, it would only be needed for <disk
type='volume'
>>>device='lun'>. And for that case, some knowledge of the pool is
>>>necessary anyway (for one thing, it won't work with filesystem or LVM
>>>pools). So if we could forbid mode='default' for that case only, it
>>>would be enough as far as I'm concernde.
>>Using "default" in the mode field would result in the following XML
>>error message (I just quickly changed a test to prove the point):
>>
>>121) QEMU XML-2-XML disk-source-pool-mode
>>... libvirt: Domain Config error : XML error: unknown source mode
>>'default' for volume type disk
>>FAILED
>Sorry, by mode='default' I really meant "no mode at all" (I was
under
>the false impression that you could also specify a mode='default' with
>the same effect as no mode at all).
>
>>The XML parsing code only looks for "mode='direct'" or
"mode='host'". If
>>"mode" isn't present in the XML, that's when that default comes
into
>>play. Since 'mode' is new there could be configurations where its not in
>>an XML file, thus a 0 (zero e.g. "default") value is provided for the
field.
>>
>>Once the XML is parsed we still needed a default when it's going to be
>>added, thus the "magic" to set the default to HOST is in qemu_conf.c
in
>>qemuTranslateDiskSourcePool():
>>
>>
>> if (pooldef->type == VIR_STORAGE_POOL_ISCSI) {
>> /* Default to use the LUN's path on host */
>> if (!def->srcpool->mode)
>> def->srcpool->mode = VIR_DOMAIN_DISK_SOURCE_POOL_MODE_HOST;
>>
>>
>>I think this answers your primary concern - correct?
>No, my concern is that mode='host' is a bad default for the
device='lun'
>case.
>
after going through the thread......
i think the point is the relationship between the "host" and "direct"
mode.
if users used the "host" mode in the past, but most of them suffered from
the persistent reservatioins, and "direct" mode is the answer for them, then
i indent to agree with paolo that defaulting to "direct" is better.
if they used the "host" mode broadly, but persistent reservation is just
requirement of a small part of the users. then i don't see any problem to
default to "host" mode.
i.e. the point is if "direct" mode is the answer for "host" mode.
but anyway, we provide good enough documentations, so if one wants to
use "direct" mode, he can still change the xml to use it, any big problems
here? though defaulting to "direct" is more convenient for these users.
Defaulting to "direct" is *NOT* more convenient for all users, only
those who happen to have a new enough QEMU, from a vendor who actually
decided to compile in the iSCSI support. If they're lacking such a QEMU
then the "direct" mode will prevent the default config from even starting.
This can never be an acceptable default choice. mode="host", while it huas
some limitations in features, is the only option that is capable of working
with any QEMU
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|