On Mon, Jan 31, 2022 at 04:21:36PM +0100, Kashyap Chamarthy wrote:
On Mon, Jan 31, 2022 at 02:36:46PM +0000, Daniel P. Berrangé wrote:
On Mon, Jan 31, 2022 at 03:00:33PM +0100, Kashyap Chamarthy wrote:
On Mon, Jan 31, 2022 at 12:55:09PM +0000, Daniel P. Berrangé wrote:
[...]
I briefly wondered if in this "combined" mode whether the no. of duplicate copies can ever fill up the storage. I doubt that, as the combined size of _VARS + _CODE is just about 2MB. So it only starts mattering if you're running tens of thousands of guests.
When guest root / data disk sizes are measured in 100's of MB, or GBs, I struggle to get worried about even a 16 MB OVMF blob being copied per guest.
Heh, fair enough.
The firmware can be provided in qcow2 format too, so if really concerned, just create a qcow2 file with a backing store pointing to the readonly master, so you're only paying the price of the delta for any guest VARs writes. That's more efficient than what we do today with copying the separate raw format VARS.fd file.
That's nice, I didn't know the qcow2 possibility in this context. For some reason I assumed the file format always has to be raw here. Your qcow2 point above should be documented, if it isn't already. Although I don't know the right place for it.
There's already a format field in the descriptor, but even if the firmware is distributed as raw, libvirt can choose to put qcow2 overlay on it, as its all configured with -blockdev Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|