Interesting that nobody ever hit it. You're right, there is a bunch of formats which we can produce but which can't be loaded directly by generated xml. To be honest, I'm not sure what is the right solution here.

Options:
1) Maybe just catch those libvirt/qemu unsupported formats and put a placeholder there instead warning user that s/he needs to convert image before the use?
2) Don't create/upload this file at all for affected formats
3) Upload unmodified XML and don't care about usefulness, (sic!)

Simple user-side workaround is to not use raw-xz but qcow2 or something else ("brew image-build --format=qcow2"). Which leads me to other problem (not tested). Does it make any sense to use discard on raw images? They are from definition containing those areas. So, discard could work on running image (underlying FS could punch a hole there) but from the POV of recompression later, whole content will be repacked again (probably with zeroed blocks, but still).

Add "discard=unmap" should be IF task, nevertheless.

I'm still confused. I'm not sure what actually consumes the driver type = raw-xz value? I thought this xml file is only used by libvirt and handed off to qemu? But something else must look at whether it's raw-xz and takes some kind of action on it? Otherwise, maybe it should just be raw, and then it's understood that there's a later step to pass it through xz unconditionally? Or I guess if you want something like an --xz switch vs --zstd switch, that's reasonable.

Both xz and zstd support sparse files by default, so it's more efficient handling if they already have holes in them instead of just zeros which then have to be compressed.

We definitely should use discard=unmap on either raw or qcow2 (whichever format is primary) because it is the guest calling fstrim (via lorax) and unless this pass through is enabled, the FITRIM() from guest to host is ignored, and the stale data is retained, it's not even treated as zeros. It's referenced stale RPM files that were deleted but not zero'd because the fstrim is ignored. So they end up getting compressed by xz and downloaded by everyone.

Whole build process is working with raw image which is only after build is done compressed and xml is altered to point to new compressed image.

I've created https://github.com/clalancette/oz/pull/305 to do it in the oz directly, so raw image is prepared correctly.

Merged to oz. Question stays if we should generate unusable xml on our side. @mikem ?

This seems like we've slipped into a tangential issue separate from the OP, with seems to be fixed by the oz patch, right?

Option 1 seems the least invasive for now.

PR #3490

Commit c0a368d fixes this issue

Commit 09d4f88 relates to this ticket