February 22, 20242 yr Im having problems when I convert to the QCOW2 format. The disk is reporting the wrong size and unallocated 142.58GB that should be 250gb. And does not boot. it works fine with KVM on Debian. Is there a problem for the Unraid KVM using QCOW2 converted with qemu-img.
April 15, 20242 yr I have the same problem and would like also a solution. The goal is to convert my vDisks to qcow2 so I could do a snapshot with virsh. I took a Windows VM vDisk "vdisk1.img" with format raw and executed the following from "/mnt/user/domains/srvr-windows" while the VM was running as a proof of concept. qemu-img convert -f raw -O qcow2 vdisk1.img vdisk1.qcow2 The img file have 50GB and the QCow2 have 17GB but I suspect this is caused by differences in how they store zeroes. I then stopped the VM, changed the primary vdisk location to /mnt/user/domains/[vm-name]/vdisk1.qcow2 and kept the vDisk bus to VirtIo. Following that, I start the machine and I have the following (see attached 'boot error.png'). Note that I have also 4 disks passed through from the host to this VM. I then tried all other vDisk bus except IDE and USB without any change on the result. Do someone have any informations for us?
April 15, 20242 yr 3 minutes ago, sbeaudoin said: I then stopped the VM, changed the primary vdisk location to /mnt/user/domains/[vm-name]/vdisk1.qcow2 and kept the vDisk bus to VirtIo. Make sure the type is set as qcow2, edit the xml if needed since the choice currently disappears when selecting manual. Edited April 15, 20242 yr by Kilrah
April 15, 20242 yr Thanks for the fast reply. There is no type field on the Gui. I understand I should manually put it on the VM xml file. I will try your suggestion later and keep this post informed.
April 15, 20242 yr I couldn't wait... I stopped the VM, went to '/etc/libvirt/qemu' and edited the srvr-windows.xml file. I changed the drvier type 'raw' for 'qcow2' here : <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='writeback'/> <source file='/mnt/user/domains/srvr-windows/vdisk1.qcow2'/> <target dev='hdc' bus='virtio'/> <serial>vdisk1</serial> <boot order='1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> </disk> No joy, same symptoms when I restart the VM. Edited April 15, 20242 yr by sbeaudoin Typo
April 15, 20242 yr Solution It works now. ChatGPT gave me the answer. The question was : Quote in an unraid vm with a raw vdisk, I converted it to a qcow2 disk and I want to modify the vm xml file created by virsh to change the format. The answer was : Quote Sure, you can modify the XML file for the VM created by virsh to change the disk format from raw to qcow2. Here's a general outline of the steps you can follow: 1. **Locate the XML file**: Find the XML file for your VM. By default, these are usually stored in `/etc/libvirt/qemu` or `/etc/libvirt/qemu/autostart` depending on your setup. 2. **Edit the XML file**: Open the XML file using a text editor like `nano` or `vim`. Look for the `<disk>` section corresponding to the disk you want to convert. 3. **Change disk format**: In the `<disk>` section, you'll find an `<source>` tag specifying the path to the disk image file. You need to change the `file` attribute to point to the qcow2 file you created, and you also need to add a `<driver>` tag to specify the disk format as qcow2. ```xml <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/path/to/your/qcow2/file.qcow2'/> <!-- Other disk configuration parameters --> </disk> ``` 4. **Save and close the XML file**: After making the necessary changes, save the file and close the text editor. 5. **Reload the VM configuration**: Once you've modified the XML file, you need to tell libvirt to reload the configuration. ```bash virsh define /path/to/your/xml/file.xml ``` Replace `/path/to/your/xml/file.xml` with the path to your modified XML file. 6. **Verify the changes**: You can now start your VM and verify that it's using the qcow2 disk format. Remember to back up your XML file before making any changes, just in case something goes wrong. Also, ensure that the permissions on the qcow2 file are set correctly so that the VM can access it. So, the process is the following, for those interested : Stop the VM. In a ssh session, go to the vDisk directory who should be : '/mnt/user/domains/[machine name]/" and you should see your vdisk file probably named 'vidks1.img'. Convert it to a qcow 2 format with the following command : qemu-img convert -f raw -O qcow2 vdisk1.img vdisk1.qcow2 The qcow2 extension is not necessary, it could still use the img extension, only the content of the file matters. But as we need a different file name, I found it convenient to use this extension. Edit the vm xml file who should be at : '/etc/libvirt/qemu/[machine name].xml' after making a backup copy. In the "devices" element, find the child "disk" element where his child "source" element point to the original vdisk and change the path and type. For example, for a vdisk at '/mnt/user/domains/srvr-windows/vdisk1.img'. I had the following : <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/mnt/user/domains/srvr-windows/vdisk1.img'/> <target dev='hdc' bus='virtio'/> <serial>vdisk1</serial> <boot order='1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> </disk> I changed the file attribute of the source element to point to the qcow2 file and I changed the type attribute of the driver element to qcow2. <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='writeback'/> <source file='/mnt/user/domains/srvr-windows/vdisk1.qcow2'/> <target dev='hdc' bus='virtio'/> <serial>vdisk1</serial> <boot order='1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> </disk> And the missing element given to me by chatGPT is to execute the following command to make the virtualization platform aware of the change : virsh define /etc/libvirt/qemu/[machine name].xml The file path is the same you edited and it should answer you with : Domain '[machine name]' defined from /etc/libvirt/qemu/[machine name].xml You can then start your VM and after the confirmation of success, confirm the vm configuration in the GUI that the path is really the qcow2 file before removing the img file at '/mnt/user/domains/[machine name]/vidks1.img'. Press F5 to refresh the page and confirm it again. Just in case... Disclaimer : I leave these instructions to help, not to maintain it or to support anyone else. It is POSSIBLE I intervene though... Enjoy.
April 15, 20242 yr Author 22 minutes ago, sbeaudoin said: It works now. ChatGPT gave me the answer. The question was : The answer was : So, the process is the following, for those interested : Stop the VM. In a ssh session, go to the vDisk directory who should be : '/mnt/user/domains/[machine name]/" and you should see your vdisk file probably named 'vidks1.img'. Convert it to a qcow 2 format with the following command : qemu-img convert -f raw -O qcow2 vdisk1.img vdisk1.qcow2 The qcow2 extension is not necessary, it could still use the img extension, only the content of the file matters. But as we need a different file name, I found it convenient to use this extension. Edit the vm xml file who should be at : '/etc/libvirt/qemu/[machine name].xml' after making a backup copy. In the "devices" element, find the child "disk" element where his child "source" element point to the original vdisk and change the path and type. For example, for a vdisk at '/mnt/user/domains/srvr-windows/vdisk1.img'. I had the following : <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/mnt/user/domains/srvr-windows/vdisk1.img'/> <target dev='hdc' bus='virtio'/> <serial>vdisk1</serial> <boot order='1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> </disk> I changed the file attribute of the source element to point to the qcow2 file and I changed the type attribute of the driver element to qcow2. <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='writeback'/> <source file='/mnt/user/domains/srvr-windows/vdisk1.qcow2'/> <target dev='hdc' bus='virtio'/> <serial>vdisk1</serial> <boot order='1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> </disk> And the missing element given to me by chatGPT is to execute the following command to make the virtualization platform aware of the change : virsh define /etc/libvirt/qemu/[machine name].xml The file path is the same you edited and it should answer you with : Domain '[machine name]' defined from /etc/libvirt/qemu/[machine name].xml You can then start your VM and after the confirmation of success, confirm the vm configuration in the GUI that the path is really the qcow2 file before removing the img file at '/mnt/user/domains/[machine name]/vidks1.img'. Press F5 to refresh the page and confirm it again. Just in case... Disclaimer : I leave these instructions to help, not to maintain it or to support anyone else. It is POSSIBLE I intervene though... Enjoy. Thank you. I forgot to update this when I found the solution for me. It was simply to change the disk type. But I have been having problems running VMs. I have to look further into these settings that I had no clue you had/could change. I also very much recommend Virt-Manager. I have still to dive into it, but it looks powerful and easy to use (I hate to use CLI, and script edits).
April 15, 20242 yr Community Expert 4 hours ago, sbeaudoin said: virsh define /etc/libvirt/qemu/[machine name].xml Can do the update via the XML view. Change the file name and type then update.
September 13, 20241 yr On 4/15/2024 at 10:36 AM, sbeaudoin said: It works now. ChatGPT gave me the answer. The question was : The answer was : So, the process is the following, for those interested : Stop the VM. In a ssh session, go to the vDisk directory who should be : '/mnt/user/domains/[machine name]/" and you should see your vdisk file probably named 'vidks1.img'. Convert it to a qcow 2 format with the following command : qemu-img convert -f raw -O qcow2 vdisk1.img vdisk1.qcow2 The qcow2 extension is not necessary, it could still use the img extension, only the content of the file matters. But as we need a different file name, I found it convenient to use this extension. Edit the vm xml file who should be at : '/etc/libvirt/qemu/[machine name].xml' after making a backup copy. In the "devices" element, find the child "disk" element where his child "source" element point to the original vdisk and change the path and type. For example, for a vdisk at '/mnt/user/domains/srvr-windows/vdisk1.img'. I had the following : <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/mnt/user/domains/srvr-windows/vdisk1.img'/> <target dev='hdc' bus='virtio'/> <serial>vdisk1</serial> <boot order='1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> </disk> I changed the file attribute of the source element to point to the qcow2 file and I changed the type attribute of the driver element to qcow2. <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='writeback'/> <source file='/mnt/user/domains/srvr-windows/vdisk1.qcow2'/> <target dev='hdc' bus='virtio'/> <serial>vdisk1</serial> <boot order='1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> </disk> And the missing element given to me by chatGPT is to execute the following command to make the virtualization platform aware of the change : virsh define /etc/libvirt/qemu/[machine name].xml The file path is the same you edited and it should answer you with : Domain '[machine name]' defined from /etc/libvirt/qemu/[machine name].xml You can then start your VM and after the confirmation of success, confirm the vm configuration in the GUI that the path is really the qcow2 file before removing the img file at '/mnt/user/domains/[machine name]/vidks1.img'. Press F5 to refresh the page and confirm it again. Just in case... Disclaimer : I leave these instructions to help, not to maintain it or to support anyone else. It is POSSIBLE I intervene though... Enjoy. This worked to get beyond the following: "error: unsupported configuration: internal snapshot for disk hdc unsupported for storage type raw" But once I ran through the above fix, I was met with another: "error: Operation not supported: internal snapshots of a VM with pflash based firmware are not supported" Apparently UEFI and virsh don't play well together. After a little more Googling, I settled on the following workaround: - Shut down the VM - Edit the VM's XML config: change 'os loader type' from 'pflash' to 'rom' - Run "virsh snapshot-create-as <VM name> --name <snapshot name>" - Verify the snapshot was created in "/var/lib/libvirt/qemu/snapshot/<machine name>/" - Revert the VM's XML edit: change 'os loader type' from 'rom' back to 'pflash' - Restart the VM
September 13, 20241 yr Community Expert 14 hours ago, Reid-O said: This worked to get beyond the following: "error: unsupported configuration: internal snapshot for disk hdc unsupported for storage type raw" But once I ran through the above fix, I was met with another: "error: Operation not supported: internal snapshots of a VM with pflash based firmware are not supported" Apparently UEFI and virsh don't play well together. After a little more Googling, I settled on the following workaround: - Shut down the VM - Edit the VM's XML config: change 'os loader type' from 'pflash' to 'rom' - Run "virsh snapshot-create-as <VM name> --name <snapshot name>" - Verify the snapshot was created in "/var/lib/libvirt/qemu/snapshot/<machine name>/" - Revert the VM's XML edit: change 'os loader type' from 'rom' back to 'pflash' - Restart the VM FYI Snapshot will be created in memory as /var/lib is not on storage. V7 uses external snapshots. You can specify path of the overlay file. You can do an external snap on a raw file. Overlay is qcow2.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.