Create OpenBSD guest for Linux KVM (Kernel-based Virtual Machine) with 'virt-install'
Create OpenBSD guest for Linux KVM (Kernel-based Virtual Machine) with 'virt-install'
After playing with the Virtual Manager GUI, I concluded that it is nice, but that a command line approach suited me better. From the virt-install(1) man page:
Quote:
virt-install is a command line tool for creating new KVM, Xen, or Linux container guests using the "libvirt" hypervisor management library. See the EXAMPLES section at the end of this document to quickly get started.
virt-install tool supports graphical installations using (for example) VNC or SPICE, as well as text mode installs over serial console. The guest can be configured to use one or more virtual disks, network interfaces, audio devices, physical USB or PCI devices, among others.
The installation media can be held locally or remotely on NFS, HTTP, FTP servers. In the latter case "virt-install" will fetch the minimal files necessary to kick off the installation process, allowing the guest to fetch the rest of the OS distribution as needed. PXE booting, and importing an existing disk image (thus skipping the install phase) are also supported.
Given suitable command line arguments, "virt-install" is capable of running completely unattended, with the guest 'kickstarting' itself too. This allows for easy automation of guest installs. An interactive mode is also available with the --prompt option, but this will only ask for the minimum required options.
|
Initially I used a shell script, but switched to a Makefile approach. The first part defines some variables to allow easy customization
Code:
# - Makefile to create OpenBSD guest VM with serial console and second disk
# - for '/usr/ports'
# - DOMAIN name is also used as disk image file ....
DOMAIN = OBSD-x3
IMAGEDIR = /var/lib/libvirt/images
IMAGEFILE = ${IMAGEDIR}/${DOMAIN}.img
DEBUG = --dry-run
DEBUG =
The first Makefile target is 'create':
Code:
create :
virt-install \
--connect=qemu:///system \
--name="${DOMAIN}" \
--ram=2048 \
--vcpus=2 \
--description 'OpenBSD virt-install with serial' \
--os-type=unix \
--os-variant=openbsd4 \
--cdrom=http://hercules.utp.xnet/snapshots/amd64 \
--disk path=${IMAGEFILE},size=8,bus=virtio \
--disk path=${IMAGEDIR}/${DOMAIN}_ports,size=8,bus=virtio \
--network bridge=br0,model=virtio \
--graphics vnc \
--serial dev,path=/dev/ttyS0 \
${DEBUG}
An explanation of the options, where the quotes are from the virt-install(1) man page :
- --connect=qemu:///system
Although not strictly needed for KVM, I put it there because the --connect option allows you to use for example Xen
with xen:///.
- --name="${DOMAIN}"
Quote:
Name of the new guest virtual machine instance. This must be unique amongst all guests known to the hypervisor on the connection, including those not currently active. To re-define an existing guest, use the virsh(1) tool to shut it down ('virsh shutdown') & delete ('virsh undefine') it prior to running "virt-install".
|
- --ram=2048
Quote:
Memory to allocate for guest instance in megabytes. If the hypervisor does not have enough free memory, it is usual for it to automatically take memory away from the host operating system to satisfy this allocation.
|
- --vcpus=2
Quote:
Number of virtual cpus to configure for the guest. If 'maxvcpus' is specified, the guest will be able to hotplug up to MAX vcpus while the guest is running, but will startup with VCPUS.
CPU topology can additionally be specified with sockets, cores, and threads. If values are omitted, the rest will be autofilled preferring sockets over cores over threads.
|
- --description 'OpenBSD virt-install with serial'
Quote:
Human readable text description of the virtual machine. This will be stored in the guests XML configuration for access by other applications.
|
- --os-type=unix
Quote:
Optimize the guest configuration for a type of operating system (ex. 'linux', 'windows'). This will attempt to pick the most suitable ACPI & APIC settings, optimally supported mouse drivers, virtio, and generally accommodate other operating system quirks.
By default, virt-install will attempt to auto detect this value from the install media (currently only supported for URL installs). Autodetection can be disabled with the special value 'none'
|
- --os-variant=openbsd4
Quote:
Further optimize the guest configuration for a specific operating system variant (ex. 'fedora8', 'winxp'). This parameter is optional, and does not require an "--os-type" to be specified.
By default, virt-install will attempt to auto detect this value from the install media (currently only supported for URL installs). Autodetection can be disabled with the special value 'none'.
If the special value 'list' is passed, virt-install will print the full list of variant values and exit. The printed format is not a stable interface, DO NOT PARSE IT.
If the special value 'none' is passed, no os variant is recorded and OS autodetection is disabled.
|
A sample of the these variants:
Code:
# virt-install --os-variant=list
...
win2k3 : Microsoft Windows Server 2003
openbsd4 : OpenBSD 4.x
freebsd8 : FreeBSD 8.x
freebsd7 : FreeBSD 7.x
freebsd6 : FreeBSD 6.x
solaris9 : Sun Solaris 9
solaris10 : Sun Solaris 10
opensolaris : Sun OpenSolaris
...
- --cdrom=http://hercules.utp.xnet/snapshots/amd64
Quote:
File or device use as a virtual CD-ROM device for fully virtualized guests. It can be path to an ISO image, or to a CDROM device. It can also be a URL from which to fetch/access a minimal boot ISO image. The URLs take the same format as described for the "--location" argument. If a cdrom has been specified via the "--disk" option, and neither "--cdrom" nor any other install option is specified, the "--disk" cdrom is used as the install media.
-l LOCATION, --location=LOCATION
Distribution tree installation source. virt-install can recognize certain distribution trees and fetches a bootable kernel/initrd pair to launch the install.
With libvirt 0.9.4 or later, network URL installs work for remote connections. virt-install will download kernel/initrd to the local machine, and then upload the media to the remote host. This option requires the URL to be accessible by both the local and remote host.
|
This gave me quite some trouble because the OpenBSD ftp/http layout, that I copied to my local webserver 'hercules', is not recognized. The nginx access log illustrates what is attempted:
Code:
# cut -d ' ' -f '6-' nginx-log.txt
"HEAD /snapshots/amd64/.treeinfo HTTP/1.1" 404 0 "-" "Python-urllib/2.7"
"HEAD /snapshots/amd64/Fedora HTTP/1.1" 404 0 "-" "Python-urllib/2.7"
"HEAD /snapshots/amd64/Server HTTP/1.1" 404 0 "-" "Python-urllib/2.7"
"HEAD /snapshots/amd64/Client HTTP/1.1" 404 0 "-" "Python-urllib/2.7"
"HEAD /snapshots/amd64/RedHat HTTP/1.1" 404 0 "-" "Python-urllib/2.7"
"HEAD /snapshots/amd64/CentOS HTTP/1.1" 404 0 "-" "Python-urllib/2.7"
"HEAD /snapshots/amd64/SL HTTP/1.1" 404 0 "-" "Python-urllib/2.7"
"HEAD /snapshots/amd64/directory.yast HTTP/1.1" 404 0 "-" "Python-urllib/2.7"
"HEAD /snapshots/amd64/current/images/MANIFEST HTTP/1.1" 404 0 "-" "Python-urllib/2.7"
"HEAD /snapshots/amd64/daily/MANIFEST HTTP/1.1" 404 0 "-" "Python-urllib/2.7"
"HEAD /snapshots/amd64/current/images/MANIFEST HTTP/1.1" 404 0 "-" "Python-urllib/2.7"
"HEAD /snapshots/amd64/install/netboot/version.info HTTP/1.1" 404 0 "-" "Python-urllib/2.7"
"HEAD /snapshots/amd64/initrd.gz HTTP/1.1" 404 0 "-" "Python-urllib/2.7"
"HEAD /snapshots/amd64/VERSION HTTP/1.1" 404 0 "-" "Python-urllib/2.7"
"HEAD /snapshots/amd64/VERSION HTTP/1.1" 404 0 "-" "Python-urllib/2.7"
"HEAD /snapshots/amd64/boot/platform/i86xpv/kernel/unix HTTP/1.1" 404 0 "-" "Python-urllib/2.7"
"HEAD /snapshots/amd64/platform/i86xpv/kernel/unix HTTP/1.1" 404 0 "-" "Python-urllib/2.7"
"HEAD /snapshots/amd64/STARTUP/XNLOADER.SYS HTTP/1.1" 404 0 "-" "Python-urllib/2.7"
"HEAD /snapshots/amd64/images/pxeboot/vmlinuz HTTP/1.1" 404 0 "-" "Python-urllib/2.7"
"HEAD /snapshots/amd64/images/boot.iso HTTP/1.1" 200 0 "-" "Python-urllib/2.7"
"GET /snapshots/amd64/images/boot.iso HTTP/1.1" 200 7710720 "-" "urlgrabber/3.9.1"
As you can see some very Linux specific boot file configurations are probed.
The work around was to create a sub-directory images and within this directory a boot.iso link to the OpenBSD cd56.iso
Code:
/home/www/snapshots/amd64/images:
lrwxr-xr-x 1 root wheel 34 Dec 1 17:54 boot.iso -> /home/www/snapshots/amd64/cd56.iso
My kvm-image.sh script to automate this boring task:
Code:
#!/bin/sh
# create proper directory for virt-install
ARCH=amd64
ISO=cd56.iso
WEB_DIR="/home/www/snapshots/${ARCH}"
mkdir -p ${WEB_DIR}/images
ln -s ${WEB_DIR}/${ISO} ${WEB_DIR}/images/boot.iso
ls -lR ${WEB_DIR}
ls -nT ${WEB_DIR} > ${WEB_DIR}/index.txt
- --disk path=${IMAGEFILE},size=8,bus=virtio
--disk path=${IMAGEDIR}/ports,size=8,bus=virtio
Quote:
--disk=DISKOPTS
Specifies media to use as storage for the guest, with various options. The general format of a disk string is
--disk opt1=val1,opt2=val2,...
To specify media, the command can either be:
--disk /some/storage/path,opt1=val1
or explicitly specify one of the following arguments:
path
A path to some storage media to use, existing or not. Existing media can be a file or block device. If installing on a remote host, the existing media must be shared as a libvirt storage volume.
Specifying a non-existent path implies attempting to create the new storage, and will require specifying a 'size' value. If the base directory of the path is a libvirt storage pool on the host, the new storage will be created as a libvirt storage volume. For remote hosts, the base directory is required to be a storage pool if using this method.
bus
Disk bus type. Value can be 'ide', 'sata', 'scsi', 'usb', 'virtio' or 'xen'. The default is hypervisor dependent since not all hypervisors support all bus types.
|
- --network bridge=br0,model=virtio
Quote:
-w NETWORK, --network=NETWORK,opt1=val1,opt2=val2
Connect the guest to the host network. The value for "NETWORK" can take one
of 3 formats:
bridge=BRIDGE
Connect to a bridge device in the host called "BRIDGE". Use this option if the host has static networking config & the guest requires full outbound and inbound connectivity to/from the LAN. Also use this if live migration will be used with this guest.
network=NAME
Connect to a virtual network in the host called "NAME". Virtual networks can be listed, created, deleted using the "virsh" command line tool. In an unmodified install of "libvirt" there is usually a virtual network with a name of "default". Use a virtual network if the host has dynamic networking (eg NetworkManager), or using wireless. The guest will be NATed to the LAN by whichever connection is active.
[snip]
Other available options are:
model
Network device model as seen by the guest. Value can be any nic model supported by the hypervisor, e.g.: 'e1000', 'rtl8139', 'virtio', ...
mac
Fixed MAC address for the guest; If this parameter is omitted, or the value "RANDOM" is specified a suitable address will be randomly generated. For Xen virtual machines it is required that the first 3 pairs in the MAC address be the sequence '00:16:3e', while for QEMU or KVM virtual machines it must be '52:54:00'.
|
The mac option is useful to assign a fixed IP address/hostname through a DHCPD configuration file entry like:
Code:
host static-client {
hardware ethernet a0:1d:48:97:5b:74 ;
#fixed-address ml310e.utp.xnet ;
fixed-address 192.168.222.222 ;
}
- --graphics vnc
Quote:
Specifies the graphical display configuration. This does not configure any virtual hardware, just how the guest's graphical display can be accessed. Typically the user does not need to specify this option, virt-install will try and choose a useful default, and launch a suitable connection.
vnc
Setup a virtual console in the guest and export it as a VNC server in the host. Unless the "port" parameter is also provided, the VNC server will run on the first free port number at 5900 or above. The actual VNC display allocated can be obtained using the "vncdisplay" command to "virsh" (or virt-viewer(1) can be used which handles this detail for the use).
|
- --serial dev,path=/dev/ttyS0
Quote:
Host device. For serial devices, this could be /dev/ttyS0. For parallel devices, this could be /dev/parport0.
|
This is the option that allows the KVM guest (OpenBSD) to use the serial port of the KVM host (Linux Mint). I use a HP Proliant, which like most real servers still features a serial port. By connecting a serial cable from my OpenBSD workstation to the Proliant, I can use tip(1) to capture output during the install. Or login. Or provide trace output in case of a crash.
- --dry-run
Quote:
Proceed through the guest creation process, but do NOT create storage devices, change host device configuration, or actually teach libvirt about the guest. virt-install may still fetch install media, since this is required to properly detect the OS to install.
|
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump
Last edited by J65nko; 7th December 2014 at 11:57 PM.
Reason: Added 'bus=virtio" to "--disk" options.
|