Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support QEMU qcow2 image format #162

Merged
merged 2 commits into from
Apr 24, 2024
Merged

Support QEMU qcow2 image format #162

merged 2 commits into from
Apr 24, 2024

Conversation

dbnicholson
Copy link
Member

It's a nice format for loading in GNOME Boxes or any VM tool that uses QEMU. In particular, it's the native format used by GNOME Boxes.

https://phabricator.endlessm.com/T35332

@dbnicholson dbnicholson requested review from dsd and wjt April 20, 2024 17:25
Copy link
Member

@wjt wjt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would be useful, but we already build & store 3 massive files for each eos build – it slows down the build process every night and occupies bytes on a disk somewhere in the sky forever.

I have a hunch that the VMDK images are essentially unused. I don't think we can determine from OS metrics/pings/activations whether a VM was installed from the VMDK or from an img/ISO. But maybe we can look at our CDN logs and see if anyone has ever downloaded them…

stages/eib_image Show resolved Hide resolved
stages/eib_image Show resolved Hide resolved
@dbnicholson
Copy link
Member Author

This would be useful, but we already build & store 3 massive files for each eos build – it slows down the build process every night and occupies bytes on a disk somewhere in the sky forever.

I have a hunch that the VMDK images are essentially unused. I don't think we can determine from OS metrics/pings/activations whether a VM was installed from the VMDK or from an img/ISO. But maybe we can look at our CDN logs and see if anyone has ever downloaded them…

Fair point. I can try to dig some download logs today and see if they're ever downloaded. Personally I've never used Virtualbox, but almost certainly the OVF images are more useful on Windows or OSX.

Alternatively, I could limit it to base with the thought that this is primarily a developer tool at the moment.

@dsd
Copy link
Member

dsd commented Apr 23, 2024

I think limiting to base makes sense.

@dbnicholson
Copy link
Member Author

I think limiting to base makes sense.

I'll update the PR to do that and we can punt on OVF images.

The QEMU qcow2 format[1][2] provides a lot of nice features compared to
raw disk images. Some of the most important ones:

* It's a copy-on-write format, so the file grows as data is added.
* It supports compression.
* It supports snapshots.

The first 2 mean that a minimized download can be made with a lot of
space to expand the root partition into. Probably most important to us,
this is the format used by GNOME Boxes (really QEMU via libvirt). That
means you can hand the image directly to boxes without creating a qcow2
disk image that the ISO installs to or converting a raw image to qcow2.

1. https://www.qemu.org/docs/master/system/images.html#cmdoption-image-formats-arg-qcow2
2. https://en.wikipedia.org/wiki/Qcow

https://phabricator.endlessm.com/T35332
In my ideal world, we'd do this for all eos products and add them to
osinfo-db. That way we could streamline the GNOME Boxes experience where
it's just going to write all the data from the ISO to a qcow2 image
anyways.

However, doing this for the bigger personalities would add a lot of
overhead. We'd really want to choose one of OVF or qcow2 as "the VM
image" since doing both would be painful. For now, punt on that question
and just enable it for the small base image where it can essentially be
a power user tool.

https://phabricator.endlessm.com/T35332
@dbnicholson
Copy link
Member Author

PR updated with moar comments + limiting to EOS base.

Copy link
Member

@wjt wjt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

moo

@wjt wjt merged commit d20191e into master Apr 24, 2024
2 checks passed
@wjt wjt deleted the T35332-qcow2 branch April 24, 2024 22:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants