-----BEGIN PGP SIGNED MESSAGE-----
On Fri, Aug 21, 2015 at 10:33:05PM -0700, Eric Shelton wrote:
> Basically, if libvirt can be updated to support nested HVM, the below will
> probably work by merely using a custom config file.
> Inspired by the recent success with a graphics card passthrough that
> employed directly calling 'xl create', I thought I would try out a few
> things. It turns out that by enabling nested HVM, it is possible to
> successfully run Qubes R3 rc2 within itself, including with networking.
Nice work! :)
> Step 1: Create a domain using Qubes VM Manager. In this example, I called
> it 'qtest'.
> Step 2: Tweak install-qubesr3.cfg to match your particular paths, including
> to the Qubes ISO.
> Step 3: Keep running 'sudo xl mem-set dom0 2200' and 'sudo xl -vvv create
> ./install-qubesr3.cfg' until qemu starts up successfully (it doesn't seem
> to know how to play nicely with memory ballooning).
You can touch /var/run/qubes/do-not-membalance just for starting the VM
- - while this file is present qmemman will not redistribute free memory.
> This will bring up an
> SDL window - you will be running qubes upstream.
Why can't the target qemu ("traditional", in stubdomain) be used for
installation? Some bugs? Missing features?
> Step 4: Run the Qubes installer. Automatic disk configuration will not
> work, you will have to manually create /boot and / partitions. Standard
> partitions worked for me.
> Step 5: After the first shutdown after the install, do step 3 again. Have
> it create service and default domains. At the end, you will get an error
> message. Just close the window, click the Finish button, and log in. Only
> dom0 will come up, sys-net still needs a little reconfiguration to work.
> Step 6: Fixing things up:
> qvm-prefs -s sys-net pcidevs "['00:04.0']" (might already be set to
> qvm-prefs -s sys-net pci_strictreset False (this is what caused the
> error message)
> edit /boot/grub2/grub.cfg - set the Linux kernel command line to include 'modprobe=xen-pciback.passthrough=1
I don't think xen-pciback.hide is needed - it should be automatically
generated by initramfs scripts (00:04.0 is network adapter, right?).
> At this point, you could reboot and run step 3 again. sys-net will even
> start up now, and you can set the network adapter for manual configuration.
> However, networking will not work, because qemu upstream runs in dom0, and
> can't get through to the real sys-firewall. So, not it's time to use qemu
> traditional in a stub domain.
> Step 7:Tweak run-qubesr3.cfg to match your particular paths.
> Step 8: Keep running 'sudo xl mem-set dom0 2200' and 'sudo xl -vvv create
> ./run-qubesr3.cfg' until qemu starts up successfully.
> Problem: Qubes has replaced the display pipeline for its secure display
> setup, but the domain was started outside of the Qubes framework.
> Solution: _right_ after step 8, run 'xl list' to get the domain IDs for the
> HVM domain (n) and its stub domain (n+1). Then run these:
> sudo /usr/sbin/qubesdb-daemon <HVM domain ID> qtest
> sudo /usr/bin/qubes-guid -d <stub domain ID> -t <HVM domain ID> -N qtest
> -c 0x73d216 -i /usr/share/icons/hicolor/128x128/devices/appvm-green.png -l
> <HVM domain ID> -q
I think sudo is not needed here.
> New problem: this clobbers the window manager. However, you can see Qubes
> start up in its window and interact with it. Now networking works just
> fine (manually configure networking if you did not before). A rough proof
> of concept for running nested Qubes.
> As I mentioned at the beginning, if libvirt can be updated to support the
> nestedhvm feature used in the attached xl config files, all of the nasty
> mucking about with 'xl create' can go away. Steps 5 and 6 will still be
> necessary (although possibly only the strict reset part of Setp 6 is
> required) to deal with the reset issue.
> Once nested HVM support is in place, hopefully Qubes devs will find some
> benefit of a Qubes within Qubes setup, and this becomes something more than
> a stupid VM trick. Qubes starts up pretty fast in a VM, particularly the
> second time around.
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
-----END PGP SIGNATURE-----