Can you link to the post?
The original post was here. It probably didn’t receive responses because it seemed to be very narrowly focused on a specific appvm rather than the broader issue of migrating VMs. I don’t think it’s very interesting and I’m going to guess the user figured it out because they didn’t persist
Unfortunately there isn’t. Cloning, and then manually fixing up name-based configuration (like RPC policy and maybe netvm/template properties in some cases) is currently the way to do it.
Fair enough for me, I don’t mind the task of fixing up a policy entry or two
On the off chance that both your old and new pool is a file-reflink pool (Btrfs or XFS) rather than lvm_thin, a hacky but relatively straightforward approach would be to shut down the VMs, move the relevant volume
.imgfiles into the new pool (skip the-precacheand the@revision files), and adjust the volumes’ pool references inqubes.xml(after stopping thequbesdservice). There’s probably a similar way to transfer some of the underlying LVM Thin volumes between lvm_thin pools, but I’m not familiar enough with that.
Off chance- hah! You clearly underestimate the peculiarity of my installation 
That’s exactly what I have, though the installer did not consent, I had UX issues, maybe my fault. So I had to drop to the shell to set it up the way I have it. Nothing too wacky, just Linux RAID0+LUKS2+BTRFS for the system, and now a second RAID0+LUKS2+BTRFS for a secondary storage pool.
I never found myself needing the features LVM provides, so I always avoid the unnecessary layer of abstraction for (potential) performance issues and for simplicity. Less is always more. Though some distributions really get upset if you don’t have LVM underneath everything…
Thanks for the “hacky” idea, it seems no more hacky than the cloning approach
While I have you here, I know that I’ve read quite a few of your posts and comments on the forum. You’ve saved me tons of time, helping me to learn some important Qubes things rapidly, so thank you