QCOW2 drive not booting

[Vlad Baragan-Stroe]

Hello everybody,

Not sure if this is the right place to ask this question, but maybe you have experience on this part also.

I want to launch a qcow2 image(drive) using qemu-system-x86_64. I have created the qcow2 image from a VM with centos. The problem I encounter it that the image does not boot.

Command that I issue:

sudo qemu-system-x86_64 -enable-kvm -drive file=centos-vm-instance.qcow2,index=0,media=disk,format=qcow2 -m 2048 -curses

The process gets stuck at ”Booting from Hard Disk”

Can you please help me?

Vlad

[John Snow]

On 2/2/21 4:28 AM, Vlad Baragan-Stroe wrote:
> Hello everybody,
>
> Not sure if this is the right place to ask this question, but maybe you
> have experience on this part also.
>
> I want to launch a qcow2 image(drive) using qemu-system-x86_64. I have
> created the qcow2 image from a VM with centos. The problem I encounter
> it that the image does not boot.
>

How did you create the image? Does it boot on the environment you
created it on?

> Command that I issue:
> sudo qemu-system-x86_64 -enable-kvm -drive
> file=centos-vm-instance.qcow2,index=0,media=disk,format=qcow2 -m 2048
> -curses
>
>
>

> The process gets stuck at ”Booting from Hard Disk”
>

In the past, common problems have been a bad disk layout or a disk image
that requires an EFI firmware instead of BIOS.

> Can you please help me?
>
> Vlad
>

--js

[Baragan-Stroe Vlad]

Hi John, 

Yes this was the problem. Thank you!

I've booted the qcow2 drive using virt-manager and the linux GUI and checked the UEFI and Q32 options. It used UEFI boot, instead of BIOS. 

If anybody stumbles on this, you can use the guidance from this article: https://ostechnix.com/enable-uefi-support-for-kvm-virtual-machines-in-linux/

Vlad

[Baragan-Stroe Vlad]

John,

Do you know if I can set qemu to boot from UEFI using the command line? In other words, using the qemu-system-x86_64 tool.

Vlad

[John Snow]

On 2/10/21 2:30 AM, Baragan-Stroe Vlad wrote:
> John,
>
> Do you know if I can set qemu to boot from UEFI using the command line?
> In other words, using the qemu-system-x86_64 tool.
>
> Vlad
>

I'm not 100% familiar with the mechanisms here. QEMU has a default
search path and a default filename(s) list it uses to load firmware.

Passing "-L ?" will have QEMU print its search path for firmware blobs;
here's one I compiled myself:

> ./x86_64-softmmu/qemu-system-x86_64 -L \?

/home/jsnow/src/qemu/bin/git/../share/qemu-firmware
/home/jsnow/src/qemu/bin/git/pc-bios


And here's the one that came with Fedora 33:

jsnow@scv ~/s/q/b/git (python-qapi-cleanup-pt2)> qemu-system-x86_64 -L \?
/usr/share/qemu-firmware
/usr/share/qemu


I believe by default it looks for "bios.bin" (which will be SeaBIOS,
usually). I think you can force its hand; here are some ways I know of,
but have *not tested or used*:


(1) Take the OVMF image and just name it "bios.bin" and then pass -L
/path/to/my/ovmf/ to coerce QEMU into loading that image. Maybe a
symlink will work too. I think this is a hack.

(2) Pass `-bios /usr/share/edk2/ovmf/OVMF_CODE.fd` to force it to load
that image. (This is what you get with the F33 edk2-ovmf package.) I
think this is also a hack.

(3) Model the pflash directly; libvirt uses a similar technique:

./qemu-system-x86_64 \
-drive
id=pflash0,if=none,file=/usr/share/edk2/ovmf/OVMF_CODE.fd,format=raw,readonly=on
-machine q35,accel=kvm,pflash0=pflash0

Libvirt uses blockdev instead of -drive if=none to model this. It also
sets up a rw pflash1 for storing NVRAM variables that you need to boot
anything, I think. I am not well versed in this area ...! I recommend
using VMM to boot an instance with libvirt and then spy on the flags it
uses using `ps` and take notes on how it built the instance.

_,.-'~'-.,__,.-'~'-.,__,.-'~'-.,__,.-'~'-.,__,.-'~'-.,_

A quick lesson on -blockdev:

You build a storage graph yourself by hand. Generally, you use a
protocol node (POSIX file) and a format node (RAW format).

-blockdev
node-name=pflash0_proto,driver=file,filename=OVMF_CODE.fd,read-only=on
-blockdev node-name=pflash0_fmt,driver=raw,file=pflash0_file,read-only=on

That builds a disembodied block graph that isn't associated with any
guest-visible device. One way to associate it with something is:

-machine q35,accel=kvm,pflash0=pflash0_fmt

_,.-'~'-.,__,.-'~'-.,__,.-'~'-.,__,.-'~'-.,__,.-'~'-.,_


I believe you need to use something similar for OVMF_VARS.fd mounted rw
for pflash1, but you will obviously need RW access for this. I honestly
have no idea if there's a way around needing to manage the nvram storage
for UEFI builds, and I have absolutely no idea what mucking around with
-L or -bios does to the machine device graph as far as pflash0/1 is
concerned.


HTH
--js

[Baragan-Stroe Vlad]

Thank you for this small tutorial. I will try your steps and let you know of the outcome. 

Vlad

[Baragan-Stroe Vlad]

Hi,

I don't have time anymore to test the steps above, if anyone else stumbles into this problem he can try this and give feedback. Thanks again to the community!

Vlad