Long time no blog post, I know. Maybe this has to do with the fact that all these posts have always been mental notes to myself first, and bits of lessons learned for the everybody else second and most of my mental notes end up in a wiki installation of mine, which gets updated way more often than this blog :-\

Anyway, the other day I was trying to build Android for a Sony phone but I didn't have enough disk space on my laptop to do so. Checking out all the sources and the build takes almost 200 GB of space - but luckily I had an (encrypted) external disk available that I could use just for this. Once plugged in and decrypted I realized that I really wanted the build environment to match the proposed requirements as closely as possible. Running a Fedora 28 desktop, let's use a Ubuntu 18.04 virtual machine for the actual build:

$ vboxmanage createhd disk --filename /opt/vm/generic/disk2.vdi --size 204800 --variant Fixed
$ vboxmanage storageattach ubuntu0 --storagectl SATA --device 0 --port 2 --type hdd --medium /opt/vm/generic/disk2.vdi

Note that we use a fixed disk image to prevent some nasty I/O errors within that virtual machine. With all that in place, we could start the machine and start to build AOSP. With regards to the aforementioned nasty I/O errors, I really must give credit to btrfs in this scenario with its built-in data checksums. I know, ZFS has this feature for ages but as this still isn't available upstream, btrfs is the next best thing.

So, while this was all fine and dandy, I still had this disk enclosure attached to my laptop and thus I couldn't move around with my laptop as I usually do. Talk about #firstworldproblems! :-) So, why not attach the enclosure to my "server" instead and see if I could somehow access the enclosure over WiFi? For some reason the first thing that pops into my head was NBD and while I had an network block device setup going in the past, it wasn't much fun and would fail too often. So let's use iSCSI instead.

Once the disk enclosure was attached to the "server", the block devices needed to be passed on to the Xen DomU that was supposed to present them as an iSCSI target:

$ lsblk /dev/sd[de]
NAME MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sdd    8:48   0 931.5G  0 disk 
sde    8:64   0 931.5G  0 disk 
 
$ xl block-attach virt2 'format=raw, vdev=xvdd, access=rw, target=/dev/sdd'
$ xl block-attach virt2 'format=raw, vdev=xvde, access=rw, target=/dev/sde'

In the virtual machine, the tgt needed to be installed and configured:

$ cat /etc/tgt/conf.d/md0.conf 
default-driver iscsi

# RAID-0
<target iqn.example.local:virt2-sdd>
    backing-store dev/sdd
    initiator-address 10.0.0.15
</target>

With that in place, we can go back to our laptop again and attach the disk:

$ iscsiadm -m discovery -t sendtargets -p virt2
10.0.0.24:3260,1 iqn.example.local:virt2-sdd

$ iscsiadm -m node --targetname "iqn.example.local:virt2-sdd" --portal 10.0.0.24:3260 --login

$ lsblk /dev/sdb 
NAME MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sdb    8:16   0  1.8T  0 disk

This worked :-)

Now we can decrypt the disk (sdb) again and make it available to our VirtualBox VM. It may not be the fastest setup (WiFi being the bottleneck), but it worked and now I can move around with my laptop again, with the disk enclosure sitting somewhere else. Yay! :-)