No bootable device after Image creation

[T0schi]

Good morning,
i am facing the issue that the images are not bootable after the creation.

The creation itself seems to run properly but shows some warnings.

1. The installed version of DISM is older than the Windows image

`WARNING: Size Not Supported

Extended information:
The specified shrink size is too big and will cause the volume to be smaller than the minimum volume size.

Activity ID: {16c7d144-adac-49ad-8dea-d47ad96c567b}
19.10.2019 12:47:52 - Size increased: 12989759488
WARNING: Size Not Supported

Extended information:
The specified shrink size is too big and will cause the volume to be smaller than the minimum volume size.

Activity ID: {77896bc6-c7bf-490a-9b88-e0ddd3c1e914}`

• I´ve tried to create a Server2012R2, Server2016 and Server2019 .raw image.
• Using bare metal server with Server2012R2 as image creation server
• Used VirtIO 0.1.141 and 0.1.171
• converted the final .raw image to .iso and try to use it in HyperV - same issue.
• Creating offline images

Someone a hint what i am doing wrong?

CompleteLog.txt

[ader1990]

@T0schi even though the image path is *.raw, you generated a qcow2 image (as the image type was set to KVM). Can you share the ps auxf|grep qemu from the Linux machine (how the qemu process was started), as I think that is the main issue here.

[T0schi]

even though the image path is *.raw, you generated a qcow2 image

Hi ader1990, that´s exactly the reason for the issue. Actual the created ".raw" files seems still to be .qcow2 files. I´ve converted the initial .raw file with qemu in another .raw file and that solved it. I can´t provide you the output ps auxf|grep qemu because i don´t use any Linux machine during the creation process. The screenshot was taken in our OpenStack environment in the console.

Do you have an idea which step could cause this renaming from .qcow2 in .raw?

Thank you so far

[ader1990]

can you share the config file? I suppose the path extension you set is not the same as the virtual_disk_format or the image_type was set to KVM.
if you set image_type = KVM, it will use the virtual_disk_format=qcow2 automatically.

If you set the image_type to HyperV, you can use virtual_disk_format=raw. image_type=HyperV should be used when you want to be able to customize every aspect of the image.

[T0schi]

Yes i have a value to set the virtual_disk_format as RAW while using KVM as image_type. I will try if that behaviour stillt persist when i remove the raw value.

2019stdV_11_2019.txt

[T0schi]

The image creation works fine now. It was the faulty RAW value that simply named a qcow2 file as raw file.

Thanks a lot!