[virt-tools-list] [virt-manager PATCH] Allow installation of i686 guests on x86_64 machines
Martin Kletzander
mkletzan at redhat.com
Sat Mar 3 21:41:07 UTC 2018
On Sat, Mar 03, 2018 at 04:21:37PM -0500, Cole Robinson wrote:
>On 03/03/2018 04:03 PM, Martin Kletzander wrote:
>> On Sat, Mar 03, 2018 at 03:53:59PM -0500, Cole Robinson wrote:
>>> On 03/01/2018 03:52 AM, Martin Kletzander wrote:
>>>> Do that by changing the code that was disabling it into code that
>>>> just warns in
>>>> such case.
>>>>
>>>> Signed-off-by: Martin Kletzander <mkletzan at redhat.com>
>>>> ---
>>>> virtManager/create.py | 10 ++++------
>>>> 1 file changed, 4 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/virtManager/create.py b/virtManager/create.py
>>>> index 0a73309372d9..9a40aec4a068 100644
>>>> --- a/virtManager/create.py
>>>> +++ b/virtManager/create.py
>>>> @@ -495,6 +495,10 @@ class vmmCreate(vmmGObjectUI):
>>>> msg = _("Failed to setup UEFI for AArch64: %s\n"
>>>> "Install options are limited.") % e
>>>> self._show_arch_warning(msg)
>>>> + elif (self._capsinfo.arch == "i686" and
>>>> + self.conn.caps.host.cpu.arch == "x86_64"):
>>>> + msg = _("You are installing 32bit guest on 64bit host")
>>>> + self._show_arch_warning(msg)
>>>>
>>>> # Install Options
>>>> method_tree = self.widget("method-tree")
>>>> @@ -824,12 +828,6 @@ class vmmCreate(vmmGObjectUI):
>>>> if guest.os_type == self._capsinfo.os_type:
>>>> archs.append(guest.arch)
>>>>
>>>> - # Combine x86/i686 to avoid confusion
>>>> - if (self.conn.caps.host.cpu.arch == "x86_64" and
>>>> - "x86_64" in archs and "i686" in archs):
>>>> - archs.remove("i686")
>>>> - archs.sort()
>>>> -
>>>> prios = ["x86_64", "i686", "aarch64", "armv7l", "ppc64",
>>>> "ppc64le",
>>>> "s390x"]
>>>> if self.conn.caps.host.cpu.arch not in prios:
>>>>
>>>
>>> The idea behind hiding the option is 1) it should be rare that someone
>>> actually wants their VM to present a 32bit cpu on 64bit host, 2) hiding
>>> it means when only x86_64 qemu is installed we can entirely hide the
>>> 'advanced options' expander.
>>>
>>> Example: on rhel7 x86_64, libvirt advertises arch=i686 and arch=x86_64
>>> for /usr/libexec/qemu-kvm. If we hide i686, there's only one arch option
>>> available, and virt-manager will hide the entire 'advanced options'
>>> expander. This is ideal IMO, otherwise users might go clicking, see the
>>> i686 option, misinterpret it to mean OS arch (which in the context of
>>> virt I've seen people mistake many times), set things to i686 needlessly.
>>>
>>
>> Sure I get that, that's why I kept it as a warning.
>>
>>> Are there benefits I'm missng of doing arch=i686 on an x86_64 host
>>> exactly? Doesn't it just map to using qemu32 as the default CPU?
>>>
>>
>> To be honest, I'm not sure if qemu32 CPU type means also 32bit CPU or
>> just limited instruction set and how it looks from the guest OS POV.
>> The reason for this patch emerged simply when we needed to test libvirt
>> build failure on 32bit machine and it was just easier to install 32bit
>> VM than setting up a cross-build. Or rather installing all 32bit
>> dependencies properly. I'd love to hear how to do this properly, I'm
>> not saying this patch is needed =)
>
>I think this is an example of that arch confusion actually. You can
>install a 32 bit OS into a 64 bit machine, doesn't matter if the CPU is
>x86_64, and building in that should reproduce the 32bit build error
>
>So in this case if i686 was a selectable option it would have just given
>you worse performance since we would have used model=qemu32 implicitly
>rather than virt-manager's default of a more modern CPU (the model we
>get out of host capabilities output)
>
Oh, sure you can do that, but that's in case the boot "medium" is not trying to
guess what kernel to boot. But I understand that's a niche and that doesn't
occur with many distributions.
Thanks for info ;)
>- Cole
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/virt-tools-list/attachments/20180303/ee195df2/attachment.sig>
More information about the virt-tools-list
mailing list