Re: Question about hypervisor <features> that are not tristate

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

 



On 01/06/2017 05:31 PM, Jim Fehlig wrote:

Adding xen-devel for a question below...

Happy new year!

Nearly a year ago I reported an issue with the <hap> hypervisor feature on Xen
[1] and am now seeing a similar issue with the <pae> feature. Setting the
default value of pae changed between xend and libxl. When not specified, xend
would enable pae for HVM domains. Clients such as xm and the old libvirt driver
did not have to explicitly enable it. In libxl, the pae field within
libxl_domain_build_info is initialized to 0. Clients must enable pae, and indeed
xl will do so if pae=1 is not specified in the xl.cfg.

The xend behavior prevents libvirt from disabling pae, whereas the libxl behvior
causes a guest ABI change (config that worked with libvirt+xend doesn't with
libvirt+libxl). The libxl behavior also forces management software (e.g.
OpenStack nova) to add <pae> where it wasn't needed before.

To solve this problem for <hap>, it was changed it to a tristate [2], allowing
it to be turned off with explicit <hap state='off'/>, and on if not specified or
<hap/> or <hap state='on'/>. Should <pae> (and the remaining hypervisor features
that are not tristate) be converted to tristate similar to <hap>? Alternatively,
I could simply set pae=1 for all HVM domains in the libxl driver. Like the old
libvirt+xend behavior it couldn't be turned off, but I don't think there is a
practical use-case to do so. At least no one has complained over all the years
of libvirt+xend use.

Xen folks, what is your opinion of always enabling pae for HVM domains in the libvirt libxl driver? Is there a need these days to disable it?

Jan had mentioned that some old, buggy guest OS's (Win 9x) might need it disabled, and perhaps some cases where it may be desirable to suppress a guest OS entering 64-bit mode. But in practice do you think it is necessary to expose this knob to users?

Thanks for your comments!

Regards,
Jim

[1] https://www.redhat.com/archives/libvir-list/2016-February/msg00197.html
[2] https://www.redhat.com/archives/libvir-list/2016-March/msg00001.html

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]
  Powered by Linux