Xen VM Configuration example

[Elliott Mitchell]

I'm sending this to the list to provide another approach to this type of
installation.  I feel this is better adapted to the situation than the
currently visible examples.  Feel free to use this information in the
OpenWRT wiki.  Hopefully this is also a better example of a real world
OpenWRT in VM usage will look like.

I suggest the information on containers should be split into a separate
section.  This could be a sub-section of Virtualization, but containers
are far more limited than VMs.  Notably containers won't use OpenWRT's
kernel or drivers.


My recommended template configuration for OpenWRT in a Xen domain (VM):

```
type = "pv"
name = "openwrt"

memory = 128
vcpus = 2

# For use with rootfs/kernel.bin:
kernel = "/location/of/openwrt/kernel.bin"
extra = "root=/dev/xvda"

disk = [
	'vdev=xvda,format=raw,access=ro,target=/location/of/openwrt/rootfs.img',
	'vdev=xvdb,format=raw,access=rw,target=/location/of/openwrt/data.img',
]

# For use with -combined image:
#kernel = "/usr/libexec/grub/pvgrub-pv.bin"
#extra = "(hd1,gpt1)/boot/grub/grub.cfg"
#
#disk = [
#	'vdev=xvda,format=raw,access=rw,target=/location/of/openwrt/combo.img',
#]

vif = [
	'bridge=br-lan',
#	'bridge=br-wan',
]
pci = [
#	'0000:04:00.0',
]

nographic = 1
serial = 'pty'
```

Installation is done by downloading the files
openwrt-<version>-rootfs.img.gz (match with xvda/rootfs.img line) and
openwrt-<version>-kernel.bin (match with "kernel =" line).  The file
"data.img" is created by `truncate -s 32M data.img`, on first boot run
`xl console openwrt` and at the shell in the VM run
`mke2fs -t ext4 /dev/xvdb`.  After that reboot and "data.img" functions
as the overlaid filesystem.

A crucial advantage of this is the root filesystem and kernel are
completely read-only inside the VM.  No persistent modification of them
is possible (though the in-memory image can be modified).  This both
enhances security, and allows sharing them between multiple VMs which
handle different network functions (splitting NAT off allows rebooting
the hardware without dropping connections).

The combined image can also be used, but the installation and
configuration are a bit different (see commented lines above).
The "kernel =" line should be adjusted to match where PvGRUB is
installed.  For some distributions, PvGRUB may be available packaged, but
the installation path may vary.  Also PVH VMs may require a distinct
build of PvGRUB from other VM types.

Presently I'm trying to figure out which approach should be preferred.
My suspicion is security updates will be easier with the combined image.
This would outweigh the above advantage.


During initial bring-up the user may want public interfaces disabled.
As such both potential methods have been left commentted in this example.
Once initial configuration (setting root's password!) is done, the
publically visible interfaces can be enabled.  This could be a bridge to
hardware handled by another VM, or could be a PCI device being passed-in.
Often one would pass-in an 802.11 interface to allow radio support.

As of Xen 4.17 passing PCI devices into "PVH" VMs hadn't been enabled.
Until this is addressed the configuration 'type = "pv"' will be needed if
PCI passthrough is used.


Things done here mostly apply to other hypervisors, though the
configuration mechanism will be different.  Qemu definitely allows
passing in storage devices as read-only, passing in PCI cards, and
removing all emulated graphics devices.  Most (if not all) hypervisors
will allow passing in storage devices as read-only and passing PCI
devices in.

As to why one would do this.  At least one reason is pretty
straightforward, just in the exact opposite direction from what most
have been thinking.

Many latest generation semi-embedded devices advertise being capable of
functioning as NAS, and/or handling server functions.  If one has a
decent server computer which includes IOMMU and hypervisor, then instead
of shedding server functions onto a router, the server can instead
swallow the router.  A second NIC is $10 (assuming no on-motherboard
spare), a good 802.11 card is $50.

This seems appropriate for a home or small office.  Just an issue of
whether there is a server with available processor, memory, and slot(s).
This doesn't need a particularly powerful computer, but with everything
virtual machine, memory is a severe limiter.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg at m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445