Best way to import a large sparse RAW image from another qube without copying 500 GB?

[PandemicOfNukes]

I’m trying to import a VirtualBox appliance into a Qubes HVM following the official documentation for converting VirtualBox VMs to Qubes HVMs.
My workflow so far is:

qemu-img convert -O raw OPENVAS-FREE-25.0.5-VirtualBox-disk001.vmdk OPENVAS.raw

The resulting RAW image has:

• Apparent size: 500 GB
• Actual disk usage (du -h ): about 30 GB

So the RAW file is clearly sparse.

The problem is that the documentation suggests copying the RAW image into dom0 first:

qvm-run --pass-io work 'cat /home/user/Downloads/OPENVAS.raw' > /home/user/OPENVAS-root.img

This appears to stream the entire 500 GB logical image, which defeats the purpose of having a sparse RAW file. I also don’t have enough free space in dom0 to create a temporary 500 GB file.

My questions are:

1. What is the recommended Qubes 4.3 workflow for importing a large sparse RAW image located in another qube?
2. Is there a way to preserve sparseness during the transfer, or does importing via cat necessarily stream all 500 GB of logical data?
3. Would it be better to avoid creating the RAW image entirely and import directly from the original VMDK?
4. Has anyone successfully imported a large sparse VirtualBox disk without needing hundreds of gigabytes of temporary storage in dom0?

I’d appreciate any recommendations for the most efficient and storage-safe workflow.

[rustybird]

Importing a large (> dom0 disk size) standalone VM

It’s possible with a named pipe (FIFO). You have to do the volume import separately after VM creation, because qvm-create cannot automatically detect the correct volume size in this case so it has to be passed manually - which is only implemented for qvm-volume import. Continuing after the qemu-img convert step: [user@dom0 ~]$ mkfifo /tmp/fifo [user@dom0 ~]$ qvm-run --pass-io untrusted 'cat "/media/user/externalhd/win10.raw"' > /tmp/fifo While this^ is still running, open another terminal and…

This will still stream all 500 GB of data as if it was a non-sparse image, but that stream is sparsified as it is being written to disk as a VM volume (which using a named pipe allows you to do directly, instead of writing to dom0 temporary storage first).

[PandemicOfNukes]

Well the issue appears to be solved but now the machine is stuck in “Booting from Hard Disk…” Is this to be expected or did I do something wrong?
I ran rm /tmp/fifo before starting the machine was that wrong?

[rustybird]

@PandemicOfNukes

I ran rm /tmp/fifo before starting the machine was that wrong?

That’s fine.

@PandemicOfNukes

now the machine is stuck in “Booting from Hard Disk…”

Sorry, I don’t know how to diagnose that. Maybe post it in a separate thread for better visibility?

[PandemicOfNukes]

Oh well you still helped me I will post another thread if I cant fix the issue!

[HexorCatZ]

Hi.
i dont understand spars so im not sure if this helps.
i did though transfer a big files from one vm to another without saving files on another vms.
or to be exact, from vault => dom0 => dispvm => ssh => remote computer without saving to anything in between.

its goes like this.
from dom0, you can pipe the files from one appvm to another with :
qvm-run -p work (in your case) 'cat /home/user/Downloads/OPENVAS.raw' | qvm-run -p vault (i assume) 'cat > /home/user/Downloads/OPENVAS.raw'

hope this help.