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 :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list