vz A lima _disk converted from qcow2 > raw on startup truncates to 0 bytes and can't be used in the vm.

[mhio]

Description

A lima disk created as the default qcow2 format, and added to a vz debian 12 vm, gets truncated to 0 bytes on limactl start vm and the device is not usable.

Here are the steps:

% limactl disk create one --size 1G
INFO[0000] Creating qcow2 disk "one" with size 1GiB 
% limactl disk list
NAME           SIZE     DIR                                     IN-USE-BY
one            1GiB     /Users/me/.lima/_disks/one

lima.yml for withone

images:
  - location: 'https://cloud.debian.org/images/cloud/bookworm/20231013-1532/debian-12-genericcloud-amd64-20231013-1532.qcow2'
    arch: 'x86_64'
    digest: 'sha512:b2ddc01e8d13dabbcfde6661541aae92219be2d442653950f0e44613ddebaeb80dc7a83e0202c5509c5e72f4bd1f4edee4c83f35191f2562b3f31e20e9e87ec2'
  - location: 'https://cloud.debian.org/images/cloud/bookworm/latest/debian-12-genericcloud-amd64.qcow2'
    arch: 'x86_64'
vmType: 'vz'
mountType: 'virtiofs'
additionalDisks:
  - name: 'one'
    format: false

% limact start withone
INFO[0000] Using the existing instance "withone"        
INFO[0002] [hostagent] hostagent socket created at /Users/me/.lima/withone/ha.sock 
INFO[0002] [hostagent] Starting VZ (hint: to watch the boot progress, see "/Users/me/.lima/withone/serial*.log") 
INFO[0002] [hostagent] new connection from  to          
INFO[0002] [hostagent] Mounting disk "one" on "/mnt/lima-one" 
INFO[0002] [hostagent] Converting "/Users/me/.lima/_disks/one/datadisk" (qcow2) to a raw disk "/Users/me/.lima/_disks/one/datadisk" 
INFO[0002] [hostagent] 1.00 GiB / 1.00 GiB (100.00%) ? p/s 
INFO[0003] SSH Local Port: 52309                        
INFO[0003] [hostagent] Waiting for the essential requirement 1 of 3: "ssh" 
INFO[0003] [hostagent] [VZ] - vm state change: running  
INFO[0013] [hostagent] Waiting for the essential requirement 1 of 3: "ssh" 
INFO[0013] [hostagent] The essential requirement 1 of 3 is satisfied 
INFO[0013] [hostagent] Waiting for the essential requirement 2 of 3: "user session is ready for ssh"
<snip> 

Now the disk is 0 bytes

% limactl disk list
NAME           SIZE     DIR                                     IN-USE-BY
one            0B       /Users/me/.lima/_disks/one              withone

% limactl shell withone lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
vda     254:0    0  100G  0 disk 
├─vda1  254:1    0 99.9G  0 part /
├─vda14 254:14   0    3M  0 part 
└─vda15 254:15   0  124M  0 part /boot/efi
vdb     254:16   0    0B  0 disk 
vdc     254:32   0  278M  1 disk /mnt/lima-cidata

Creating the disk with --format raw leads to a usable 1GB device being presented to the VM.

% limactl --version
limactl version 0.18.0
% sw_vers
ProductName:		macOS
ProductVersion:		14.0
BuildVersion:		23A344

[jandubois]

INFO[0002] [hostagent] Converting "/Users/me/.lima/_disks/one/datadisk" (qcow2) to a raw disk "/Users/me/.lima/_disks/one/datadisk"

I think the issue is that the disk is being converted in-place. In my experience this doesn't work; the destination must be a new file, and you can delete the source and rename the converted copy back to the original filename after a successful copy.

So yes, this means you need enough free space to temporarily store a second copy of the volume.

[afbjorklund]

It is supposed to use a temporary file (internally), but I can confirm that I also got a zero-byte file when calling the ConvertToRaw function

limactl disk convert

So must be a silent error somewhere inside

[jandubois]

It is supposed to use a temporary file (internally)

It never worked for me. See also

https://github.com/rancher-sandbox/rancher-desktop/commit/c65fc1aa04ebd06b556d24963e27be7a0266f41b

[afbjorklund]

Oh, the imgutils version does NOT support it... But the nativeimgutil was supposed to do it, at least from my reading of the code.

The qemu version just says the image is "locked" (by itself, I suppose)

[jandubois]

But the nativeimgutil was supposed to do it, at least from my reading if the code.

Ah, you are right; it should have done the right thing already. I was just going by the log message, which listed identical source and destination. So not sure why this failed then.

[AndreasA]

I am not 100% sure it is related to this issue, but it seems related.

I just had an issue with the new colima version that changed from raw format to qcow2, where the instance could not be created, after some furhter tests the same image failed to create/start the instance with the qcow2 file, but manually converting it first to raw file (using qemu-img), it works fine.

See: https://github.com/abiosoft/colima/issues/930

however, it is possible that issue only occurs on intel macs but not on M1/M2/M3 based macs.

[AndreasA]

Btw. from my checks with colima 0.6.7 I did some checks on the file on the disk and it seems that the temporary filename is not changed after the disk is converted. maybe that is the issue? and the file itself seems to be in a locked state as reading it fails as well.

[AndreasA]

what is the state regarding this issue? does anyone know if OS or latest lima update might have fixed this? don't have time currently to test this.

[mhio]

$ limactl --version
limactl version 0.20.0

Test

limactl disk create one --size 1G

echo '
images:
- location: "https://cloud.debian.org/images/cloud/bookworm/20240102-1614/debian-12-genericcloud-amd64-20240102-1614.qcow2"
  arch: "x86_64"
  digest: "sha512:49cbcfdb3d5401e8c731d33211cff5e1ef884f179a936c7378eeab00c582ace45dd7154ac9e4c059f1bd6c7ae2ce805879cb381a12a1cc493e3a58c847e134c7"
additionalDisks:
- name: "one"
  format: false
' \
| limactl create --name one --plain --vm-type vz -

# and with virtio
#| limactl create --name one --plain --vm-type vz --mount-type virtiofs -

limactl start one

limactl shell one lsblk /dev/vdb

Outputs 0 bytes

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
vdb  254:16   0   0B  0 disk 

Clean

limactl rm one -f
limactl disk remove one

[AkihiroSuda]

Seems fixed in #2255