Need help with installing guest via virt-install

[F_style]

After hours of breaking my head and reading the docs and many articles, I saw better to ask for help.

I need to create a Windows 10 guest with following characteristics:
–Use win10.iso
–attach also win-virtio.iso for the drivers
–arch=x86_64
–os-variant=win10
–memory: balloon 4 - 6 Gb
–no. of cpus=2
–disk: qcow 25 Gb
–graphic driver:qxl (intended for SPICE)
–disk driver: virtio
–network device: virbr0
–network driver: virtio
–boot: uefi

What would the command be for this?

So far I have:

virt-install --name win10 --memory 6144 --vcpus 2 --disk size=25 --disk win10.iso,device=cdrom --disk win-virtio.iso,device=cdrom --os-variant win10

But I’m clueless of how to specify the rest…

Could someone help please?

[nrickert]

I have not done any Windows installs.

Here is the command that I used a while ago (2017, I think). And I have been using that as a template for other installs:

virt-install --name efisolus --memory 4096 --vcpus 2 --disk size=20 --cdrom /shared/iso/solus/Solus-2017.04.18.0-Budgie.iso --boot loader=/usr/share/qemu/ovmf-x86_64-code.bin,loader_ro=yes,loader_type=pflash,nvram_template=/usr/share/qemu/ovmf-x86_64-vars.bin,loader_secure=no

For that case, the ovmf is for firmware without secure-boot. So you probably need to change that, and change the “pflash” part to match.

I think qxl is the default for graphic driver, so you probably won’t need to specify that.

[tsu2]

The virt-install command only indicates you’re using libvirt to manage… some virtualization technology.

So, besides identifying the virtualization you’re using,

1. Did you install virtualization the recommended way by using the YaST “Install Virtualization” module?
2. If your machine is installed with a GUI, is there some reason why you’d prefer to install by command line instead of using the GUI tools?

You may want to install your VM using the GUI and then modify the VM configuration file for simplicity,
But if you want to install by command line, I hesitate to reference current SUSE/LEAP documentation but here you go…

https://doc.opensuse.org/documentation/leap/virtualization/html/book.virt/cha-kvm-inst.html#sec-libvirt-inst-virt-install

Or, look up the last SLES11 SP4 virtualization documentation which I consider to be the last published with over 99% accurate information (my estimation). People may know that I’ve heavily criticized virtualization documentation since for mixing up definitions and concepts between Xen and KVM when terminology is often and significantly opposite each other. Skimming the above link quickly, I can see immediately that as expected continues to do this, and mentions options which apply only to Xen and not KVM without saying so. Just saying, you might use the documentation for a fix here or there, and there are some interesting nuggets of valuable information but I would not recommend someone new to virtualization to study it… Maybe less of a problem if the person was learning Xen, but would have to unlearn a large amount of info if learning KVM.

TSU

[malcolmlewis]

Hi
This is what I use to install Windows 10;

#!/bin/bash

#Create initial image via qemu-img create -f raw -o preallocation=full Win101909pt.raw  40G

qemu-system-x86_64 \
-m 8G \
-cpu host,kvm=off,hv_vendor_id=whatever \
-smp 4,sockets=1,cores=2,threads=2 \
-rtc clock=host,base=utc \
-serial none \
-parallel none \
-vga none \
-nographic \
-usb \
-device usb-host,vendorid=0x05af,productid=0x0808 \
-device vfio-pci,host=03:00.0 \
-device vfio-pci,host=03:00.1 \
-drive id=disk0,if=virtio,cache=none,format=raw,file=/var/lib/libvirt/images/Win101909pt.raw \
-drive file=/data/repositories/iso_images/Windows/Win10_1909_English_x64.iso,index=1,media=cdrom \
-drive file=/data/repositories/iso_images/Windows/virtio-win-0.1.173.iso,index=2,media=cdrom \
-drive if=pflash,format=raw,unit=0,file=/stuff/repositories/KVM_GPU_Passthrough/qemu_vars/ovmf-x86_64-ms-4m-code.bin,readonly=on \
-drive if=pflash,format=raw,unit=1,file=/stuff/repositories/KVM_GPU_Passthrough/qemu_vars/ovmf-x86_64-ms-4m-vars.bin \
-boot order=dc \
-machine type=pc-q35-4.0,accel=kvm,kernel_irqchip=on \
-nic tap,ifname=tap0,script=no,downscript=no

