Some VMs on an external disk (unavailable at boot)

[Stefan Schlott]

Hi,

I'd like to have some VMs on a secondary disk. I successfully followed
the guidelines from https://www.qubes-os.org/doc/secondary-storage/

Troubles arise when the disk is not available at boot time. I'm working
on some mount/unmount scripts which adds/removes the storage pools. But
it seems that this is not enough: Upon reboot (with the pool from the
secondary disk removed), the qubesd terminates with an exception,
causing the whole Qubes installation not to boot properly.

First, I added some try-catch in qubes/app.py (line 905) so the qubesd
starts even if some VMs cause errors. Perhaps this would be a general
nice behaviour?

After re-adding the pool, all VMs from the secondary disk pointed to the
primary pool. Manually editing the /var/lib/qubes/qubes.xml fixed the
issue, so I now have a working system again.

My question: Is there a procedure to properly handle such a second disk
(unavailable at boot time)?


Stefan.

[Stuart Perkins]

I do not know the official stance or method, but I symbolically link from the standard appVM location to my other drive where I have the larger appVM's. Mine is always available so I don't know if Qubes would boot if it weren't, but it is a thought...obviously the drive would need to be available to start the appVM's located thereon.

[Stefan Schlott]

On 2/4/19 5:59 PM, Stuart Perkins wrote:

> I do not know the official stance or method, but I symbolically link from the standard appVM location to my other drive where I have the larger appVM's. Mine is always available so I don't know if Qubes would boot if it weren't, but it is a thought...obviously the drive would need to be available to start the appVM's located thereon.

This is what I did on Qubes 3.2. On Qubes 4.0, I used the new thin pool
provisioning, so the symlink trick doesn't work anymore...

Stefan.

[Stuart Perkins]

Ah, but if the path must be "provisioned" in order to boot qubes itself, that sounds like a more difficult way to do it.

[Chris Laprise]

The workaround would be to have either A) installed Qubes with a regular
filesystem (without thin LVM) or B) setup a secondary but "always
available" non-LVM pool on your internal drive. Then symlinks can be used.

@Stefan: Would you post this as a feature-request issue? If not, I may
do so because having Qubes support removable storage pools automatically
could be valuable to a lot of people.

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[prei...@gmail.com]

On 2/4/19 4:42 PM, Chris Laprise wrote:
> On 2/4/19 4:12 PM, Stuart Perkins wrote:
>>
>>
>> On Mon, 4 Feb 2019 21:27:44 +0100
>> Stefan Schlott <ste...@ploing.de> wrote:
>>
>>> On 2/4/19 5:59 PM, Stuart Perkins wrote:
>>>
>>>> I do not know the official stance or method, but I symbolically
>>>> link from the standard appVM location to my other drive where I
>>>> have the larger appVM's.  Mine is always available so I don't know
>>>> if Qubes would boot if it weren't, but it is a thought...obviously
>>>> the drive would need to be available to start the appVM's located
>>>> thereon.
>>>
>>> This is what I did on Qubes 3.2. On Qubes 4.0, I used the new thin pool
>>> provisioning, so the symlink trick doesn't work anymore...
>>>
>>> Stefan.
>>>
>>>
>>
>> Ah, but if the path must be "provisioned" in order to boot qubes
>> itself, that sounds like a more difficult way to do it.
>>
>
> The workaround would be to have either A) installed Qubes with a
> regular filesystem (without thin LVM) or B) setup a secondary but
> "always available" non-LVM pool on your internal drive. Then symlinks
> can be used.
>
> @Stefan: Would you post this as a feature-request issue? If not, I may
> do so because having Qubes support removable storage pools
> automatically could be valuable to a lot of people.
>

Here are my notes on adding a 2nd disk to Qubes 4.  I think they
correctly document what I did, but it was several months ago.


There was a page called this that I referred to. 
https://www.qubes-os.org/secondary-storage

I don't see that page today.


sudo su -

cryptsetup luksFormat --hash=sha512 --key-size=512
--cipher=aes-xts-plain64 --verify-passphrase /dev/sdb

use blkid to see the new item


add it to  /etc/crypttab

reboot

pvcreate /dev/mapper/luks-c38b8e68-ce41-4474-81c9-226599812715

vgcreate qubes_data /dev/mapper/luks-c38b8e68-ce41-4474-81c9-226599812715

lvcreate -T -n qubes_disk2 -l +100%FREE qubes_data

qvm-pool --add pool_qubes_disk2 lvm_thin -o
volume_group=qubes_data,thin_pool=qubes_disk2,revisions_to_keep=2

# to create vm using this pool
qvm-create -P pool_qubes_disk2 --label blue data

[prei...@gmail.com]

On 2/12/19 7:37 PM, prei...@gmail.com wrote:
> There was a page called this that I referred to. 
> https://www.qubes-os.org/secondary-storage

My mistake.  It's here:

https://www.qubes-os.org/doc/secondary-storage/

[unman]

On Tue, Feb 12, 2019 at 07:37:51PM -0500, prei...@gmail.com wrote:
>
>
> There was a page called this that I referred to. 
> https://www.qubes-os.org/secondary-storage
>
> I don't see that page today.
>

It's at https://www.qubes-os.org/doc/secondary-storage