On Wed, Mar 30, 2016 at 12:05:28PM +0300, Maxim Nestratov wrote:
> 30.03.2016 10:50, Pavel Hrdina пишет:
> > On Tue, Mar 29, 2016 at 07:06:14PM +0300, Maxim Nestratov wrote:
> >> 29.03.2016 16:31, Pavel Hrdina пишет:
> >>> Commit 7068b56c introduced several hyperv features. Not all hyperv
> >>> features are supported by old enough kernels and we shouldn't allow to
> >>> start a guest if kernel doesn't support any of the hyperv feature.
> >>>
> >>> There is one exception, for backward compatibility we cannot error out
> >>> if one of the RELAXED, VAPIC or SPINLOCKS isn't supported, for the same
> >>> reason we ignore invtsc, to not break restoring saved domains with older
> >>> libvirt.
> >>>
> > [...]
> >
> >> Hmm, qemu already checks them and simply ignores most of them and
> >> doesn't prevent guest from starting in case they are not supported and
> >> optional. In case they are reqired it fails. Why should we check them
> >> here? At least we should follow the logic qemu has.
> > Yes, that's true that QEMU do some checks and ignores most of the features
> > missing in kernel, but that's no reason why we should do the same. Libvirt
> > tries to present in domain XML only those features and devices that are actually
> > present in the guest. Thus if you tell libvirt that you want some hyperv
> > feature but your host kernel doesn't support it, we should let the user know
> > that this feature isn't supported instead of ignoring that fact and start the
> > guest anyway.
> >
> > Pavel
> I see your point. And what if a user wants to define some features just
> to ask libvirt/qemu to do its best if possible and ignore if it isn't
> without redefining domain xml? Does such case make sense?
>
> Maxim
Sure, this makes sense and we do this for cpu features [1], for example:
<feature policy='optional' name='lahf_lm'/>
But I'm not that sure whether we want to do this also for guest features like
those hyperv features. If your guest OS is Windows you probably want to know
what features are supported and to be sure, that all of the specified features
are enabled.
[1] http://libvirt.org/formatdomain.html#elementsCPU
Pavel
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list