[tsu2]

Be aware that using the qemu command involves emulation which works differently than virtualization… virtualization is simply translating a HostOS functionality to a Guest functionality with little ability to modify. Emulation is a virtual device which might not have anything to do with what actually exists in the HostOS, and this is one of the unique features of qemu, to run anything from a particular type of hardware device(like a Cirrus video card which doesn’t likely exist anymore) to an entirely different architecture (like ARM when your hardware is x64).

qemu is therefor not as fast as running a fully paravirtualized KVM or Xen HVM which would be the result if you used native or libvirt commands to launch the VM.

TSU

[malcolmlewis]

@tsu2

Be aware that using the qemu command involves emulation which works differently than virtualization… virtualization is simply translating a HostOS functionality to a Guest functionality with little ability to modify. Emulation is a virtual device which might not have anything to do with what actually exists in the HostOS, and this is one of the unique features of qemu, to run anything from a particular type of hardware device(like a Cirrus video card which doesn’t likely exist anymore) to an entirely different architecture (like ARM when your hardware is x64).

qemu is therefor not as fast as running a fully paravirtualized KVM or Xen HVM which would be the result if you used native or libvirt commands to launch the VM.

TSU

Hi
That’s not the issue, whilst I use qemu, the point was to show the efi (two, not just one) files I use…

[tsu2]

@malcolmlewis

Hi
That’s not the issue, whilst I use qemu, the point was to show the efi (two, not just one) files I use…

OK,
The LEAP documentation link I provided above also describes how to set up UEFI, but using virt-install, whereupon you can use virsh to launch.

Using qemu is one of those things that’s important to know about, but should be avoided unless you can benefit from it.
At least, that’s the general recommendation… Of course if the slight latency which isn’t as bad as before integration with KVM can be tolerated, then it’s certainly not going to work.

TSU

[malcolmlewis]

@tsu2

OK,
The LEAP documentation link I provided above also describes how to set up UEFI, but using virt-install, whereupon you can use virsh to launch.

Using qemu is one of those things that’s important to know about, but should be avoided unless you can benefit from it.
At least, that’s the general recommendation… Of course if the slight latency which isn’t as bad as before integration with KVM can be tolerated, then it’s certainly not going to work.

TSU

Hi
Moving Off Topic a bit here, this is the boot time for my qemu openSUSE Leap 15.1 instance…

systemd-analyze 
Startup finished in 1.117s (kernel) + 1.291s (initrd) + 3.565s (userspace) = 5.975s

pinxi -FxxZ
System:    Host: grover-os151.homelinux.org Kernel: 4.12.14-lp151.28.36-default x86_64 bits: 64 compiler: gcc v: 7.4.1 
           Desktop: Gnome 3.26.2 wm: gnome-shell dm: GDM Distro: openSUSE Leap 15.1 
Machine:   Type: Vm-other System: QEMU product: Standard PC (Q35 + ICH9, 2009) v: pc-q35-4.0 serial: <root required> 
           Chassis: type: 1 v: pc-q35-4.0 serial: <root required> 
           Mobo: N/A model: N/A serial: N/A UEFI: EFI Development Kit II / OVMF v: 0.0.0 date: 02/06/2015 
CPU:       Topology: Dual Core model: Intel Xeon E3-1245 V2 bits: 64 type: MT MCP arch: Ivy Bridge rev: 9 
           L2 cache: 16.0 MiB 
           flags: avx lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 27138 
           Speed: 3392 MHz min/max: N/A Core speeds (MHz): 1: 3392 2: 3392 3: 3392 4: 3392 
Graphics:  Device-1: NVIDIA GK208B [GeForce GT 710] vendor: ZOTAC driver: nvidia v: 440.44 bus ID: 00:02.0 
           chip ID: 10de:128b 
           Display: x11 server: X.Org 1.20.3 driver: nvidia compositor: gnome-shell resolution: 1366x768~60Hz 
           OpenGL: renderer: GeForce GT 710/PCIe/SSE2 v: 4.6.0 NVIDIA 440.44 direct render: Yes 
Audio:     Device-1: NVIDIA GK208 HDMI/DP Audio vendor: ZOTAC driver: snd_hda_intel v: kernel bus ID: 00:03.0 
           chip ID: 10de:0e0f 
           Sound Server: ALSA v: k4.12.14-lp151.28.36-default 
