Hi,
How can I move only the root volume of a VM to another pool?
Or root and volatile?
Or only volatile?
Thereās no builtin support for moving volumes of an existing VM to another pool. You could use qvm-clone --pool=VOLUME=POOL ... and then delete the original VM. Or if you want to create a new VM, the same option can be passed to qvm-create.
But the ārootā volume of an AppVM is snap_on_start, so it is always located in the pool of its templateās ārootā volume. Itās not possible to change that.
2 Likes
Thanks for the quick reply.
What about the volatile? It is possible to have it in a different pool (we have that in the RAM qubes). But is it possible to have only it in a different pool?
Yes, thatās possible for āvolatileā and all other volumes that are not snap_on_start.
It can even be configured globally (instead of per VM) with qubes-prefs default_pool_volatile POOL, although this will only apply to VMs created after changing this global setting.
Could you explain how to do it? - Only volatile.
qvm-create --pool=volatile=yourpoolname --label=color newqube
or
qvm-clone --pool=volatile=yourpoolname originalqube clonedqube && qvm-remove originalqube
1 Like
There seems to be some misunderstanding.
I donāt want to move the whole VM to another pool. I want to move only itās volatile volume.
kernel - vm-pool
private - vm-pool
root - vm-pool
volatile - another-pool
Thatās sort of what --pool=volatile=yourpoolname doesā¦
If you need to avoid cloning the VM, I guess you could also edit /var/lib/qubes/qubes.xml manually (after stopping qubesd.service!), adjusting the volume XML elementās pool and vid attributes.
Thanks.
I hope I wonāt mess it up 
So, this seems to work! Even renaming the qube (which AFAIK works by copying it in the background) preserves the volume location which is cool.
Do you think we can use this for the RAM disposables that have their private as snap_on_start? Instead of copying them to RAM first, the private and volatile can simply be pointed to a location on a RAM drive. What do you think?
The only challenge is the need to stop/start qubesd.service. Is there a way around this?
1 Like
Itās conceptually impossible to do this with snap_on_start volumes. Those need to be snapshotted from their source volume (belonging to the template), which must happen in the source volumeās pool because that pool is what provides the mechanism for making a snapshot from a source volume to a destination volume.
I also wouldnāt recommend editing qubes.xml as part of some regular workflow. Youāre bound to break something sooner or later.
No
Itās conceptually impossible to do this with
snap_on_startvolumes. Those need to be snapshotted from their source volume (belonging to the template), which must happen in the source volumeās pool because that pool is what provides the mechanism for making a snapshot from a source volume to a destination volume.
How does it work with root (rw=False) and volatile then? It is possible to have them on different pools and CoW works. Why canāt we have this mechanism between source private (DVM template) and disposable private?
āvolatileā is never snap_on_start.
ārootā, if it is snap_on_start (which is the case for AppVMs and DisposableVMs), is always in the same pool as its source volume. When ārootā is rw=False, thereās in-VM support for redirecting writes to somewhere on āvolatileā. (So CoW for ārootā effectively happens inside the VM.) Thereās no such in-VM support for āprivateā with rw=False, because sadly nobody has implemented this.
thereās in-VM support for redirecting writes to somewhere on āvolatileā. (So CoW for ārootā effectively happens inside the VM.)
A-ha! Thanks for explaining.
Thereās no such in-VM support for āprivateā with
rw=False, because sadly nobody has implemented this.
Was that done deliberately?
Or can we somehow borrow the code that does it for root/volatile and adapt it?
Itās not deliberately absent. Implementing this in-VM support for the āprivateā volume is whatās missing for proper anti-forensic DisposableVMs, without any workarounds like temporary storage pools or RAM disks.
https://github.com/QubesOS/qubes-issues/issues/8704#issuecomment-1806860626
It seems we keep returning to that (itās in my bookmarks too).
Unfortunately, I donāt quite understand everything in the script you mentioned there (xen stuff), so it is still beyond my level. Is there any good info somewhere about these things, where one can learn?
BTW, there seems to be an error in the man pages of qvm-clone/create:
--pool=POOL:VOLUME, -p POOL:VOLUME
should likely be:
--pool=POOL=VOLUME, -p POOL=VOLUME
The only Xen specific thing there is how in-VM block devices correspond to volumes (xvda = ārootā, xdvb = āprivateā, xvdc = āvolatileā, xvdd = ākernelā).
Although Iām guessing the write redirection mechanism is probably not really something thatās written down anywhere. Itās a remnant of much older storage code, which has found a new use thanks to the new ephemeral āvolatileā feature.
Itās the other way around - VOLUME=POOL:
I am also not familiar with the intricacies of dracut. Looks complicated to me as a whole.
To find what is actually changed in the PR you link to, I am looking at (in a Debian VM):
diff -wy ./qubes-linux-utils/dracut/simple/init.sh /usr/lib/dracut/modules.d/90qubes-vm-simple/init.sh
and I donāt see many differences. Are you sure that particular code is doing what we are discussing?
Although Iām guessing the write redirection mechanism is probably not really something thatās written down anywhere.
Difficult to learn without info.
You are much more familiar with all that. Have you any idea why this was not touched since 2016? And what exactly needs to be done?
Wrong branch checked out?