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@xxxxxxxxxx> --- 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
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list