Network:   Device-1: Intel 82574L Gigabit Network driver: e1000e v: 3.2.6-k port: 61c0 bus ID: 00:01.0 
           chip ID: 8086:10d3 
           IF: eth0 state: up speed: 1000 Mbps duplex: full mac: 52:54:00:12:34:56 
Drives:    Local Storage: total: 60.00 GiB used: 27.06 GiB (45.1%) 
           ID-1: /dev/vda model: N/A size: 60.00 GiB serial: N/A 
Partition: ID-1: / size: 57.51 GiB used: 27.06 GiB (47.0%) fs: btrfs dev: /dev/vda2 
           ID-2: /home size: 57.51 GiB used: 27.06 GiB (47.0%) fs: btrfs dev: /dev/vda2 
           ID-3: /opt size: 57.51 GiB used: 27.06 GiB (47.0%) fs: btrfs dev: /dev/vda2 
           ID-4: /tmp size: 57.51 GiB used: 27.06 GiB (47.0%) fs: btrfs dev: /dev/vda2 
           ID-5: /var size: 57.51 GiB used: 27.06 GiB (47.0%) fs: btrfs dev: /dev/vda2 
           ID-6: swap-1 size: 2.00 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/vda3 
Sensors:   Message: No sensors data was found. Is sensors configured? 
Info:      Processes: 225 Uptime: N/A Memory: 7.78 GiB used: 895.0 MiB (11.2%) Init: systemd v: 234 runlevel: 5 
           target: graphical.target Compilers: gcc: 7.5.0 alt: 7 Shell: bash v: 4.4.23 running in: tilda 
           pinxi: 3.0.37-1 

[tsu2]

@tsu2

OK,
The LEAP documentation link I provided above also describes how to set up UEFI, but using virt-install, whereupon you can use virsh to launch.

Using qemu is one of those things that’s important to know about, but should be avoided unless you can benefit from it.
At least, that’s the general recommendation… Of course if the slight latency which isn’t as bad as before integration with KVM can be tolerated, then it’s certainly not going to work.

TSU

Re-reading my post,
I can see I didn’t word my final sentence well, people may not read it the way I intended…

Meant to say that invoking qemu instead of by other means will result in a slightly slower running VM, but for many today that difference may not be important.
Before integration with KVM, the difference was very, very large but today not so much.

And, it’s not just the bootup, emulation vs virtualization is an ongoing difference when comparing running VMs.

TSU

[larryr]

As an alternative you could install virtualbox and create a Windows 10 guest install that way.

I run windows 10 in a Virtualbox - I have a 32 bit and a 64 bit version. You can install it from the Microsoft 1909 image and install the virtualbox extension pack to get usb and uefi support and the guest additions to the virtual machine so that you can have any size window and not have to use the right ctrl key to move the mouse out of the virtual machine.
I created a 64gb virtual drive for 64 bit Windows 10 and a 32gb virtual drive for 32 bit Windows 10.

No issues and no need for special drivers as all are included in VirtualBox.

[tsu2]

@larryr

As an alternative you could install virtualbox and create a Windows 10 guest install that way.

I run windows 10 in a Virtualbox - I have a 32 bit and a 64 bit version. You can install it from the Microsoft 1909 image and install the virtualbox extension pack to get usb and uefi support and the guest additions to the virtual machine so that you can have any size window and not have to use the right ctrl key to move the mouse out of the virtual machine.
I created a 64gb virtual drive for 64 bit Windows 10 and a 32gb virtual drive for 32 bit Windows 10.

No issues and no need for special drivers as all are included in VirtualBox.

I agree that installing Win10 as a VBox guest is easy.
And, VBox supports UEFI if that’s what you want (VMware today does not).

But, at least for now we don’t know the @OP’s reasons for

• Installing by command line. It’s useful if setting up a number of machines and may be necessary for a remote install, but if simply creating a single machine even as a Golden instance, a GUI typically makes things easy in any virtualization technology.
• UEFI can be unstable, or at least I’ve found that to be the case. Works for awhile, maybe not forever. And, there’s no need to ever install a Guest using UEFI, there’s no problem installing a Guest with MBR on any HostOS that boots UEFI (because all hypervisor based virtualization uses its own virtual BIOS and virtualized disk layout). I’ve mainly used the UEFI option to explore and experiment, but don’t use it for my important VMs in the interest of the KISS principle.

TSU