Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Blockdiff: We built our own file format for VM disk snapshots

cognition.ai

Post reply on HN
Print view View original

11–20 of 30 posts

Re: Blockdiff: We built our own file format for VM disk snapshots

#11

Post by imiric »

This is interesting. Is it hypervisor-agnostic?

Ideally, I would like to use something like this without being forced to use a specific file system. This is essentially what qcow2 does, and it's a shame that it's not supported by all hypervisors. But then your implementation would need to be much more complex, and implement what CoW filesystems give you for free, so I appreciate that this is possible in 600 LOCs.

Also, your repo doesn't have a license, which technically makes it unusable.

Re: Blockdiff: We built our own file format for VM disk snapshots

#12

Post by Imustaskforhelp »

imiric wrote: post #11

This is interesting. Is it hypervisor-agnostic? Ideally, I would like to use something like this without being forced to use a specific file system. This is essentially what qcow2 does, and it's a shame that it's not supported by all hypervisors. But then your implementation would need to be much more complex, and implement what CoW filesystems give you for free, so I appreciate that this is possible in 600 LOCs. Als…

https://github.com/CognitionAI/blockdiff/issues/3

Created an issue of this on their github as I wanted this issue to also go to their github, let's hope they add a permissive license like MIT or apache

Re: Blockdiff: We built our own file format for VM disk snapshots

#14

Post by [deleted] »

UomoNeroNero wrote: post #10

I don’t know how to express to you how stupid, inadequate, and envious I feel of this level of competence. For me this article has the density of slaps of a plutonium ingot. It’s moving to read (and “maybe” understand, given how well it’s written). Wow, maximum respect, truly.

[deleted]

Re: Blockdiff: We built our own file format for VM disk snapshots

#16

Post by ori_b »

It's a bit surprising that they dismissed qcow2, because it does exactly what they want. It's also pretty easy to implement in a vm. The file format is a 2 level page table per snapshot, with pointers to blocks. I suspect they didn't really look at it enough.

Here's the implementation I did for openbsd; it's around 700 lines, including the gunk to interface with the hypervisor.

https://github.com/openbsd/src/blob/master/usr.sbin/vmd/vioq...

It's not a good choice for computing diffs, but you can run your VM directly off a read-only base qcow2, with all deltas going into a separate file. That file can either be shipped around or discarded. And multiple VMs can share the same read only base.

So, it probably would have been better to write the code for the hypervisor, and end up with something far more efficient overall.

Re: Blockdiff: We built our own file format for VM disk snapshots

#17

Post by sumtechguy »

ori_b wrote: post #16

It's a bit surprising that they dismissed qcow2, because it does exactly what they want. It's also pretty easy to implement in a vm. The file format is a 2 level page table per snapshot, with pointers to blocks. I suspect they didn't really look at it enough. Here's the implementation I did for openbsd; it's around 700 lines, including the gunk to interface with the hypervisor. https://github.com/openbsd/src/blob/mas…

Also VDI/VHD was not mentioned which is interesting.

Re: Blockdiff: We built our own file format for VM disk snapshots

#18

Post by da-x »

I wonder didn't they used VDO thin provisioning with LVM2.

Also, a few years ago I've implemented VM management tool called 'vmess', in which the concept is to maintain a tree of QCOW2 files, which R/W snapshots are at the leafs and R/O snapshots are the nodes of the tree. The connection up to the root is made via QCOW2 backing-file store mechanism, so a newly created leaf starts a 0 space. I did this because libvirt+qemu impose various annoying limitations surrounding snapshots-with-in-qcow2, and I liked the idea of file-per-snapshot.

VDO: https://docs.kernel.org/admin-guide/device-mapper/vdo.html (original project URL: https://github.com/dm-vdo/kvdo )

vmess: https://github.com/da-x/vmess

Re: Blockdiff: We built our own file format for VM disk snapshots

#19

Post by [deleted] »

jeroenhd wrote: post #6
hanwenn wrote: post #4

Thanks for writing the blog post; it was a fascinating read! I was curious about a couple of things: * Have you considered future extensions where you can start the VM before you completed the FS copy? * You picked XFS over ZFS and BTRFS. Any reason why XFS in particular? * You casually mention that you wrote 'otterlink', your own hypervisor. Isn't that by itself a complicated effort worthy of a blog post? Or is it j…

Not the author, but: > Any reason why XFS in particular? XFS is still the default filesystem of choice for many enterprise systems. For instance, Red Hat states in their manual [1]: In general, use XFS unless you have a specific use case for ext4. There are good reasons to choose other file systems, but if you just want good performance on simple storage, XFS is a pretty good default. [1] https://docs.redhat.com/en/d…

[deleted]

Re: Blockdiff: We built our own file format for VM disk snapshots

#20

Post by whizzter »

ori_b wrote: post #16

It's a bit surprising that they dismissed qcow2, because it does exactly what they want. It's also pretty easy to implement in a vm. The file format is a 2 level page table per snapshot, with pointers to blocks. I suspect they didn't really look at it enough. Here's the implementation I did for openbsd; it's around 700 lines, including the gunk to interface with the hypervisor. https://github.com/openbsd/src/blob/mas…

Not entirely sure of their reasons but their main stumbling block was that they wanted snapshots in-VM, that seemed a bit like a counter-intuitive considering that part of their reason for a VM to begin with was to ensure security.
Post reply on HN