Recommended way to move existing VMs to secondary storage pool

I recently created a secondary storage pool which has faster underlying media than my primary. I would like to move some of the more performance sensitive VMs I have over to that pool

How can I go about doing that with the least amount of friction?

I noticed one post from a user that cloned the VMs to the new pool and then complained that they didn’t work. I can see a few reasons why - the clones having different names than the originals being one, potentially causing issues with RPC policy that was based solely on VM name. For whatever reason, that post didn’t get any replies, so it only served to make me cautious about using that same approach

Is cloning and then deleting the original VM the correct way to do this? Or is there some more “correct” way to move a VM from one storage pool to another in a way that everything is effectively the same once the operation is complete?

EDIT: There are reasons I opted to create a new storage pool rather than extend the existing one in one way or another … I realize extending would have saved me from this bit of hassle

Can you link to the post?

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.

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 .img files into the new pool (skip the -precache and the @ revision files), and adjust the volumes’ pool references in qubes.xml (after stopping the qubesd service). 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.

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 .img files into the new pool (skip the -precache and the @ revision files), and adjust the volumes’ pool references in qubes.xml (after stopping the qubesd service). 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 :slight_smile:

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

1 Like

I’ll go ahead and say that was probably the fault of the installer’s partitioning screen. If you step outside of the predefined automatic schemes, that thing is the devil.

1 Like