Allow multiple source volume groups in an archive

[tasket]

Support use cases where a user wants to add volumes from different vgs or even non-CoW storage to a single archive.

• [ ] move vg/pool info into Volume()
• [ ] process deltas with an outer loop keyed on the source vg

[gdiShun]

Regarding this, I've noticed just changing aname under get_config(), at least for internal setups, seems to work fine for this. It seems like creating a new command line argument, like --aname="other_volume", could be a hacky way to accomplish this for people who can't wait for it to be implemented properly. But my question is, would this create any sort of problems with the backup integrity or anything like that? It seems to work fine, and it seems like everything is isolated within those aname folders, so my uneducated assumption is probably not. But would like to know for sure.

[boryeumao]

Tried poking around but hadn't found anything that may allow volumes from a second vg to go into the archive - Has this been implemented (in 0.3.1 20220804)?

(A related question, on Qubes: with "--local=qubes_dom0/vm-pool", I can add/send "root" to the archive, even though it resides in "qubes_dom0/root-pool". Is this expected? Thanks.)

[tasket]

@boryeumao @gdiShun There is a current option for supporting this use case: --meta-dir. The meta-dir defaults to '/var/lib' but setting it to someplace else (say, a custom subdirectory of /var/lib or /var/cache, etc.) allows you to init and use other archives with different VGs and other parameters.

Status on this issue (multi VGs in a single archive) is still unimplemented and TBH I'm not certain there is a great need for it. However, there will be at least one additional way to use different archives/VGs in v0.04... archive location has already been de-linked from archive metadata itself, so if you imagine 'aname' becomes the archive UUID then that opens up possibilities. See issue #60

[boryeumao]

@tasket Thanks. I will check out "--meta-dir", now that I understand what it is (should've checked the code more closely), and also v4 alpha.

If you could comment on the issue above on root being in a different t-pool from what is in "--local", that would be great. Thx

[tasket]

@boryeumao You can mix tpools (of the same VG) in a single archive and it won't affect Wyng operations except for receive. So if this is a Qubes tpool setup the volumes will all be under 'qubes_dom0' VG, and that's how I use it BTW with root volume mixed in with VM volumes.

When using receive and the volume doesn't already exist in the VG, Wyng will use the archive's pool setting to choose where to create the volume. Probably this could be improved in the future by allowing users to specify --local for receive or something similar.

[boryeumao]

@tasket Ah Yes precisely I wanted to be aware of anything to watch out for with mixing tpools. Thanks for clarifying.

[tasket]

The current v0.4 work in progress makes this issue largely moot. The new version will accept any suitable --local option at runtime, so you can update/add to an archive from different sources very much like you would with tar. The only limitation is that currently you can only specify one --local source at a time.