https://wiki.archlinux.org/api.php?action=feedcontributions&user=Asdil12&feedformat=atomArchWiki - User contributions [en]2024-03-28T18:07:05ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=QEMU&diff=518525QEMU2018-04-24T15:22:13Z<p>Asdil12: /* Tap networking with QEMU */ -net --> -netdev</p>
<hr />
<div>[[Category:Emulation]]<br />
[[Category:Hypervisors]]<br />
[[de:Qemu]]<br />
[[es:QEMU]]<br />
[[fr:Qemu]]<br />
[[ja:QEMU]]<br />
[[ru:QEMU]]<br />
[[zh-hans:QEMU]]<br />
[[zh-hant:QEMU]]<br />
{{Related articles start}}<br />
{{Related|:Category:Hypervisors}}<br />
{{Related|Libvirt}}<br />
{{Related|PCI passthrough via OVMF}}<br />
{{Related articles end}}<br />
<br />
According to the [http://wiki.qemu.org/Main_Page QEMU about page], "QEMU is a generic and open source machine emulator and virtualizer."<br />
<br />
When used as a machine emulator, QEMU can run OSes and programs made for one machine (e.g. an ARM board) on a different machine (e.g. your x86 PC). By using dynamic translation, it achieves very good performance.<br />
<br />
QEMU can use other hypervisors like [[Xen]] or [[KVM]] to use CPU extensions ([[Wikipedia:Hardware-assisted virtualization|HVM]]) for virtualization. When used as a virtualizer, QEMU achieves near native performances by executing the guest code directly on the host CPU.<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|qemu}} package (or {{Pkg|qemu-headless}} for the version without GUI) and below optional packages for your needs:<br />
<br />
* {{Pkg|qemu-arch-extra}} - extra architectures support<br />
* {{Pkg|qemu-block-gluster}} - [[Glusterfs]] block support<br />
* {{Pkg|qemu-block-iscsi}} - [[iSCSI]] block support<br />
* {{Pkg|qemu-block-rbd}} - RBD block support <br />
* {{Pkg|samba}} - [[Samba|SMB/CIFS]] server support<br />
<br />
== Graphical front-ends for QEMU ==<br />
<br />
Unlike other virtualization programs such as [[VirtualBox]] and [[VMware]], QEMU does not provide a GUI to manage virtual machines (other than the window that appears when running a virtual machine), nor does it provide a way to create persistent virtual machines with saved settings. All parameters to run a virtual machine must be specified on the command line at every launch, unless you have created a custom script to start your virtual machine(s). However, there are several GUI front-ends for QEMU:<br />
<br />
* {{Pkg|virt-manager}}<br />
* {{Pkg|gnome-boxes}}<br />
* {{AUR|qemu-launcher}}<br />
* {{AUR|qtemu}}<br />
* {{AUR|aqemu}}<br />
<br />
Additional front-ends with QEMU support are available for [[libvirt]].<br />
<br />
== Creating new virtualized system ==<br />
<br />
=== Creating a hard disk image ===<br />
<br />
{{Tip|See the [https://en.wikibooks.org/wiki/QEMU/Images QEMU Wikibook] for more information on QEMU images.}}<br />
<br />
To run QEMU you will need a hard disk image, unless you are booting a live system from CD-ROM or the network (and not doing so to install an operating system to a hard disk image). A hard disk image is a file which stores the contents of the emulated hard disk.<br />
<br />
A hard disk image can be ''raw'', so that it is literally byte-by-byte the same as what the guest sees, and will always use the full capacity of the guest hard drive on the host. This method provides the least I/O overhead, but can waste a lot of space, as not-used space on the guest cannot be used on the host.<br />
<br />
Alternatively, the hard disk image can be in a format such as ''qcow2'' which only allocates space to the image file when the guest operating system actually writes to those sectors on its virtual hard disk. The image appears as the full size to the guest operating system, even though it may take up only a very small amount of space on the host system. This image format also supports QEMU snapshotting functionality (see [[#Creating and managing snapshots via the monitor console]] for details). However, using this format instead of ''raw'' will likely affect performance.<br />
<br />
QEMU provides the {{ic|qemu-img}} command to create hard disk images. For example to create a 4 GB image in the ''raw'' format:<br />
<br />
$ qemu-img create -f raw ''image_file'' 4G<br />
<br />
You may use {{ic|-f qcow2}} to create a ''qcow2'' disk instead.<br />
<br />
{{Note|You can also simply create a ''raw'' image by creating a file of the needed size using {{ic|dd}} or {{ic|fallocate}}.}}<br />
<br />
{{Warning|If you store the hard disk images on a [[Btrfs]] file system, you should consider disabling [[Btrfs#Copy-on-Write (CoW)|Copy-on-Write]] for the directory before creating any images.}}<br />
<br />
==== Overlay storage images ====<br />
<br />
You can create a storage image once (the 'backing' image) and have QEMU keep mutations to this image in an overlay image. This allows you to revert to a previous state of this storage image. You could revert by creating a new overlay image at the time you wish to revert, based on the original backing image.<br />
<br />
To create an overlay image, issue a command like:<br />
<br />
$ qemu-img create -o backing_file=''img1.raw'',backing_fmt=''raw'' -f ''qcow2'' ''img1.cow''<br />
<br />
After that you can run your QEMU VM as usual (see [[#Running virtualized system]]):<br />
<br />
$ qemu-system-x86_64 ''img1.cow''<br />
<br />
The backing image will then be left intact and mutations to this storage will be recorded in the overlay image file.<br />
<br />
When the path to the backing image changes, repair is required.<br />
<br />
{{Warning|The backing image's absolute filesystem path is stored in the (binary) overlay image file. Changing the backing image's path requires some effort.}}<br />
<br />
Make sure that the original backing image's path still leads to this image. If necessary, make a symbolic link at the original path to the new path. Then issue a command like:<br />
<br />
$ qemu-img rebase -b ''/new/img1.raw'' ''/new/img1.cow''<br />
<br />
At your discretion, you may alternatively perform an 'unsafe' rebase where the old path to the backing image is not checked:<br />
<br />
$ qemu-img rebase -u -b ''/new/img1.raw'' ''/new/img1.cow''<br />
<br />
==== Resizing an image ====<br />
<br />
{{Warning|Resizing an image containing an NTFS boot file system could make the operating system installed on it unbootable. For full explanation and workaround see [http://tjworld.net/wiki/Howto/ResizeQemuDiskImages].}}<br />
<br />
The {{ic|qemu-img}} executable has the {{ic|resize}} option, which enables easy resizing of a hard drive image. It works for both ''raw'' and ''qcow2''. For example, to increase image space by 10 GB, run:<br />
<br />
$ qemu-img resize ''disk_image'' +10G<br />
<br />
After enlarging the disk image, you must use file system and partitioning tools inside the virtual machine to actually begin using the new space. When shrinking a disk image, you must '''first reduce the allocated file systems and partition sizes''' using the file system and partitioning tools inside the virtual machine and then shrink the disk image accordingly, otherwise shrinking the disk image will result in data loss!<br />
<br />
=== Preparing the installation media ===<br />
<br />
To install an operating system into your disk image, you need the installation medium (e.g. optical disk, USB-drive, or ISO image) for the operating system. The installation medium should not be mounted because QEMU accesses the media directly.<br />
<br />
{{Tip|If using an optical disk, it is a good idea to first dump the media to a file because this both improves performance and does not require you to have direct access to the devices (that is, you can run QEMU as a regular user without having to change access permissions on the media's device file). For example, if the CD-ROM device node is named {{ic|/dev/cdrom}}, you can dump it to a file with the command: {{bc|1=$ dd if=/dev/cdrom of=''cd_image.iso''}}}}<br />
<br />
=== Installing the operating system===<br />
<br />
This is the first time you will need to start the emulator. To install the operating system on the disk image, you must attach both the disk image and the installation media to the virtual machine, and have it boot from the installation media.<br />
<br />
For example on i386 guests, to install from a bootable ISO file as CD-ROM and a raw disk image:<br />
<br />
$ qemu-system-x86_64 -cdrom ''iso_image'' -boot order=d -drive file=''disk_image'',format=raw<br />
<br />
See {{man|1|qemu}} for more information about loading other media types (such as floppy, disk images or physical drives) and [[#Running virtualized system]] for other useful options.<br />
<br />
After the operating system has finished installing, the QEMU image can be booted directly (see [[#Running virtualized system]]).<br />
<br />
{{Warning|By default only 128 MB of memory is assigned to the machine. The amount of memory can be adjusted with the {{ic|-m}} switch, for example {{ic|-m 512M}} or {{ic|-m 2G}}.}}<br />
<br />
{{Tip|<br />
* Instead of specifying {{ic|1=-boot order=x}}, some users may feel more comfortable using a boot menu: {{ic|1=-boot menu=on}}, at least during configuration and experimentation.<br />
* If you need to replace floppies or CDs as part of the installation process, you can use the QEMU machine monitor (press {{ic|Ctrl+Alt+2}} in the virtual machine's window) to remove and attach storage devices to a virtual machine. Type {{ic|info block}} to see the block devices, and use the {{ic|change}} command to swap out a device. Press {{ic|Ctrl+Alt+1}} to go back to the virtual machine.}}<br />
<br />
== Running virtualized system ==<br />
<br />
{{ic|qemu-system-*}} binaries (for example {{ic|qemu-system-i386}} or {{ic|qemu-system-x86_64}}, depending on guest's architecture) are used to run the virtualized guest. The usage is:<br />
<br />
$ qemu-system-x86_64 ''options'' ''disk_image''<br />
<br />
Options are the same for all {{ic|qemu-system-*}} binaries, see {{man|1|qemu}} for documentation of all options.<br />
<br />
By default, QEMU will show the virtual machine's video output in a window. One thing to keep in mind: when you click inside the QEMU window, the mouse pointer is grabbed. To release it, press {{ic|Ctrl+Alt+g}}.<br />
<br />
{{Warning|QEMU should never be run as root. If you must launch it in a script as root, you should use the {{ic|-runas}} option to make QEMU drop root privileges.}}<br />
<br />
=== Enabling KVM ===<br />
<br />
KVM must be supported by your processor and kernel, and necessary [[kernel modules]] must be loaded. See [[KVM]] for more information.<br />
<br />
To start QEMU in KVM mode, append {{ic|-enable-kvm}} to the additional start options. To check if KVM is enabled for a running VM, enter the QEMU [https://en.wikibooks.org/wiki/QEMU/Monitor Monitor] using {{ic|Ctrl+Alt+Shift+2}}, and type {{ic|info kvm}}.<br />
<br />
{{Note|<br />
* If you start your VM with a GUI tool and experience very bad performance, you should check for proper KVM support, as QEMU may be falling back to software emulation.<br />
* KVM needs to be enabled in order to start Windows 7 and Windows 8 properly without a ''blue screen''.<br />
}}<br />
<br />
=== Enabling IOMMU (Intel VT-d/AMD-Vi) support ===<br />
<br />
First enable IOMMU, see [[PCI passthrough via OVMF#Setting up IOMMU]].<br />
<br />
Add {{ic|-device intel-iommu}} to create the IOMMU device:<br />
<br />
$ qemu-system-x86_64 '''-enable-kvm -machine q35,accel=kvm -device intel-iommu''' -cpu host ..<br />
<br />
{{Note|<br />
On Intel CPU based systems creating an IOMMU device in a QEMU guest with {{ic|-device intel-iommu}} will disable PCI passthrough with an error like: {{bc|Device at bus pcie.0 addr 09.0 requires iommu notifier which is currently not supported by intel-iommu emulation}} While adding the kernel parameter {{ic|1=intel_iommu=on}} is still needed for remapping IO (e.g. [[PCI_passthrough_via_OVMF#Using_vfio-pci|PCI passthrough with vfio-pci]]), {{ic|-device intel-iommu}} should not be set if PCI PCI passthrough is required.<br />
}}<br />
<br />
== Moving data between host and guest OS ==<br />
<br />
=== Network ===<br />
<br />
Data can be shared between the host and guest OS using any network protocol that can transfer files, such as [[NFS]], [[SMB]], [[Wikipedia:Network Block Device|NBD]], HTTP, [[Very Secure FTP Daemon|FTP]], or [[SSH]], provided that you have set up the network appropriately and enabled the appropriate services.<br />
<br />
The default user-mode networking allows the guest to access the host OS at the IP address 10.0.2.2. Any servers that you are running on your host OS, such as a SSH server or SMB server, will be accessible at this IP address. So on the guests, you can mount directories exported on the host via [[SMB]] or [[NFS]], or you can access the host's HTTP server, etc.<br />
It will not be possible for the host OS to access servers running on the guest OS, but this can be done with other network configurations (see [[#Tap networking with QEMU]]).<br />
<br />
=== QEMU's built-in SMB server ===<br />
<br />
QEMU's documentation says it has a "built-in" SMB server, but actually it just starts up [[Samba]] with an automatically generated {{ic|smb.conf}} file located at {{ic|/tmp/qemu-smb.''pid''-0/smb.conf}} and makes it accessible to the guest at a different IP address (10.0.2.4 by default). This only works for user networking, and this is not necessarily very useful since the guest can also access the normal [[Samba]] service on the host if you have set up shares on it.<br />
<br />
To enable this feature, start QEMU with a command like:<br />
<br />
$ qemu-system-x86_64 ''disk_image'' -net nic -net user,smb=''shared_dir_path''<br />
<br />
where {{ic|''shared_dir_path''}} is a directory that you want to share between the guest and host.<br />
<br />
Then, in the guest, you will be able to access the shared directory on the host 10.0.2.4 with the share name "qemu". For example, in Windows Explorer you would go to {{ic|\\10.0.2.4\qemu}}.<br />
<br />
{{Note|<br />
* If you are using sharing options multiple times like {{ic|1=-net user,smb=''shared_dir_path1'' -net user,smb=''shared_dir_path2''}} or {{ic|1=-net user,smb=''shared_dir_path1'',smb=''shared_dir_path2''}} then it will share only the last defined one.<br />
* If you cannot access the shared folder and the guest system is Windows, check that the [http://ecross.mvps.org/howto/enable-netbios-over-tcp-ip-with-windows.htm NetBIOS protocol is enabled] and that a firewall does not block [http://technet.microsoft.com/en-us/library/cc940063.aspx ports] used by the NetBIOS protocol.<br />
}}<br />
<br />
=== Mounting a partition inside a raw disk image ===<br />
<br />
When the virtual machine is not running, it is possible to mount partitions that are inside a raw disk image file by setting them up as loopback devices. This does not work with disk images in special formats, such as qcow2, although those can be mounted using {{ic|qemu-nbd}}.<br />
<br />
{{Warning|You must make sure to unmount the partitions before running the virtual machine again. Otherwise, data corruption is very likely to occur.}}<br />
<br />
==== With manually specifying byte offset ====<br />
<br />
One way to mount a disk image partition is to mount the disk image at a certain offset using a command like the following:<br />
<br />
# mount -o loop,offset=32256 ''disk_image'' ''mountpoint''<br />
<br />
The {{ic|1=offset=32256}} option is actually passed to the {{ic|losetup}} program to set up a loopback device that starts at byte offset 32256 of the file and continues to the end. This loopback device is then mounted. You may also use the {{ic|sizelimit}} option to specify the exact size of the partition, but this is usually unnecessary.<br />
<br />
Depending on your disk image, the needed partition may not start at offset 32256. Run {{ic|fdisk -l ''disk_image''}} to see the partitions in the image. fdisk gives the start and end offsets in 512-byte sectors, so multiply by 512 to get the correct offset to pass to {{ic|mount}}.<br />
<br />
==== With loop module autodetecting partitions ====<br />
<br />
The Linux loop driver actually supports partitions in loopback devices, but it is disabled by default. To enable it, do the following:<br />
<br />
* Get rid of all your loopback devices (unmount all mounted images, etc.).<br />
* [[Kernel_modules#Manual_module_handling|Unload]] the {{ic|loop}} kernel module, and load it with the {{ic|1=max_part=15}} parameter set. Additionally, the maximum number of loop devices can be controlled with the {{ic|max_loop}} parameter.<br />
<br />
{{Tip|You can put an entry in {{ic|/etc/modprobe.d}} to load the loop module with {{ic|1=max_part=15}} every time, or you can put {{ic|1=loop.max_part=15}} on the kernel command-line, depending on whether you have the {{ic|loop.ko}} module built into your kernel or not.}}<br />
<br />
Set up your image as a loopback device:<br />
<br />
# losetup -f -P ''disk_image''<br />
<br />
Then, if the device created was {{ic|/dev/loop0}}, additional devices {{ic|/dev/loop0pX}} will have been automatically created, where X is the number of the partition. These partition loopback devices can be mounted directly. For example:<br />
<br />
# mount /dev/loop0p1 ''mountpoint''<br />
<br />
To mount the disk image with ''udisksctl'', see [[Udisks#Mount loop devices]].<br />
<br />
==== With kpartx ====<br />
<br />
'''kpartx''' from the {{AUR|multipath-tools}} package can read a partition table on a device and create a new device for each partition. For example:<br />
# kpartx -a ''disk_image''<br />
<br />
This will setup the loopback device and create the necessary partition(s) device(s) in {{ic|/dev/mapper/}}.<br />
<br />
=== Mounting a partition inside a qcow2 image ===<br />
<br />
You may mount a partition inside a qcow2 image using {{ic|qemu-nbd}}. See [http://en.wikibooks.org/wiki/QEMU/Images#Mounting_an_image_on_the_host Wikibooks].<br />
<br />
=== Using any real partition as the single primary partition of a hard disk image ===<br />
<br />
Sometimes, you may wish to use one of your system partitions from within QEMU. Using a raw partition for a virtual machine will improve performance, as the read and write operations do not go through the file system layer on the physical host. Such a partition also provides a way to share data between the host and guest.<br />
<br />
In Arch Linux, device files for raw partitions are, by default, owned by ''root'' and the ''disk'' group. If you would like to have a non-root user be able to read and write to a raw partition, you need to change the owner of the partition's device file to that user.<br />
<br />
{{Warning|<br />
* Although it is possible, it is not recommended to allow virtual machines to alter critical data on the host system, such as the root partition.<br />
* You must not mount a file system on a partition read-write on both the host and the guest at the same time. Otherwise, data corruption will result.<br />
}}<br />
<br />
After doing so, you can attach the partition to a QEMU virtual machine as a virtual disk.<br />
<br />
However, things are a little more complicated if you want to have the ''entire'' virtual machine contained in a partition. In that case, there would be no disk image file to actually boot the virtual machine since you cannot install a bootloader to a partition that is itself formatted as a file system and not as a partitioned device with a MBR. Such a virtual machine can be booted either by specifying the [[kernel]] and [[initramfs|initrd]] manually, or by simulating a disk with a MBR by using linear [[RAID]].<br />
<br />
==== By specifying kernel and initrd manually ====<br />
<br />
QEMU supports loading [[Kernels|Linux kernels]] and [[initramfs|init ramdisks]] directly, thereby circumventing bootloaders such as [[GRUB]]. It then can be launched with the physical partition containing the root file system as the virtual disk, which will not appear to be partitioned. This is done by issuing a command similar to the following:<br />
<br />
{{Note|In this example, it is the '''host's''' images that are being used, not the guest's. If you wish to use the guest's images, either mount {{ic|/dev/sda3}} read-only (to protect the file system from the host) and specify the {{ic|/full/path/to/images}} or use some kexec hackery in the guest to reload the guest's kernel (extends boot time). }}<br />
<br />
$ qemu-system-x86_64 -kernel /boot/vmlinuz-linux -initrd /boot/initramfs-linux.img -append root=/dev/sda /dev/sda3<br />
<br />
In the above example, the physical partition being used for the guest's root file system is {{ic|/dev/sda3}} on the host, but it shows up as {{ic|/dev/sda}} on the guest.<br />
<br />
You may, of course, specify any kernel and initrd that you want, and not just the ones that come with Arch Linux.<br />
<br />
When there are multiple [[kernel parameters]] to be passed to the {{ic|-append}} option, they need to be quoted using single or double quotes. For example:<br />
<br />
... -append 'root=/dev/sda1 console=ttyS0'<br />
<br />
==== Simulate virtual disk with MBR using linear RAID ====<br />
<br />
A more complicated way to have a virtual machine use a physical partition, while keeping that partition formatted as a file system and not just having the guest partition the partition as if it were a disk, is to simulate a MBR for it so that it can boot using a bootloader such as GRUB.<br />
<br />
You can do this using software [[RAID]] in linear mode (you need the {{ic|linear.ko}} kernel driver) and a loopback device: the trick is to dynamically prepend a master boot record (MBR) to the real partition you wish to embed in a QEMU raw disk image.<br />
<br />
Suppose you have a plain, unmounted {{ic|/dev/hdaN}} partition with some file system on it you wish to make part of a QEMU disk image. First, you create some small file to hold the MBR:<br />
<br />
$ dd if=/dev/zero of=''/path/to/mbr'' count=32<br />
<br />
Here, a 16 KB (32 * 512 bytes) file is created. It is important not to make it too small (even if the MBR only needs a single 512 bytes block), since the smaller it will be, the smaller the chunk size of the software RAID device will have to be, which could have an impact on performance. Then, you setup a loopback device to the MBR file:<br />
<br />
# losetup -f ''/path/to/mbr''<br />
<br />
Let us assume the resulting device is {{ic|/dev/loop0}}, because we would not already have been using other loopbacks. Next step is to create the "merged" MBR + {{ic|/dev/hdaN}} disk image using software RAID:<br />
<br />
# modprobe linear<br />
# mdadm --build --verbose /dev/md0 --chunk=16 --level=linear --raid-devices=2 /dev/loop0 /dev/hda''N''<br />
<br />
The resulting {{ic|/dev/md0}} is what you will use as a QEMU raw disk image (do not forget to set the permissions so that the emulator can access it). The last (and somewhat tricky) step is to set the disk configuration (disk geometry and partitions table) so that the primary partition start point in the MBR matches the one of {{ic|/dev/hda''N''}} inside {{ic|/dev/md0}} (an offset of exactly 16 * 512 = 16384 bytes in this example). Do this using {{ic|fdisk}} on the host machine, not in the emulator: the default raw disc detection routine from QEMU often results in non-kilobyte-roundable offsets (such as 31.5 KB, as in the previous section) that cannot be managed by the software RAID code. Hence, from the the host:<br />
<br />
# fdisk /dev/md0<br />
<br />
Press {{ic|X}} to enter the expert menu. Set number of 's'ectors per track so that the size of one cylinder matches the size of your MBR file. For two heads and a sector size of 512, the number of sectors per track should be 16, so we get cylinders of size 2x16x512=16k.<br />
<br />
Now, press {{ic|R}} to return to the main menu.<br />
<br />
Press {{ic|P}} and check that the cylinder size is now 16k.<br />
<br />
Now, create a single primary partition corresponding to {{ic|/dev/hda''N''}}. It should start at cylinder 2 and end at the end of the disk (note that the number of cylinders now differs from what it was when you entered fdisk.<br />
<br />
Finally, 'w'rite the result to the file: you are done. You now have a partition you can mount directly from your host, as well as part of a QEMU disk image:<br />
<br />
$ qemu-system-x86_64 -hdc /dev/md0 ''[...]''<br />
<br />
You can, of course, safely set any bootloader on this disk image using QEMU, provided the original {{ic|/dev/hda''N''}} partition contains the necessary tools.<br />
<br />
===== Alternative: use nbd-server =====<br />
Instead of linear RAID, you may use {{ic|nbd-server}} (from the {{pkg|nbd}} package) to create an MBR wrapper for QEMU.<br />
<br />
Assuming you have already set up your MBR wrapper file like above, rename it to {{ic|wrapper.img.0}}. Then create a symbolic link named {{ic|wrapper.img.1}} in the same directory, pointing to your partition. Then put the following script in the same directory:<br />
<br />
#!/bin/sh<br />
dir="$(realpath "$(dirname "$0")")"<br />
cat >wrapper.conf <<EOF<br />
[generic]<br />
allowlist = true<br />
listenaddr = 127.713705<br />
port = 10809<br />
<br />
[wrap]<br />
exportname = $dir/wrapper.img<br />
multifile = true<br />
EOF<br />
<br />
nbd-server \<br />
-C wrapper.conf \<br />
-p wrapper.pid \<br />
"$@"<br />
<br />
The {{ic|.0}} and {{ic|.1}} suffixes are essential; the rest can be changed. After running the above script (which you may need to do as root to make sure nbd-server is able to access the partition), you can launch QEMU with:<br />
<br />
qemu-system-x86_64 -drive file=nbd:127.713705:10809:exportname=wrap ''[...]''<br />
<br />
== Networking ==<br />
<br />
{{Style|Network topologies (sections [[#Host-only networking]], [[#Internal networking]] and info spread out across other sections) should not be described alongside the various virtual interfaces implementations, such as [[#User-mode networking]], [[#Tap networking with QEMU]], [[#Networking with VDE2]].}}<br />
<br />
The performance of virtual networking should be better with tap devices and bridges than with user-mode networking or vde because tap devices and bridges are implemented in-kernel.<br />
<br />
In addition, networking performance can be improved by assigning virtual machines a [http://wiki.libvirt.org/page/Virtio virtio] network device rather than the default emulation of an e1000 NIC. See [[#Installing virtio drivers]] for more information.<br />
<br />
=== Link-level address caveat ===<br />
<br />
By giving the {{ic|-net nic}} argument to QEMU, it will, by default, assign a virtual machine a network interface with the link-level address {{ic|52:54:00:12:34:56}}. However, when using bridged networking with multiple virtual machines, it is essential that each virtual machine has a unique link-level (MAC) address on the virtual machine side of the tap device. Otherwise, the bridge will not work correctly, because it will receive packets from multiple sources that have the same link-level address. This problem occurs even if the tap devices themselves have unique link-level addresses because the source link-level address is not rewritten as packets pass through the tap device.<br />
<br />
Make sure that each virtual machine has a unique link-level address, but it should always start with {{ic|52:54:}}. Use the following option, replace ''X'' with arbitrary hexadecimal digit:<br />
<br />
$ qemu-system-x86_64 -net nic,macaddr=52:54:''XX:XX:XX:XX'' -net vde ''disk_image''<br />
<br />
Generating unique link-level addresses can be done in several ways:<br />
<br />
<ol><br />
<li>Manually specify unique link-level address for each NIC. The benefit is that the DHCP server will assign the same IP address each time the virtual machine is run, but it is unusable for large number of virtual machines.<br />
</li><br />
<li>Generate random link-level address each time the virtual machine is run. Practically zero probability of collisions, but the downside is that the DHCP server will assign a different IP address each time. You can use the following command in a script to generate random link-level address in a {{ic|macaddr}} variable:<br />
<br />
{{bc|1=<br />
printf -v macaddr "52:54:%02x:%02x:%02x:%02x" $(( $RANDOM & 0xff)) $(( $RANDOM & 0xff )) $(( $RANDOM & 0xff)) $(( $RANDOM & 0xff ))<br />
qemu-system-x86_64 -net nic,macaddr="$macaddr" -net vde ''disk_image''<br />
}}<br />
<br />
</li><br />
<li>Use the following script {{ic|qemu-mac-hasher.py}} to generate the link-level address from the virtual machine name using a hashing function. Given that the names of virtual machines are unique, this method combines the benefits of the aforementioned methods: it generates the same link-level address each time the script is run, yet it preserves the practically zero probability of collisions.<br />
<br />
{{hc|qemu-mac-hasher.py|<nowiki><br />
#!/usr/bin/env python<br />
<br />
import sys<br />
import zlib<br />
<br />
if len(sys.argv) != 2:<br />
print("usage: %s <VM Name>" % sys.argv[0])<br />
sys.exit(1)<br />
<br />
crc = zlib.crc32(sys.argv[1].encode("utf-8")) & 0xffffffff<br />
crc = str(hex(crc))[2:]<br />
print("52:54:%s%s:%s%s:%s%s:%s%s" % tuple(crc))<br />
</nowiki>}}<br />
<br />
In a script, you can use for example:<br />
<br />
vm_name="''VM Name''"<br />
qemu-system-x86_64 -name "$vm_name" -net nic,macaddr=$(qemu-mac-hasher.py "$vm_name") -net vde ''disk_image''<br />
</li><br />
</ol><br />
<br />
=== User-mode networking ===<br />
<br />
By default, without any {{ic|-netdev}} arguments, QEMU will use user-mode networking with a built-in DHCP server. Your virtual machines will be assigned an IP address when they run their DHCP client, and they will be able to access the physical host's network through IP masquerading done by QEMU.<br />
<br />
{{warning|This only works with the TCP and UDP protocols, so ICMP, including {{ic|ping}}, will not work. Do not use {{ic|ping}} to test network connectivity.}}<br />
<br />
This default configuration allows your virtual machines to easily access the Internet, provided that the host is connected to it, but the virtual machines will not be directly visible on the external network, nor will virtual machines be able to talk to each other if you start up more than one concurrently.<br />
<br />
QEMU's user-mode networking can offer more capabilities such as built-in TFTP or SMB servers, redirecting host ports to the guest (for example to allow SSH connections to the guest) or attaching guests to VLANs so that they can talk to each other. See the QEMU documentation on the {{ic|-net user}} flag for more details.<br />
<br />
However, user-mode networking has limitations in both utility and performance. More advanced network configurations require the use of tap devices or other methods.<br />
<br />
{{Note|If the host system uses [[systemd-networkd]], make sure to symlink the {{ic|/etc/resolv.conf}} file as described in [[systemd-networkd#Required services and setup]], otherwise the DNS lookup in the guest system will not work.}}<br />
<br />
=== Tap networking with QEMU ===<br />
<br />
[[wikipedia:TUN/TAP|Tap devices]] are a Linux kernel feature that allows you to create virtual network interfaces that appear as real network interfaces. Packets sent to a tap interface are delivered to a userspace program, such as QEMU, that has bound itself to the interface.<br />
<br />
QEMU can use tap networking for a virtual machine so that packets sent to the tap interface will be sent to the virtual machine and appear as coming from a network interface (usually an Ethernet interface) in the virtual machine. Conversely, everything that the virtual machine sends through its network interface will appear on the tap interface.<br />
<br />
Tap devices are supported by the Linux bridge drivers, so it is possible to bridge together tap devices with each other and possibly with other host interfaces such as {{ic|eth0}}. This is desirable if you want your virtual machines to be able to talk to each other, or if you want other machines on your LAN to be able to talk to the virtual machines.<br />
<br />
{{Warning|If you bridge together tap device and some host interface, such as {{ic|eth0}}, your virtual machines will appear directly on the external network, which will expose them to possible attack. Depending on what resources your virtual machines have access to, you may need to take all the [[Firewalls|precautions]] you normally would take in securing a computer to secure your virtual machines. If the risk is too great, virtual machines have little resources or you set up multiple virtual machines, a better solution might be to use [[#Host-only networking|host-only networking]] and set up NAT. In this case you only need one firewall on the host instead of multiple firewalls for each guest.}}<br />
<br />
As indicated in the user-mode networking section, tap devices offer higher networking performance than user-mode. If the guest OS supports virtio network driver, then the networking performance will be increased considerably as well. Supposing the use of the tap0 device, that the virtio driver is used on the guest, and that no scripts are used to help start/stop networking, next is part of the qemu command one should see:<br />
<br />
-device virtio-net,netdev=network0 -netdev tap,id=network0,ifname=tap0,script=no,downscript=no<br />
<br />
But if already using a tap device with virtio networking driver, one can even boost the networking performance by enabling vhost, like:<br />
<br />
-device virtio-net,netdev=network0 -netdev tap,id=network0,ifname=tap0,script=no,downscript=no,vhost=on<br />
<br />
See http://www.linux-kvm.com/content/how-maximize-virtio-net-performance-vhost-net for more information.<br />
<br />
==== Host-only networking ====<br />
<br />
If the bridge is given an IP address and traffic destined for it is allowed, but no real interface (e.g. {{ic|eth0}}) is connected to the bridge, then the virtual machines will be able to talk to each other and the host system. However, they will not be able to talk to anything on the external network, provided that you do not set up IP masquerading on the physical host. This configuration is called ''host-only networking'' by other virtualization software such as [[VirtualBox]].<br />
<br />
{{Tip|<br />
* If you want to set up IP masquerading, e.g. NAT for virtual machines, see the [[Internet sharing#Enable NAT]] page.<br />
* See [[Network bridge]] for information on creating bridge.<br />
* You may want to have a DHCP server running on the bridge interface to service the virtual network. For example, to use the {{ic|172.20.0.1/16}} subnet with [[dnsmasq]] as the DHCP server:<br />
# ip addr add 172.20.0.1/16 dev br0<br />
# ip link set br0 up<br />
# dnsmasq --interface&#61;br0 --bind-interfaces --dhcp-range&#61;172.20.0.2,172.20.255.254<br />
}}<br />
<br />
==== Internal networking ====<br />
<br />
If you do not give the bridge an IP address and add an [[iptables]] rule to drop all traffic to the bridge in the INPUT chain, then the virtual machines will be able to talk to each other, but not to the physical host or to the outside network. This configuration is called ''internal networking'' by other virtualization software such as [[VirtualBox]]. You will need to either assign static IP addresses to the virtual machines or run a DHCP server on one of them.<br />
<br />
By default iptables would drop packets in the bridge network. You may need to use such iptables rule to allow packets in a bridged network:<br />
<br />
# iptables -I FORWARD -m physdev --physdev-is-bridged -j ACCEPT<br />
<br />
==== Bridged networking using qemu-bridge-helper ====<br />
<br />
{{Note|This method is available since QEMU 1.1, see http://wiki.qemu.org/Features/HelperNetworking.}}<br />
<br />
This method does not require a start-up script and readily accommodates multiple taps and multiple bridges. It uses {{ic|/usr/lib/qemu/qemu-bridge-helper}} binary, which allows creating tap devices on an existing bridge.<br />
<br />
{{Tip|See [[Network bridge]] for information on creating bridge.}}<br />
<br />
First, create a configuration file containing the names of all bridges to be used by QEMU:<br />
<br />
{{hc|/etc/qemu/bridge.conf|<br />
allow ''bridge0''<br />
allow ''bridge1''<br />
...}}<br />
<br />
Now start the VM. The most basic usage would be:<br />
<br />
$ qemu-system-x86_64 -net nic -net bridge,br=''bridge0'' ''[...]''<br />
<br />
With multiple taps, the most basic usage requires specifying the VLAN for all additional NICs:<br />
<br />
$ qemu-system-x86_64 -net nic -net bridge,br=''bridge0'' -net nic,vlan=1 -net bridge,vlan=1,br=''bridge1'' ''[...]''<br />
<br />
==== Creating bridge manually ====<br />
<br />
{{Style|This section needs serious cleanup and may contain out-of-date information.}}<br />
<br />
{{Tip|Since QEMU 1.1, the [http://wiki.qemu.org/Features/HelperNetworking network bridge helper] can set tun/tap up for you without the need for additional scripting. See [[#Bridged networking using qemu-bridge-helper]].}}<br />
<br />
The following describes how to bridge a virtual machine to a host interface such as {{ic|eth0}}, which is probably the most common configuration. This configuration makes it appear that the virtual machine is located directly on the external network, on the same Ethernet segment as the physical host machine.<br />
<br />
We will replace the normal Ethernet adapter with a bridge adapter and bind the normal Ethernet adapter to it.<br />
<br />
* Install {{Pkg|bridge-utils}}, which provides {{ic|brctl}} to manipulate bridges.<br />
<br />
* Enable IPv4 forwarding:<br />
# sysctl net.ipv4.ip_forward=1<br />
<br />
To make the change permanent, change {{ic|1=net.ipv4.ip_forward = 0}} to {{ic|1=net.ipv4.ip_forward = 1}} in {{ic|/etc/sysctl.d/99-sysctl.conf}}.<br />
<br />
* Load the {{ic|tun}} module and configure it to be loaded on boot. See [[Kernel modules]] for details.<br />
<br />
* Now create the bridge. See [[Bridge with netctl]] for details. Remember to name your bridge as {{ic|br0}}, or change the scripts below to your bridge's name.<br />
<br />
* Create the script that QEMU uses to bring up the tap adapter with {{ic|root:kvm}} 750 permissions:<br />
{{hc|/etc/qemu-ifup|<nowiki><br />
#!/bin/sh<br />
<br />
echo "Executing /etc/qemu-ifup"<br />
echo "Bringing up $1 for bridged mode..."<br />
sudo /usr/bin/ip link set $1 up promisc on<br />
echo "Adding $1 to br0..."<br />
sudo /usr/bin/brctl addif br0 $1<br />
sleep 2<br />
</nowiki>}}<br />
<br />
* Create the script that QEMU uses to bring down the tap adapter in {{ic|/etc/qemu-ifdown}} with {{ic|root:kvm}} 750 permissions:<br />
{{hc|/etc/qemu-ifdown|<nowiki><br />
#!/bin/sh<br />
<br />
echo "Executing /etc/qemu-ifdown"<br />
sudo /usr/bin/ip link set $1 down<br />
sudo /usr/bin/brctl delif br0 $1<br />
sudo /usr/bin/ip link delete dev $1<br />
</nowiki>}}<br />
<br />
* Use {{ic|visudo}} to add the following to your {{ic|sudoers}} file:<br />
{{bc|<nowiki><br />
Cmnd_Alias QEMU=/usr/bin/ip,/usr/bin/modprobe,/usr/bin/brctl<br />
%kvm ALL=NOPASSWD: QEMU<br />
</nowiki>}}<br />
<br />
* You launch QEMU using the following {{ic|run-qemu}} script:<br />
{{hc|run-qemu|<nowiki><br />
#!/bin/bash<br />
USERID=$(whoami)<br />
<br />
# Get name of newly created TAP device; see https://bbs.archlinux.org/viewtopic.php?pid=1285079#p1285079<br />
precreationg=$(/usr/bin/ip tuntap list | /usr/bin/cut -d: -f1 | /usr/bin/sort)<br />
sudo /usr/bin/ip tuntap add user $USERID mode tap<br />
postcreation=$(/usr/bin/ip tuntap list | /usr/bin/cut -d: -f1 | /usr/bin/sort)<br />
IFACE=$(comm -13 <(echo "$precreationg") <(echo "$postcreation"))<br />
<br />
# This line creates a random MAC address. The downside is the DHCP server will assign a different IP address each time<br />
printf -v macaddr "52:54:%02x:%02x:%02x:%02x" $(( $RANDOM & 0xff)) $(( $RANDOM & 0xff )) $(( $RANDOM & 0xff)) $(( $RANDOM & 0xff ))<br />
# Instead, uncomment and edit this line to set a static MAC address. The benefit is that the DHCP server will assign the same IP address.<br />
# macaddr='52:54:be:36:42:a9'<br />
<br />
qemu-system-x86_64 -net nic,macaddr=$macaddr -net tap,ifname="$IFACE" $*<br />
<br />
sudo ip link set dev $IFACE down &> /dev/null<br />
sudo ip tuntap del $IFACE mode tap &> /dev/null<br />
</nowiki>}}<br />
<br />
Then to launch a VM, do something like this<br />
$ run-qemu -hda ''myvm.img'' -m 512 -vga std<br />
<br />
* It is recommended for performance and security reasons to disable the [http://ebtables.netfilter.org/documentation/bridge-nf.html firewall on the bridge]:<br />
{{hc|/etc/sysctl.d/10-disable-firewall-on-bridge.conf|<nowiki><br />
net.bridge.bridge-nf-call-ip6tables = 0<br />
net.bridge.bridge-nf-call-iptables = 0<br />
net.bridge.bridge-nf-call-arptables = 0<br />
</nowiki>}}<br />
Run {{ic|sysctl -p /etc/sysctl.d/10-disable-firewall-on-bridge.conf}} to apply the changes immediately.<br />
<br />
See the [http://wiki.libvirt.org/page/Networking#Creating_network_initscripts libvirt wiki] and [https://bugzilla.redhat.com/show_bug.cgi?id=512206 Fedora bug 512206]. If you get errors by sysctl during boot about non-existing files, make the {{ic|bridge}} module load at boot. See [[Kernel modules#Automatic module handling]].<br />
<br />
Alternatively, you can configure [[iptables]] to allow all traffic to be forwarded across the bridge by adding a rule like this:<br />
-I FORWARD -m physdev --physdev-is-bridged -j ACCEPT<br />
<br />
==== Network sharing between physical device and a Tap device through iptables ====<br />
<br />
{{Merge|Internet_sharing|Duplication, not specific to QEMU.}}<br />
<br />
Bridged networking works fine between a wired interface (Eg. eth0), and it is easy to setup. However if the host gets connected to the network through a wireless device, then bridging is not possible.<br />
<br />
See [[Network bridge#Wireless interface on a bridge]] as a reference.<br />
<br />
One way to overcome that is to setup a tap device with a static IP, making linux automatically handle the routing for it, and then forward traffic between the tap interface and the device connected to the network through iptables rules.<br />
<br />
See [[Internet sharing]] as a reference.<br />
<br />
There you can find what is needed to share the network between devices, included tap and tun ones. The following just hints further on some of the host configurations required. As indicated in the reference above, the client needs to be configured for a static IP, using the IP assigned to the tap interface as the gateway. The caveat is that the DNS servers on the client might need to be manually edited if they change when changing from one host device connected to the network to another.<br />
<br />
To allow IP forwarding on every boot, one need to add the following lines to sysctl configuration file inside {{ic|/etc/sysctl.d}}:<br />
<br />
net.ipv4.ip_forward = 1<br />
net.ipv6.conf.default.forwarding = 1<br />
net.ipv6.conf.all.forwarding = 1<br />
<br />
The iptables rules can look like:<br />
<br />
# Forwarding from/to outside<br />
iptables -A FORWARD -i ${INT} -o ${EXT_0} -j ACCEPT<br />
iptables -A FORWARD -i ${INT} -o ${EXT_1} -j ACCEPT<br />
iptables -A FORWARD -i ${INT} -o ${EXT_2} -j ACCEPT<br />
iptables -A FORWARD -i ${EXT_0} -o ${INT} -j ACCEPT<br />
iptables -A FORWARD -i ${EXT_1} -o ${INT} -j ACCEPT<br />
iptables -A FORWARD -i ${EXT_2} -o ${INT} -j ACCEPT<br />
# NAT/Masquerade (network address translation)<br />
iptables -t nat -A POSTROUTING -o ${EXT_0} -j MASQUERADE<br />
iptables -t nat -A POSTROUTING -o ${EXT_1} -j MASQUERADE<br />
iptables -t nat -A POSTROUTING -o ${EXT_2} -j MASQUERADE<br />
<br />
The prior supposes there are 3 devices connected to the network sharing traffic with one internal device, where for example:<br />
<br />
INT=tap0<br />
EXT_0=eth0<br />
EXT_1=wlan0<br />
EXT_2=tun0<br />
<br />
The prior shows a forwarding that would allow sharing wired and wireless connections with the tap device.<br />
<br />
The forwarding rules shown are stateless, and for pure forwarding. One could think of restricting specific traffic, putting a firewall in place to protect the guest and others. However those would decrease the networking performance, while a simple bridge does not include any of that.<br />
<br />
Bonus: Whether the connection is wired or wireless, if one gets connected through VPN to a remote site with a tun device, supposing the tun device opened for that connection is tun0, and the prior iptables rules are applied, then the remote connection gets also shared with the guest. This avoids the need for the guest to also open a VPN connection. Again, as the guest networking needs to be static, then if connecting the host remotely this way, one most probably will need to edit the DNS servers on the guest.<br />
<br />
=== Networking with VDE2 ===<br />
<br />
{{Style|This section needs serious cleanup and may contain out-of-date information.}}<br />
<br />
==== What is VDE? ====<br />
<br />
VDE stands for Virtual Distributed Ethernet. It started as an enhancement of [[User-mode Linux|uml]]_switch. It is a toolbox to manage virtual networks.<br />
<br />
The idea is to create virtual switches, which are basically sockets, and to "plug" both physical and virtual machines in them. The configuration we show here is quite simple; However, VDE is much more powerful than this, it can plug virtual switches together, run them on different hosts and monitor the traffic in the switches. You are invited to read [http://wiki.virtualsquare.org/wiki/index.php/Main_Page the documentation of the project].<br />
<br />
The advantage of this method is you do not have to add sudo privileges to your users. Regular users should not be allowed to run modprobe.<br />
<br />
==== Basics ====<br />
<br />
VDE support can be [[pacman|installed]] via the {{Pkg|vde2}} package.<br />
<br />
In our config, we use tun/tap to create a virtual interface on my host. Load the {{ic|tun}} module (see [[Kernel modules]] for details):<br />
<br />
# modprobe tun<br />
<br />
Now create the virtual switch:<br />
<br />
# vde_switch -tap tap0 -daemon -mod 660 -group users<br />
<br />
This line creates the switch, creates {{ic|tap0}}, "plugs" it, and allows the users of the group {{ic|users}} to use it.<br />
<br />
The interface is plugged in but not configured yet. To configure it, run this command:<br />
<br />
# ip addr add 192.168.100.254/24 dev tap0<br />
<br />
Now, you just have to run KVM with these {{ic|-net}} options as a normal user:<br />
<br />
$ qemu-system-x86_64 -net nic -net vde -hda ''[...]''<br />
<br />
Configure networking for your guest as you would do in a physical network.<br />
<br />
{{Tip|You might want to set up NAT on tap device to access the internet from the virtual machine. See [[Internet sharing#Enable NAT]] for more information.}}<br />
<br />
==== Startup scripts ====<br />
<br />
Example of main script starting VDE:<br />
<br />
{{hc|/etc/systemd/scripts/qemu-network-env|<nowiki><br />
#!/bin/sh<br />
# QEMU/VDE network environment preparation script<br />
<br />
# The IP configuration for the tap device that will be used for<br />
# the virtual machine network:<br />
<br />
TAP_DEV=tap0<br />
TAP_IP=192.168.100.254<br />
TAP_MASK=24<br />
TAP_NETWORK=192.168.100.0<br />
<br />
# Host interface<br />
NIC=eth0<br />
<br />
case "$1" in<br />
start)<br />
echo -n "Starting VDE network for QEMU: "<br />
<br />
# If you want tun kernel module to be loaded by script uncomment here<br />
#modprobe tun 2>/dev/null<br />
## Wait for the module to be loaded<br />
#while ! lsmod | grep -q "^tun"; do echo "Waiting for tun device"; sleep 1; done<br />
<br />
# Start tap switch<br />
vde_switch -tap "$TAP_DEV" -daemon -mod 660 -group users<br />
<br />
# Bring tap interface up<br />
ip address add "$TAP_IP"/"$TAP_MASK" dev "$TAP_DEV"<br />
ip link set "$TAP_DEV" up<br />
<br />
# Start IP Forwarding<br />
echo "1" > /proc/sys/net/ipv4/ip_forward<br />
iptables -t nat -A POSTROUTING -s "$TAP_NETWORK"/"$TAP_MASK" -o "$NIC" -j MASQUERADE<br />
;;<br />
stop)<br />
echo -n "Stopping VDE network for QEMU: "<br />
# Delete the NAT rules<br />
iptables -t nat -D POSTROUTING "$TAP_NETWORK"/"$TAP_MASK" -o "$NIC" -j MASQUERADE<br />
<br />
# Bring tap interface down<br />
ip link set "$TAP_DEV" down<br />
<br />
# Kill VDE switch<br />
pgrep -f vde_switch | xargs kill -TERM<br />
;;<br />
restart|reload)<br />
$0 stop<br />
sleep 1<br />
$0 start<br />
;;<br />
*)<br />
echo "Usage: $0 {start|stop|restart|reload}"<br />
exit 1<br />
esac<br />
exit 0<br />
</nowiki>}}<br />
<br />
Example of systemd service using the above script:<br />
<br />
{{hc|/etc/systemd/system/qemu-network-env.service|<nowiki><br />
[Unit]<br />
Description=Manage VDE Switch<br />
<br />
[Service]<br />
Type=oneshot<br />
ExecStart=/etc/systemd/scripts/qemu-network-env start<br />
ExecStop=/etc/systemd/scripts/qemu-network-env stop<br />
RemainAfterExit=yes<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
Change permissions for {{ic|qemu-network-env}} to be executable<br />
<br />
# chmod u+x /etc/systemd/scripts/qemu-network-env<br />
<br />
You can [[start]] {{ic|qemu-network-env.service}} as usual.<br />
<br />
====Alternative method====<br />
<br />
If the above method does not work or you do not want to mess with kernel configs, TUN, dnsmasq, and iptables you can do the following for the same result.<br />
<br />
# vde_switch -daemon -mod 660 -group users<br />
# slirpvde --dhcp --daemon<br />
<br />
Then, to start the VM with a connection to the network of the host:<br />
<br />
$ qemu-system-x86_64 -net nic,macaddr=52:54:00:00:EE:03 -net vde ''disk_image''<br />
<br />
=== VDE2 Bridge ===<br />
<br />
Based on [http://selamatpagicikgu.wordpress.com/2011/06/08/quickhowto-qemu-networking-using-vde-tuntap-and-bridge/ quickhowto: qemu networking using vde, tun/tap, and bridge] graphic. Any virtual machine connected to vde is externally exposed. For example, each virtual machine can receive DHCP configuration directly from your ADSL router.<br />
<br />
==== Basics ====<br />
<br />
Remember that you need {{ic|tun}} module and {{Pkg|bridge-utils}} package.<br />
<br />
Create the vde2/tap device:<br />
<br />
# vde_switch -tap tap0 -daemon -mod 660 -group users<br />
# ip link set tap0 up<br />
<br />
Create bridge:<br />
<br />
# brctl addbr br0<br />
<br />
Add devices:<br />
<br />
# brctl addif br0 eth0<br />
# brctl addif br0 tap0<br />
<br />
And configure bridge interface:<br />
<br />
# dhcpcd br0<br />
<br />
==== Startup scripts ====<br />
<br />
All devices must be set up. And only the bridge needs an IP address. For physical devices on the bridge (e.g. {{ic|eth0}}), this can be done with [[netctl]] using a custom Ethernet profile with:<br />
<br />
{{hc|/etc/netctl/ethernet-noip|<nowiki><br />
Description='A more versatile static Ethernet connection'<br />
Interface=eth0<br />
Connection=ethernet<br />
IP=no<br />
</nowiki>}}<br />
<br />
The following custom systemd service can be used to create and activate a VDE2 tap interface for use in the {{ic|users}} user group.<br />
<br />
{{hc|/etc/systemd/system/vde2@.service|<nowiki><br />
[Unit]<br />
Description=Network Connectivity for %i<br />
Wants=network.target<br />
Before=network.target<br />
<br />
[Service]<br />
Type=oneshot<br />
RemainAfterExit=yes<br />
ExecStart=/usr/bin/vde_switch -tap %i -daemon -mod 660 -group users<br />
ExecStart=/usr/bin/ip link set dev %i up<br />
ExecStop=/usr/bin/ip addr flush dev %i<br />
ExecStop=/usr/bin/ip link set dev %i down<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
And finally, you can create the [[Bridge with netctl|bridge interface with netctl]].<br />
<br />
== Graphics ==<br />
<br />
QEMU can use the following different graphic outputs: {{ic|std}}, {{ic|qxl}}, {{ic|vmware}}, {{ic|virtio}}, {{ic|cirrus}} and {{ic|none}}.<br />
<br />
=== std ===<br />
<br />
With {{ic|-vga std}} you can get a resolution of up to 2560 x 1600 pixels without requiring guest drivers. This is the default since QEMU 2.2.<br />
<br />
=== qxl ===<br />
<br />
QXL is a paravirtual graphics driver with 2D support. To use it, pass the {{ic|-vga qxl}} option and install drivers in the guest. You may want to use SPICE for improved graphical performance when using QXL.<br />
<br />
On Linux guests, the {{ic|qxl}} and {{ic|bochs_drm}} kernel modules must be loaded in order to gain a decent performance.<br />
<br />
==== SPICE ====<br />
The [http://spice-space.org/ SPICE project] aims to provide a complete open source solution for remote access to virtual machines in a seamless way.<br />
<br />
SPICE can only be used when using QXL as the graphical output.<br />
<br />
The following is example of booting with SPICE as the remote desktop protocol, including the support for copy and paste from host:<br />
<br />
$ qemu-system-x86_64 -vga qxl -spice port=5930,disable-ticketing -device virtio-serial-pci -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 -chardev spicevmc,id=spicechannel0,name=vdagent<br />
<br />
From the [https://www.linux-kvm.org/page/SPICE SPICE page on the KVM wiki]: "''The {{ic|-device virtio-serial-pci}} option adds the virtio-serial device, {{ic|1=-device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0}} opens a port for spice vdagent in that device and {{ic|1=-chardev spicevmc,id=spicechannel0,name=vdagent}} adds a spicevmc chardev for that port. It is important that the {{ic|1=chardev=}} option of the {{ic|virtserialport}} device matches the {{ic|1=id=}} option given to the {{ic|chardev}} option ({{ic|spicechannel0}} in this example). It is also important that the port name is {{ic|com.redhat.spice.0}}, because that is the namespace where vdagent is looking for in the guest. And finally, specify {{ic|1=name=vdagent}} so that spice knows what this channel is for.''"<br />
<br />
{{Tip|Since QEMU in SPICE mode acts similarly to a remote desktop server, it may be more convenient to run QEMU in daemon mode with the {{ic|-daemonize}} parameter.}}<br />
<br />
Connect to the guest by using a SPICE client. {{pkg|virt-viewer}} is the recommended SPICE client by the protocol developers:<br />
<br />
$ remote-viewer spice://127.0.0.1:5930<br />
<br />
The reference and test implementation {{Pkg|spice-gtk}} can also be used:<br />
<br />
$ spicy -h 127.0.0.1 -p 5930<br />
<br />
Other [http://www.spice-space.org/download.html clients], including for other platforms, are also available.<br />
<br />
Using [[wikipedia:Unix_socket|Unix sockets]] instead of TCP ports does not involve using network stack on the host system, so it is [https://unix.stackexchange.com/questions/91774/performance-of-unix-sockets-vs-tcp-ports reportedly] better for performance. Example:<br />
$ qemu-system-x86_64 -vga qxl -device virtio-serial-pci -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 -chardev spicevmc,id=spicechannel0,name=vdagent -spice unix,addr=/tmp/vm_spice.socket,disable-ticketing<br />
<br />
Then connect via:<br />
<br />
$ remote-viewer spice+unix:///tmp/vm_spice.socket<br />
<br />
or via:<br />
<br />
$ spicy --uri="spice+unix:///tmp/vm_spice.socket"<br />
<br />
For improved support for multiple monitors, clipboard sharing, etc. the following packages should be installed on the guest:<br />
* {{Pkg|spice-vdagent}}: Spice agent xorg client that enables copy and paste between client and X-session and more. [[Enable]] {{ic|spice-vdagentd.service}} after installation.<br />
* {{Pkg|xf86-video-qxl}}: Xorg X11 qxl video driver<br />
* For other operating systems, see the Guest section on [http://www.spice-space.org/download.html SPICE-Space download] page.<br />
<br />
===== Password authentication with SPICE =====<br />
If you want to enable password authentication with SPICE you need to remove {{ic|disable-ticketing}} from the {{ic|-spice}} argument and instead add {{ic|1=password=''yourpassword''}}. For example:<br />
<br />
$ qemu-system-x86_64 -vga qxl -spice port=5900,password=''yourpassword'' -device virtio-serial-pci -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 -chardev spicevmc,id=spicechannel0,name=vdagent<br />
<br />
Your SPICE client should now ask for the password to be able to connect to the SPICE server.<br />
<br />
===== TLS encryption =====<br />
<br />
You can also configure TLS encryption for communicating with the SPICE server. First, you need to have a directory which contains the following files (the names must be exactly as indicated):<br />
* {{ic|ca-cert.pem}}: the CA master certificate.<br />
* {{ic|server-cert.pem}}: the server certificate signed with {{ic|ca-cert.pem}}.<br />
* {{ic|server-key.pem}}: the server private key.<br />
<br />
An example of generation of self-signed certificates with your own generated CA for your server is shown in the [https://www.spice-space.org/spice-user-manual.html#_generating_self_signed_certificates Spice User Manual].<br />
<br />
Afterwards, you can run QEMU with SPICE as explained above but using the following {{ic|-spice}} argument: {{ic|1=-spice tls-port=5901,password=''yourpassword'',x509-dir=''/path/to/pki_certs''}}, where {{ic|''/path/to/pki_certs''}} is the directory path that contains the three needed files shown earlier.<br />
<br />
It is now possible to connect to the server using {{pkg|virt-viewer}}:<br />
<br />
$ remote-viewer spice://''hostname''?tls-port=5901 --spice-ca-file=''/path/to/ca-cert.pem'' --spice-host-subject="C=''XX'',L=''city'',O=''organization'',CN=''hostname''" --spice-secure-channels=all<br />
<br />
Keep in mind that the {{ic|--spice-host-subject}} parameter needs to be set according to your {{ic|server-cert.pem}} subject. You also need to copy {{ic|ca-cert.pem}} to every client to verify the server certificate.<br />
<br />
{{Tip|You can get the subject line of the server certificate in the correct format for {{ic|--spice-host-subject}} (with entries separated by commas) using the following command: {{bc|<nowiki>$ openssl x509 -noout -subject -in server-cert.pem | cut -d' ' -f2- | sed 's/\///' | sed 's/\//,/g'</nowiki>}}<br />
}}<br />
<br />
The equivalent {{Pkg|spice-gtk}} command is:<br />
<br />
$ spicy -h ''hostname'' -s 5901 --spice-ca-file=ca-cert.pem --spice-host-subject="C=''XX'',L=''city'',O=''organization'',CN=''hostname''" --spice-secure-channels=all<br />
<br />
=== vmware ===<br />
<br />
Although it is a bit buggy, it performs better than std and cirrus. Install the VMware drivers {{Pkg|xf86-video-vmware}} and {{Pkg|xf86-input-vmmouse}} for Arch Linux guests.<br />
<br />
=== virtio ===<br />
<br />
{{ic|virtio-vga}} / {{ic|virtio-gpu}} is a paravirtual 3D graphics driver based on [https://virgil3d.github.io/ virgl]. Currently a work in progress, supporting only very recent (>= 4.4) Linux guests with {{Pkg|mesa}} (>=11.2) compiled with the option {{ic|1=--with-gallium-drivers=virgl}}.<br />
<br />
To enable 3D acceleration on the guest system select this vga with {{ic|-vga virtio}} and enable the opengl context in the display device with {{ic|1=-display sdl,gl=on}} or {{ic|1=-display gtk,gl=on}} for the sdl and gtk display output respectively. Successful configuration can be confirmed looking at the kernel log in the guest:<br />
<br />
{{hc|$ dmesg {{!}} grep drm |<br />
[drm] pci: virtio-vga detected<br />
[drm] virgl 3d acceleration enabled<br />
}}<br />
<br />
As of September 2016, support for the spice protocol is under development and can be tested installing the development release of {{Pkg|spice}} (>= 0.13.2) and recompiling qemu.<br />
<br />
For more information visit [https://www.kraxel.org/blog/tag/virgl/ kraxel's blog].<br />
<br />
=== cirrus ===<br />
<br />
The cirrus graphical adapter was the default [http://wiki.qemu.org/ChangeLog/2.2#VGA before 2.2]. It [https://www.kraxel.org/blog/2014/10/qemu-using-cirrus-considered-harmful/ should not] be used on modern systems.<br />
<br />
=== none ===<br />
<br />
This is like a PC that has no VGA card at all. You would not even be able to access it with the {{ic|-vnc}} option. Also, this is different from the {{ic|-nographic}} option which lets QEMU emulate a VGA card, but disables the SDL display.<br />
<br />
=== vnc ===<br />
<br />
Given that you used the {{ic|-nographic}} option, you can add the {{ic|-vnc display}} option to have QEMU listen on {{ic|display}} and redirect the VGA display to the VNC session. There is an example of this in the [[#Starting QEMU virtual machines on boot]] section's example configs.<br />
<br />
$ qemu-system-x86_64 -vga std -nographic -vnc :0<br />
$ gvncviewer :0<br />
<br />
When using VNC, you might experience keyboard problems described (in gory details) [https://www.berrange.com/posts/2010/07/04/more-than-you-or-i-ever-wanted-to-know-about-virtual-keyboard-handling/ here]. The solution is ''not'' to use the {{ic|-k}} option on QEMU, and to use {{ic|gvncviewer}} from {{Pkg|gtk-vnc}}. See also [http://www.mail-archive.com/libvir-list@redhat.com/msg13340.html this] message posted on libvirt's mailing list.<br />
<br />
== Audio ==<br />
<br />
=== Host ===<br />
<br />
The audio driver used by QEMU is set with the {{ic|QEMU_AUDIO_DRV}} environment variable:<br />
<br />
$ export QEMU_AUDIO_DRV=pa<br />
<br />
Run the following command to get QEMU's configuration options related to PulseAudio:<br />
<br />
$ qemu-system-x86_64 -audio-help | awk '/Name: pa/' RS=<br />
<br />
The listed options can be exported as environment variables, for example:<br />
<br />
{{bc|1=<br />
$ export QEMU_PA_SINK=alsa_output.pci-0000_04_01.0.analog-stereo.monitor<br />
$ export QEMU_PA_SOURCE=input<br />
}}<br />
<br />
=== Guest ===<br />
To get list of the supported emulation audio drivers:<br />
$ qemu-system-x86_64 -soundhw help<br />
<br />
To use e.g. {{ic|hda}} driver for the guest use the {{ic|-soundhw hda}} command with QEMU.<br />
<br />
{{Note|Video graphic card emulated drivers for the guest machine may also cause a problem with the sound quality. Test one by one to make it work. You can list possible options with {{ic|<nowiki>qemu-system-x86_64 -h | grep vga</nowiki>}}.}}<br />
<br />
== Installing virtio drivers ==<br />
<br />
QEMU offers guests the ability to use paravirtualized block and network devices using the [http://wiki.libvirt.org/page/Virtio virtio] drivers, which provide better performance and lower overhead.<br />
<br />
* A virtio block device requires the option {{Ic|-drive}} for passing a disk image, with parameter {{Ic|1=if=virtio}}:<br />
$ qemu-system-x86_64 -boot order=c -drive file=''disk_image'',if=virtio<br />
<br />
* Almost the same goes for the network:<br />
$ qemu-system-x86_64 -net nic,model=virtio<br />
<br />
{{Note|This will only work if the guest machine has drivers for virtio devices. Linux does, and the required drivers are included in Arch Linux, but there is no guarantee that virtio devices will work with other operating systems.}}<br />
<br />
=== Preparing an (Arch) Linux guest ===<br />
<br />
To use virtio devices after an Arch Linux guest has been installed, the following modules must be loaded in the guest: {{Ic|virtio}}, {{Ic|virtio_pci}}, {{Ic|virtio_blk}}, {{Ic|virtio_net}}, and {{Ic|virtio_ring}}. For 32-bit guests, the specific "virtio" module is not necessary.<br />
<br />
If you want to boot from a virtio disk, the initial ramdisk must contain the necessary modules. By default, this is handled by [[mkinitcpio]]'s {{ic|autodetect}} hook. Otherwise use the {{ic|MODULES}} array in {{ic|/etc/mkinitcpio.conf}} to include the necessary modules and rebuild the initial ramdisk.<br />
<br />
{{hc|/etc/mkinitcpio.conf|2=<br />
MODULES="virtio virtio_blk virtio_pci virtio_net"}}<br />
<br />
Virtio disks are recognized with the prefix {{ic|'''v'''}} (e.g. {{ic|'''v'''da}}, {{ic|'''v'''db}}, etc.); therefore, changes must be made in at least {{ic|/etc/fstab}} and {{ic|/boot/grub/grub.cfg}} when booting from a virtio disk.<br />
<br />
{{Tip|When referencing disks by [[UUID]] in both {{ic|/etc/fstab}} and bootloader, nothing has to be done.}}<br />
<br />
Further information on paravirtualization with KVM can be found [http://www.linux-kvm.org/page/Boot_from_virtio_block_device here].<br />
<br />
You might also want to install {{Pkg|qemu-guest-agent}} to implement support for QMP commands that will enhance the hypervisor management capabilities. After installing the package you can enable and start the {{ic|qemu-ga.service}}.<br />
<br />
=== Preparing a Windows guest ===<br />
<br />
{{Note|1=The only (reliable) way to upgrade a Windows 8.1 guest to Windows 10 seems to be to temporarily choose cpu core2duo,nx for the install [http://ubuntuforums.org/showthread.php?t=2289210]. After the install, you may revert to other cpu settings (8/8/2015).}}<br />
<br />
==== Block device drivers ====<br />
<br />
===== New Install of Windows =====<br />
<br />
Windows does not come with the virtio drivers. Therefore, you will need to load them during installation. There are basically two ways to do this: via Floppy Disk or via ISO files. Both images can be downloaded from the [https://fedoraproject.org/wiki/Windows_Virtio_Drivers Fedora repository].<br />
<br />
The floppy disk option is difficult because you will need to press F6 (Shift-F6 on newer Windows) at the very beginning of powering on the QEMU. This is difficult since you need time to connect your VNC console window. You can attempt to add a delay to the boot sequence. See {{man|1|qemu}} for more details about applying a delay at boot.<br />
<br />
The ISO option to load drivers is the preferred way, but it is available only on Windows Vista and Windows Server 2008 and later. The procedure is to load the image with virtio drivers in an additional cdrom device along with the primary disk device and Windows installer:<br />
<br />
$ qemu-system-x86_64 ... \<br />
-drive file=''/path/to/primary/disk.img'',index=0,media=disk,if=virtio \<br />
-drive file=''/path/to/installer.iso'',index=2,media=cdrom \<br />
-drive file=''/path/to/virtio.iso'',index=3,media=cdrom \<br />
...<br />
<br />
During the installation, the Windows installer will ask you for your Product key and perform some additional checks. When it gets to the "Where do you want to install Windows?" screen, it will give a warning that no disks are found. Follow the example instructions below (based on Windows Server 2012 R2 with Update).<br />
<br />
* Select the option {{ic|Load Drivers}}.<br />
* Uncheck the box for "Hide drivers that aren't compatible with this computer's hardware".<br />
* Click the Browse button and open the CDROM for the virtio iso, usually named "virtio-win-XX".<br />
* Now browse to {{ic|E:\viostor\[your-os]\amd64}}, select it, and press OK.<br />
* Click Next<br />
<br />
You should now see your virtio disk(s) listed here, ready to be selected, formatted and installed to.<br />
<br />
===== Change Existing Windows VM to use virtio =====<br />
Modifying an existing Windows guest for booting from virtio disk is a bit tricky.<br />
<br />
You can download the virtio disk driver from the [https://fedoraproject.org/wiki/Windows_Virtio_Drivers Fedora repository].<br />
<br />
Now you need to create a new disk image, which will force Windows to search for the driver. For example:<br />
<br />
$ qemu-img create -f qcow2 ''fake.qcow2'' 1G<br />
<br />
Run the original Windows guest (with the boot disk still in IDE mode) with the fake disk (in virtio mode) and a CD-ROM with the driver.<br />
<br />
$ qemu-system-x86_64 -m 512 -vga std -drive file=''windows_disk_image'',if=ide -drive file=''fake.qcow2'',if=virtio -cdrom virtio-win-0.1-81.iso<br />
<br />
Windows will detect the fake disk and try to find a driver for it. If it fails, go to the ''Device Manager'', locate the SCSI drive with an exclamation mark icon (should be open), click ''Update driver'' and select the virtual CD-ROM. Do not forget to select the checkbox which says to search for directories recursively.<br />
<br />
When the installation is successful, you can turn off the virtual machine and launch it again, now with the boot disk attached in virtio mode:<br />
<br />
$ qemu-system-x86_64 -m 512 -vga std -drive file=''windows_disk_image'',if=virtio<br />
<br />
{{Note|If you encounter the Blue Screen of Death, make sure you did not forget the {{ic|-m}} parameter, and that you do not boot with virtio instead of ide for the system drive before drivers are installed.}}<br />
<br />
==== Network drivers ====<br />
<br />
Installing virtio network drivers is a bit easier, simply add the {{ic|-net}} argument as explained above.<br />
<br />
$ qemu-system-x86_64 -m 512 -vga std -drive file=''windows_disk_image'',if=virtio -net nic,model=virtio -cdrom virtio-win-0.1-74.iso<br />
<br />
Windows will detect the network adapter and try to find a driver for it. If it fails, go to the ''Device Manager'', locate the network adapter with an exclamation mark icon (should be open), click ''Update driver'' and select the virtual CD-ROM. Do not forget to select the checkbox which says to search for directories recursively.<br />
<br />
==== Balloon driver ====<br />
<br />
If you want to track you guest memory state (for example via {{ic|virsh}} command {{ic|dommemstat}}) or change guest's memory size in runtime (you still won't be able to change memory size, but can limit memory usage via inflating balloon driver) you will need to install guest balloon driver.<br />
<br />
For this you will need to go to ''Device Manager'', locate ''PCI standard RAM Controller'' in ''System devices'' (or unrecognized PCI controller from ''Other devices'') and choose ''Update driver''. In opened window you will need to choose ''Browse my computer...'' and select the CD-ROM (and don't forget the ''Include subdirectories'' checkbox). Reboot after installation. This will install the driver and you will be able to inflate the balloon (for example via hmp command {{ic|balloon ''memory_size''}}, which will cause balloon to take as much memory as possible in order to shrink the guest's available memory size to ''memory_size''). However, you still won't be able to track guest memory state. In order to do this you will need to install ''Balloon'' service properly. For that open command line as administrator, go to the CD-ROM, ''Balloon'' directory and deeper, depending on your system and architecture. Once you are in ''amd64'' (''x86'') directory, run {{ic|blnsrv.exe -i}} which will do the installation. After that {{ic|virsh}} command {{ic|dommemstat}} should be outputting all supported values.<br />
<br />
=== Preparing a FreeBSD guest ===<br />
<br />
Install the {{ic|emulators/virtio-kmod}} port if you are using FreeBSD 8.3 or later up until 10.0-CURRENT where they are included into the kernel. After installation, add the following to your {{ic|/boot/loader.conf}} file:<br />
<br />
{{bc|<nowiki><br />
virtio_loader="YES"<br />
virtio_pci_load="YES"<br />
virtio_blk_load="YES"<br />
if_vtnet_load="YES"<br />
virtio_balloon_load="YES"<br />
</nowiki>}}<br />
<br />
Then modify your {{ic|/etc/fstab}} by doing the following:<br />
<br />
{{bc|<nowiki><br />
sed -i bak "s/ada/vtbd/g" /etc/fstab<br />
</nowiki>}}<br />
<br />
And verify that {{ic|/etc/fstab}} is consistent. If anything goes wrong, just boot into a rescue CD and copy {{ic|/etc/fstab.bak}} back to {{ic|/etc/fstab}}.<br />
<br />
== QEMU Monitor ==<br />
<br />
While QEMU is running, a monitor console is provided in order to provide several ways to interact with the virtual machine running. The QEMU Monitor offers interesting capabilities such as obtaining information about the current virtual machine, hotplugging devices, creating snapshots of the current state of the virtual machine, etc. To see the list of all commands, run {{ic|help}} or {{ic|?}} in the QEMU monitor console or review the relevant section of the [https://qemu.weilnetz.de/doc/qemu-doc.html#pcsys_005fmonitor official QEMU documentation].<br />
<br />
=== Accessing the monitor console ===<br />
<br />
When using the {{ic|std}} default graphics option, one can access the QEMU Monitor by pressing {{ic|Ctrl+Alt+2}} or by clicking ''View > compatmonitor0'' in the QEMU window. To return to the virtual machine graphical view either press {{ic|Ctrl+Alt+1}} or click ''View > VGA''.<br />
<br />
However, the standard method of accessing the monitor is not always convenient and does not work in all graphic outputs QEMU supports. Alternative options of accessing the monitor are described below:<br />
<br />
* [[telnet]]: Run QEMU with the {{ic|-monitor telnet:127.0.0.1:''port'',server,nowait}} parameter. When the virtual machine is started you will be able to access the monitor via telnet:<br />
$ telnet 127.0.0.1 ''port''<br />
{{Note|If {{ic|127.0.0.1}} is specified as the IP to listen it will be only possible to connect to the monitor from the same host QEMU is running on. If connecting from remote hosts is desired, QEMU must be told to listen {{ic|0.0.0.0}} as follows: {{ic|-monitor telnet:0.0.0.0:''port'',server,nowait}}. Keep in mind that it is recommended to have a [[firewall]] configured in this case or make sure your local network is completely trustworthy since this connection is completely unauthenticated and unencrypted.}}<br />
<br />
* UNIX socket: Run QEMU with the {{ic|-monitor unix:''socketfile'',server,nowait}} parameter. Then you can connect with either {{pkg|socat}} or {{pkg|openbsd-netcat}}.<br />
<br />
For example, if QEMU is run via:<br />
<br />
$ qemu-system-x86_64 ''[...]'' -monitor unix:/tmp/monitor.sock,server,nowait ''[...]''<br />
<br />
It is possible to connect to the monitor with:<br />
<br />
$ socat - UNIX-CONNECT:/tmp/monitor.sock<br />
<br />
Or with:<br />
<br />
$ nc -U /tmp/monitor.sock<br />
<br />
* TCP: You can expose the monitor over TCP with the argument {{ic|-monitor tcp:127.0.0.1:''port'',server,nowait}}. Then connect with netcat, either {{pkg|openbsd-netcat}} or {{pkg|gnu-netcat}} by running:<br />
<br />
$ nc 127.0.0.1 ''port''<br />
<br />
{{Note|In order to be able to connect to the tcp socket from other devices other than the same host QEMU is being run on you need to listen to {{ic|0.0.0.0}} like explained in the telnet case. The same security warnings apply in this case as well.}}<br />
<br />
* Standard I/O: It is possible to access the monitor automatically from the same terminal QEMU is being run by running it with the argument {{ic|-monitor stdio}}.<br />
<br />
=== Sending keyboard presses to the virtual machine using the monitor console ===<br />
<br />
Some combinations of keys may be difficult to perform on virtual machines due to the host intercepting them instead in some configurations (a notable example is the {{ic|Ctrl+Alt+F*}} key combinations, which change the active tty). To avoid this problem, the problematic combination of keys may be sent via the monitor console instead. Switch to the monitor and use the {{ic|sendkey}} command to forward the necessary keypresses to the virtual machine. For example:<br />
<br />
(qemu) sendkey ctrl-alt-f2<br />
<br />
=== Creating and managing snapshots via the monitor console ===<br />
<br />
{{Note|This feature will '''only''' work when the virtual machine disk image is in ''qcow2'' format. It will not work with ''raw'' images.}}<br />
<br />
It is sometimes desirable to save the current state of a virtual machine and having the possibility of reverting the state of the virtual machine to that of a previously saved snapshot at any time. The QEMU monitor console provides the user with the necessary utilities to create snapshots, manage them, and revert the machine state to a saved snapshot.<br />
<br />
* Use {{ic|savevm ''name''}} in order to create a snapshot with the tag ''name''.<br />
* Use {{ic|loadvm ''name''}} to revert the virtual machine to the state of the snapshot ''name''.<br />
* Use {{ic|delvm ''name''}} to delete the snapshot tagged as ''name''.<br />
* Use {{ic|info snapshots}} to see a list of saved snapshots. Snapshots are identified by both an auto-incremented ID number and a text tag (set by the user on snapshot creation).<br />
<br />
=== Running the virtual machine in immutable mode ===<br />
<br />
It is possible to run a virtual machine in a frozen state so that all changes will be discarded when the virtual machine is powered off just by running QEMU with the {{ic|-snapshot}} parameter. When the disk image is written by the guest, changes will be saved in a temporary file in {{ic|/tmp}} and will be discarded when QEMU halts.<br />
<br />
However, if a machine is running in frozen mode it is still possible to save the changes to the disk image if it is afterwards desired by using the monitor console and running the following command:<br />
<br />
(qemu) commit<br />
<br />
If snapshots are created when running in frozen mode they will be discarded as soon as QEMU is exited unless changes are explicitly commited to disk, as well.<br />
<br />
=== Pause and power options via the monitor console ===<br />
<br />
Some operations of a physical machine can be emulated by QEMU using some monitor commands:<br />
<br />
* {{ic|system_powerdown}} will send an ACPI shutdown request to the virtual machine. This effect is similar to the power button in a physical machine.<br />
* {{ic|system_reset}} will reset the virtual machine similarly to a reset button in a physical machine. This operation can cause data loss and file system corruption since the virtual machine is not cleanly restarted.<br />
* {{ic|stop}} will pause the virtual machine.<br />
* {{ic|cont}} will resume a virtual machine previously paused.<br />
<br />
=== Taking screenshots of the virtual machine ===<br />
<br />
Screenshots of the virtual machine graphic display can be obtained in the PPM format by running the following command in the monitor console:<br />
<br />
(qemu) screendump ''file.ppm''<br />
<br />
== Tips and tricks ==<br />
<br />
=== Starting QEMU virtual machines on boot ===<br />
<br />
==== With libvirt ====<br />
<br />
If a virtual machine is set up with [[libvirt]], it can be configured with {{ic|virsh autostart}} or through the ''virt-manager'' GUI to start at host boot by going to the Boot Options for the virtual machine and selecting "Start virtual machine on host boot up".<br />
<br />
==== Custom script ====<br />
<br />
To run QEMU VMs on boot, you can use following systemd unit and config.<br />
<br />
{{hc|/etc/systemd/system/qemu@.service|<nowiki><br />
[Unit]<br />
Description=QEMU virtual machine<br />
<br />
[Service]<br />
Environment="type=system-x86_64" "haltcmd=kill -INT $MAINPID"<br />
EnvironmentFile=/etc/conf.d/qemu.d/%i<br />
PIDFile=/tmp/%i.pid<br />
ExecStart=/usr/bin/env qemu-${type} -name %i -nographic -pidfile /tmp/%i.pid $args<br />
ExecStop=/bin/sh -c ${haltcmd}<br />
TimeoutStopSec=30<br />
KillMode=none<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
{{Note|<br />
* According to {{man|5|systemd.service}} and {{ic|5|systemd.kill}} man pages it is necessary to use the {{ic|1=KillMode=none}} option. Otherwise the main qemu process will be killed immediately after the {{ic|ExecStop}} command quits (it simply echoes one string) and your quest system will not be able to shutdown correctly.<br />
* It is necessary to use the {{ic|PIDFile}} option. Otherwise systemd cannot tell whether the main qemu process was terminated and your quest system will not be able to shutdown correctly. On host shutdown it will proceed without waiting for the VM to shutdown.<br />
}}<br />
<br />
Then create per-VM configuration files, named {{ic|/etc/conf.d/qemu.d/''vm_name''}}, with the following variables set:<br />
<br />
; type<br />
: QEMU binary to call. If specified, will be prepended with {{ic|/usr/bin/qemu-}} and that binary will be used to start the VM. I.e. you can boot e.g. {{ic|qemu-system-arm}} images with {{ic|1=type="system-arm"}}.<br />
; args<br />
: QEMU command line to start with. Will always be prepended with {{ic|-name ${vm} -nographic}}.<br />
; haltcmd<br />
: Command to shut down a VM safely. In this example, the QEMU monitor is exposed via telnet using {{ic|-monitor telnet:..}} and the VMs are powered off via ACPI by sending {{ic|system_powerdown}} to monitor with the {{ic|nc}} command. You can use SSH or some other ways as well.<br />
<br />
Example configs:<br />
<br />
{{hc|/etc/conf.d/qemu.d/one|<nowiki><br />
type="system-x86_64"<br />
<br />
args="-enable-kvm -m 512 -hda /dev/mapper/vg0-vm1 -net nic,macaddr=DE:AD:BE:EF:E0:00 \<br />
-net tap,ifname=tap0 -serial telnet:localhost:7000,server,nowait,nodelay \<br />
-monitor telnet:localhost:7100,server,nowait,nodelay -vnc :0"<br />
<br />
haltcmd="echo 'system_powerdown' | nc localhost 7100" # or netcat/ncat<br />
<br />
# You can use other ways to shut down your VM correctly<br />
#haltcmd="ssh powermanager@vm1 sudo poweroff"<br />
</nowiki>}}<br />
<br />
{{hc|/etc/conf.d/qemu.d/two|<nowiki><br />
args="-enable-kvm -m 512 -hda /srv/kvm/vm2.img -net nic,macaddr=DE:AD:BE:EF:E0:01 \<br />
-net tap,ifname=tap1 -serial telnet:localhost:7001,server,nowait,nodelay \<br />
-monitor telnet:localhost:7101,server,nowait,nodelay -vnc :1"<br />
<br />
haltcmd="echo 'system_powerdown' | nc localhost 7101"<br />
</nowiki>}}<br />
<br />
To set which virtual machines will start on boot-up, [[enable]] the {{ic|qemu@''vm_name''.service}} systemd unit.<br />
<br />
=== Mouse integration ===<br />
<br />
To prevent the mouse from being grabbed when clicking on the guest operating system's window, add the options {{ic|-usb -device usb-tablet}}. This means QEMU is able to report the mouse position without having to grab the mouse. This also overrides PS/2 mouse emulation when activated. For example:<br />
<br />
$ qemu-system-x86_64 -hda ''disk_image'' -m 512 -vga std -usb -device usb-tablet<br />
<br />
If that does not work, try the tip at [[#Mouse cursor is jittery or erratic]].<br />
<br />
=== Pass-through host USB device ===<br />
<br />
To access physical USB device connected to host from VM, you can use the option: {{ic|-usbdevice host:''vendor_id'':''product_id''}}.<br />
<br />
You can find {{ic|vendor_id}} and {{ic|product_id}} of your device with {{ic|lsusb}} command.<br />
<br />
Since the default I440FX chipset emulated by qemu feature a single UHCI controller (USB 1), the {{ic|-usbdevice}} option will try to attach your physical device to it. In some cases this may cause issues with newer devices. A possible solution is to emulate the [http://wiki.qemu.org/Features/Q35 ICH9] chipset, which offer an EHCI controller supporting up to 12 devices, using the option {{ic|1=-machine type=q35}}.<br />
<br />
A less invasive solution is to emulate an EHCI (USB 2) or XHCI (USB 3) controller with the option {{ic|1=-device usb-ehci,id=ehci}} or {{ic|1=-device nec-usb-xhci,id=xhci}} respectively and then attach your physical device to it with the option {{ic|1=-device usb-host,..}} as follows:<br />
<br />
-device usb-host,bus='''controller_id'''.0,vendorid=0x'''vendor_id''',productid=0x'''product_id'''<br />
<br />
You can also add the {{ic|1=...,port=''<n>''}} setting to the previous option to specify in which physical port of the virtual controller you want to attach your device, useful in the case you want to add multiple usb devices to the VM.<br />
<br />
{{Note|If you encounter permission errors when running QEMU, see [[Udev#Writing udev rules]] for information on how to set permissions of the device.}}<br />
<br />
=== USB redirection with SPICE ===<br />
<br />
When using [[#SPICE]] it is possible to redirect USB devices from the client to the virtual machine without needing to specify them in the QEMU command. It is possible to configure the number of USB slots available for redirected devices (the number of slots will determine the maximum number of devices which can be redirected simultaneously). The main advantages of using SPICE for redirection compared to the previously-mentioned {{ic|-usbdevice}} method is the possibility of hot-swapping USB devices after the virtual machine has started, without needing to halt it in order to remove USB devices from the redirection or adding new ones. This method of USB redirection also allows us to redirect USB devices over the network, from the client to the server. In summary, it is the most flexible method of using USB devices in a QEMU virtual machine.<br />
<br />
We need to add one EHCI/UHCI controller per available USB redirection slot desired as well as one SPICE redirection channel per slot. For example, adding the following arguments to the QEMU command you use for starting the virtual machine in SPICE mode will start the virtual machine with three available USB slots for redirection:<br />
<br />
{{bc|<nowiki>-device ich9-usb-ehci1,id=usb \<br />
-device ich9-usb-uhci1,masterbus=usb.0,firstport=0,multifunction=on \<br />
-device ich9-usb-uhci2,masterbus=usb.0,firstport=2 \<br />
-device ich9-usb-uhci3,masterbus=usb.0,firstport=4 \<br />
-chardev spicevmc,name=usbredir,id=usbredirchardev1 \<br />
-device usb-redir,chardev=usbredirchardev1,id=usbredirdev1 \<br />
-chardev spicevmc,name=usbredir,id=usbredirchardev2 \<br />
-device usb-redir,chardev=usbredirchardev2,id=usbredirdev2 \<br />
-chardev spicevmc,name=usbredir,id=usbredirchardev3 \<br />
-device usb-redir,chardev=usbredirchardev3,id=usbredirdev3</nowiki>}}<br />
<br />
Both {{ic|spicy}} from {{Pkg|spice-gtk}} (''Input > Select USB Devices for redirection'') and {{ic|remote-viewer}} from {{pkg|virt-viewer}} (''File > USB device selection'') support this feature. Please make sure that you have installed the necessary SPICE Guest Tools on the virtual machine for this functionality to work as expected (see the [[#SPICE]] section for more information).<br />
<br />
{{Warning|Keep in mind that when a USB device is redirected from the client, it will not be usable from the client operating system itself until the redirection is stopped. It is specially important to never redirect the input devices (namely mouse and keyboard), since it will be then difficult to access the SPICE client menus to revert the situation, because the client will not respond to the input devices after being redirected to the virtual machine.}}<br />
<br />
=== Enabling KSM ===<br />
<br />
Kernel Samepage Merging (KSM) is a feature of the Linux kernel that allows for an application to register with the kernel to have its pages merged with other processes that also register to have their pages merged. The KSM mechanism allows for guest virtual machines to share pages with each other. In an environment where many of the guest operating systems are similar, this can result in significant memory savings.<br />
<br />
{{Note|Although KSM may reduce memory usage, it may increase CPU usage. Also note some security issues may occur, see [[Wikipedia:Kernel same-page merging]].}}<br />
<br />
To enable KSM:<br />
<br />
# echo 1 > /sys/kernel/mm/ksm/run<br />
<br />
To make it permanent, use [[systemd#Temporary files|systemd's temporary files]]:<br />
<br />
{{hc|/etc/tmpfiles.d/ksm.conf|<br />
w /sys/kernel/mm/ksm/run - - - - 1<br />
}}<br />
<br />
If KSM is running, and there are pages to be merged (i.e. at least two similar VMs are running), then {{ic|/sys/kernel/mm/ksm/pages_shared}} should be non-zero. See https://www.kernel.org/doc/Documentation/vm/ksm.txt for more information.<br />
<br />
{{Tip|An easy way to see how well KSM is performing is to simply print the contents of all the files in that directory: {{bc|$ grep . /sys/kernel/mm/ksm/*}}}}<br />
<br />
=== Multi-monitor support ===<br />
The Linux QXL driver supports four heads (virtual screens) by default. This can be changed via the {{ic|1=qxl.heads=N}} kernel parameter.<br />
<br />
The default VGA memory size for QXL devices is 16M (VRAM size is 64M). This is not sufficient if you would like to enable two 1920x1200 monitors since that requires 2 × 1920 × 4 (color depth) × 1200 = 17.6 MiB VGA memory. This can be changed by replacing {{ic|-vga qxl}} by {{ic|<nowiki>-vga none -device qxl-vga,vgamem_mb=32</nowiki>}}. If you ever increase vgamem_mb beyond 64M, then you also have to increase the {{ic|vram_size_mb}} option.<br />
<br />
=== Copy and paste ===<br />
<br />
To have copy and paste between the host and the guest you need to enable the spice agent communication channel. It requires to add a virtio-serial device to the guest, and open a port for the spice vdagent. It is also required to install the spice vdagent in guest ({{Pkg|spice-vdagent}} for Arch guests, [http://www.spice-space.org/download.html Windows guest tools] for Windows guests). Make sure the agent is running (and for future, started automatically). See [[#SPICE]] for the necessary procedure to use QEMU with the SPICE protocol.<br />
<br />
=== Windows-specific notes ===<br />
<br />
QEMU can run any version of Windows from Windows 95 through Windows 10.<br />
<br />
It is possible to run [[Windows PE]] in QEMU.<br />
<br />
==== Fast startup ====<br />
{{Note|An administrator account is required to change power settings.}}<br />
For Windows 8 (or later) guests it is better to disable "Turn on fast startup (recommended)" from the Power Options of the Control Panel as explained in the following [https://www.tenforums.com/tutorials/4189-turn-off-fast-startup-windows-10-a.html forum page], as it causes the guest to hang during every other boot.<br />
<br />
Fast Startup may also need to be disabled for changes to the {{ic|-smp}} option to be properly applied.<br />
<br />
==== Remote Desktop Protocol ====<br />
<br />
If you use a MS Windows guest, you might want to use RDP to connect to your guest VM. If you are using a VLAN or are not in the same network as the guest, use:<br />
<br />
$ qemu-system-x86_64 -nographic -net user,hostfwd=tcp::5555-:3389<br />
<br />
Then connect with either {{Pkg|rdesktop}} or {{Pkg|freerdp}} to the guest. For example:<br />
<br />
$ xfreerdp -g 2048x1152 localhost:5555 -z -x lan<br />
<br />
== Troubleshooting ==<br />
<br />
=== Virtual machine runs too slowly ===<br />
<br />
There are a number of techniques that you can use to improve the performance of your virtual machine. For example:<br />
<br />
* Use the {{ic|-cpu host}} option to make QEMU emulate the host's exact CPU. If you do not do this, it may be trying to emulate a more generic CPU.<br />
* Especially for Windows guests, enable [http://blog.wikichoon.com/2014/07/enabling-hyper-v-enlightenments-with-kvm.html Hyper-V enlightenments]: {{ic|1=-cpu host,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time}}.<br />
* If the host machine has multiple CPUs, assign the guest more CPUs using the {{ic|-smp}} option.<br />
* Make sure you have assigned the virtual machine enough memory. By default, QEMU only assigns 128 MiB of memory to each virtual machine. Use the {{ic|-m}} option to assign more memory. For example, {{ic|-m 1024}} runs a virtual machine with 1024 MiB of memory.<br />
* Use KVM if possible: add {{ic|1=-machine type=pc,accel=kvm}} to the QEMU start command you use.<br />
* If supported by drivers in the guest operating system, use [http://wiki.libvirt.org/page/Virtio virtio] for network and/or block devices. For example:<br />
$ qemu-system-x86_64 -net nic,model=virtio -net tap,if=tap0,script=no -drive file=''disk_image'',media=disk,if=virtio<br />
* Use TAP devices instead of user-mode networking. See [[#Tap networking with QEMU]].<br />
* If the guest OS is doing heavy writing to its disk, you may benefit from certain mount options on the host's file system. For example, you can mount an [[Ext4|ext4 file system]] with the option {{ic|1=barrier=0}}. You should read the documentation for any options that you change because sometimes performance-enhancing options for file systems come at the cost of data integrity.<br />
* If you have a raw disk image, you may want to disable the cache:<br />
$ qemu-system-x86_64 -drive file=''disk_image'',if=virtio,'''cache=none'''<br />
* Use the native Linux AIO:<br />
$ qemu-system-x86_64 -drive file=''disk_image'',if=virtio''',aio=native,cache.direct=on'''<br />
* If you use a qcow2 disk image, I/O performance can be improved considerably by ensuring that the L2 cache is of sufficient size. The [https://blogs.igalia.com/berto/2015/12/17/improving-disk-io-performance-in-qemu-2-5-with-the-qcow2-l2-cache/ formula] to calculate L2 cache is: l2_cache_size = disk_size * 8 / cluster_size. Assuming the qcow2 image was created with the default cluster size of 64K, this means that for every 8 GB in size of the qcow2 image, 1 MB of L2 cache is best for performance. Only 1 MB is used by QEMU by default; specifying a larger cache is done on the QEMU command line. For instance, to specify 4 MB of cache (suitable for a 32 GB disk with a cluster size of 64K):<br />
$ qemu-system-x86_64 -drive file=''disk_image'',format=qcow2,l2-cache-size=4M<br />
* If you are running multiple virtual machines concurrently that all have the same operating system installed, you can save memory by enabling [[wikipedia:Kernel_SamePage_Merging_(KSM)|kernel same-page merging]]. See [[#Enabling KSM]].<br />
* In some cases, memory can be reclaimed from running virtual machines by running a memory ballooning driver in the guest operating system and launching QEMU with the {{ic|-balloon virtio}} option.<br />
* It is possible to use a emulation layer for an ICH-9 AHCI controller (although it may be unstable). The AHCI emulation supports [[Wikipedia:Native_Command_Queuing|NCQ]], so multiple read or write requests can be outstanding at the same time:<br />
$ qemu-system-x86_64 -drive id=disk,file=''disk_image'',if=none -device ich9-ahci,id=ahci -device ide-drive,drive=disk,bus=ahci.0<br />
<br />
See http://www.linux-kvm.org/page/Tuning_KVM for more information.<br />
<br />
=== Mouse cursor is jittery or erratic ===<br />
<br />
If the cursor jumps around the screen uncontrollably, entering this on the terminal before starting QEMU might help:<br />
<br />
$ export SDL_VIDEO_X11_DGAMOUSE=0<br />
<br />
If this helps, you can add this to your {{ic|~/.bashrc}} file.<br />
<br />
=== No visible Cursor ===<br />
<br />
Add {{ic|-show-cursor}} to QEMU's options to see a mouse cursor.<br />
<br />
If that still does not work, make sure you have set your display device appropriately.<br />
<br />
For example: {{ic|-vga qxl}}<br />
<br />
=== Unable to move/attach Cursor ===<br />
<br />
Replace {{ic|-usbdevice tablet}} with {{ic|-usb}} as QEMU option.<br />
<br />
=== Keyboard seems broken or the arrow keys do not work ===<br />
<br />
Should you find that some of your keys do not work or "press" the wrong key (in particular, the arrow keys), you likely need to specify your keyboard layout as an option. The keyboard layouts can be found in {{ic|/usr/share/qemu/keymaps}}.<br />
<br />
$ qemu-system-x86_64 -k ''keymap'' ''disk_image''<br />
<br />
=== Guest display stretches on window resize ===<br />
<br />
To restore default window size, press {{ic|Ctrl+Alt+u}}.<br />
<br />
=== ioctl(KVM_CREATE_VM) failed: 16 Device or resource busy ===<br />
<br />
If an error message like this is printed when starting QEMU with {{ic|-enable-kvm}} option:<br />
<br />
ioctl(KVM_CREATE_VM) failed: 16 Device or resource busy<br />
failed to initialize KVM: Device or resource busy<br />
<br />
that means another [[hypervisor]] is currently running. It is not recommended or possible to run several hypervisors in parallel.<br />
<br />
=== libgfapi error message ===<br />
<br />
The error message displayed at startup:<br />
<br />
Failed to open module: libgfapi.so.0: cannot open shared object file: No such file or directory<br />
<br />
[[Install]] {{pkg|glusterfs}} or ignore the error message as GlusterFS is a optional dependency.<br />
<br />
=== Kernel panic on LIVE-environments===<br />
<br />
If you start a live-environment (or better: booting a system) you may encounter this:<br />
<br />
[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown block(0,0)<br />
<br />
or some other boot hindering process (e.g. cannot unpack initramfs, cant start service foo).<br />
Try starting the VM with the {{ic|-m VALUE}} switch and an appropriate amount of RAM, if the ram is to low you will probably encounter similar issues as above/without the memory-switch.<br />
<br />
=== Windows 7 guest suffers low-quality sound ===<br />
<br />
Using the {{ic|hda}} audio driver for Windows 7 guest may result in low-quality sound. Changing the audio driver to {{ic|ac97}} by passing the {{ic|-soundhw ac97}} arguments to QEMU and installing the AC97 driver from [http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1&PNid=14&PFid=23&Level=4&Conn=3&DownTypeID=3&GetDown=false Realtek AC'97 Audio Codecs] in the guest may solve the problem. See [https://bugzilla.redhat.com/show_bug.cgi?id=1176761#c16 Red Hat Bugzilla – Bug 1176761] for more information.<br />
<br />
=== Could not access KVM kernel module: Permission denied ===<br />
<br />
If you encounter the following error:<br />
<br />
libvirtError: internal error: process exited while connecting to monitor: Could not access KVM kernel module: Permission denied failed to initialize KVM: Permission denied<br />
<br />
Systemd 234 assign it a dynamic id to group kvm (see [https://bugs.archlinux.org/task/54943 bug]). A workground for avoid this error, you need edit the file {{ic|/etc/libvirt/qemu.conf}} and change the line:<br />
<br />
group = "78"<br />
<br />
to<br />
<br />
group = "kvm"<br />
<br />
=== "System Thread Exception Not Handled" when booting a Windows VM ===<br />
<br />
Windows 8 or Windows 10 guests may raise a generic compatibility exception at boot, namely "System Thread Exception Not Handled", which tends to be caused by legacy drivers acting strangely on real machines. On KVM machines this issue can generally be solved by setting the CPU model to {{ic|core2duo}}.<br />
<br />
=== Certain Windows games/applications crashing/causing a bluescreen ===<br />
<br />
Occasionally, applications running in the VM may crash unexpectedly, whereas they'd run normally on a physical machine. If, while running {{ic|dmesg -wH}}, you encounter an error mentioning {{ic|MSR}}, the reason for those crashes is that KVM injects a [[wikipedia:General protection fault|General protection fault]] (GPF) when the guest tries to access unsupported [[wikipedia:Model-specific register|Model-specific registers]] (MSRs) - this often results in guest applications/OS crashing. A number of those issues can be solved by passing the {{ic|1=ignore_msrs=1}} option to the KVM module, which will ignore unimplemented MSRs.<br />
<br />
{{hc|/etc/modprobe.d/kvm.conf|2=<br />
...<br />
options kvm ignore_msrs=1<br />
...<br />
}}<br />
<br />
Cases where adding this option might help:<br />
<br />
* GeForce Experience complaining about an unsupported CPU being present.<br />
* StarCraft 2 and L.A. Noire reliably blue-screening Windows 10 with {{ic|KMODE_EXCEPTION_NOT_HANDLED}}. The blue screen information does not identify a driver file in these cases.<br />
<br />
{{Warning|While this is normally safe and some applications might not work without this, silently ignoring unknown MSR accesses could potentially break other software within the VM or other VMs.}}<br />
<br />
== See also ==<br />
<br />
* [http://qemu.org Official QEMU website]<br />
* [http://www.linux-kvm.org Official KVM website]<br />
* [http://qemu.weilnetz.de/qemu-doc.html QEMU Emulator User Documentation]<br />
* [https://en.wikibooks.org/wiki/QEMU QEMU Wikibook]<br />
* [http://alien.slackbook.org/dokuwiki/doku.php?id=slackware:qemu Hardware virtualization with QEMU] by AlienBOB (last updated in 2008)<br />
* [http://blog.falconindy.com/articles/build-a-virtual-army.html Building a Virtual Army] by Falconindy<br />
* [http://git.qemu.org/?p=qemu.git;a=tree;f=docs Lastest docs]<br />
* [http://qemu.weilnetz.de/ QEMU on Windows]<br />
* [[wikipedia:Qemu|Wikipedia]]<br />
* [[debian:QEMU|Debian Wiki - QEMU]]<br />
* [https://people.gnome.org/~markmc/qemu-networking.html QEMU Networking on gnome.org]<br />
* [http://bsdwiki.reedmedia.net/wiki/networking_qemu_virtual_bsd_systems.html Networking QEMU Virtual BSD Systems]<br />
* [https://www.gnu.org/software/hurd/hurd/running/qemu.html QEMU on gnu.org]<br />
* [https://wiki.freebsd.org/qemu QEMU on FreeBSD as host]<br />
* [https://wiki.mikejung.biz/KVM_/_Xen KVM/QEMU Virtio Tuning and SSD VM Optimization Guide]<br />
* [https://doc.opensuse.org/documentation/leap/virtualization/html/book.virt/part.virt.qemu.html Managing Virtual Machines with QEMU - OpenSUSE documentation]<br />
* [https://www.ibm.com/support/knowledgecenter/en/linuxonibm/liaat/liaatkvm.htm KVM on IBM Knowledge Center]</div>Asdil12https://wiki.archlinux.org/index.php?title=Fail2ban&diff=366747Fail2ban2015-03-22T18:22:11Z<p>Asdil12: /* SSH jail */ add not about aur pkg</p>
<hr />
<div>[[Category:Secure Shell]]<br />
[[ja:Fail2ban]]<br />
[[ro:Fail2ban]]<br />
{{Warning|Using an IP blacklist will stop trivial attacks but it relies on an additional daemon and successful logging (the partition containing /var can become full, especially if an attacker is pounding on the server). Additionally, if the attacker knows your IP address, they can send packets with a spoofed source header and get you locked out of the server. [[SSH keys]] provide an elegant solution to the problem of brute forcing without these problems.}}<br />
<br />
[http://www.fail2ban.org/wiki/index.php/Main_Page Fail2ban] scans various textual log files and bans IP that makes too many password failures by updating firewall rules to reject the IP address, similar to [[Sshguard]]. <br />
<br />
{{Warning|For correct function it is essential that the tool parses the IP addresses in the log correctly. You should always '''test''' the log filters work as intended per application you want to protect.}}<br />
<br />
== Installation ==<br />
<br />
Install {{Pkg|fail2ban}} from the [[official repositories]].<br />
<br />
If you want Fail2ban to send an email when someone has been banned, you have to configure [[SSMTP]] (for example).<br />
<br />
=== systemd ===<br />
<br />
Use the service unit {{ic|fail2ban.service}}, refer to [[systemd]] for instructions.<br />
<br />
== Hardening ==<br />
<br />
Currently, fail2ban requires to run as root, therefore you may wish to consider some additional hardening on the process with systemd. Ref:[http://0pointer.de/blog/projects/security.html systemd for Administrators, Part XII]<br />
<br />
=== Capabilities ===<br />
<br />
For added security consider limiting fail2ban capabilities by specifying {{ic|CapabilityBoundingSet}} in the [[Systemd#Editing_provided_unit_files|drop-in configuration file]] for the provided {{ic|fail2ban.service}}:<br />
<br />
{{hc|/etc/systemd/system/fail2ban.service.d/capabilities.conf|2=<br />
[Service]<br />
CapabilityBoundingSet=CAP_DAC_READ_SEARCH CAP_NET_ADMIN CAP_NET_RAW<br />
}}<br />
<br />
In the example above, {{ic|CAP_DAC_READ_SEARCH}} will allow fail2ban full read access, and {{ic|CAP_NET_ADMIN}} and {{ic|CAP_NET_RAW}} allow setting of firewall rules with [[iptables]]. Additional capabilities may be required, depending on your fail2ban configuration. See {{ic|man capabilities}} for more info.<br />
<br />
=== Filesystem Access ===<br />
<br />
Also considering limiting file system read and write access, by using ''ReadOnlyDirectories'' and ''ReadWriteDirectories'', again under the {{ic|[Service]}} section. For example:<br />
ReadOnlyDirectories=/<br />
ReadWriteDirectories=/var/run/fail2ban /var/lib/fail2ban /var/spool/postfix/maildrop /tmp<br />
In the example above, this limits the file system to read-only, except for {{ic|/var/run/fail2ban}} for pid and socket files, and {{ic|/var/spool/postfix/maildrop}} for [[postfix]] sendmail. Again, this will be dependent on you system configuration and fail2ban configuration. The {{ic|/tmp}} directory is needed for some fail2ban actions. Note that adding {{ic|/var/log}} is necessary if you want fail2ban to log its activity.<br />
<br />
== SSH jail ==<br />
<br />
Edit {{ic|/etc/fail2ban/jail.conf}} and modify the ssh-iptables section to enable it and configure the action.<br />
<br />
{{Note|Due to the possibility of the {{ic|jail.conf}} file being overwritten or improved during a distribution update, it is recommended to provide customizations in a {{ic|jail.local}} file, or separate ''.conf'' files under the {{ic|jail.d/}} directory, e.g. {{ic|jail.d/ssh-iptables.conf}}.}}<br />
<br />
If your firewall is iptables:<br />
[ssh-iptables]<br />
enabled = true<br />
filter = sshd<br />
action = iptables[name=SSH, port=ssh, protocol=tcp]<br />
sendmail-whois[name=SSH, dest=your@mail.org, sender=fail2ban@mail.com]<br />
logpath = /var/log/auth.log<br />
maxretry = 5<br />
<br />
Fail2Ban from version 0.9 can also read directly from the systemd journal by setting {{ic|1=backend = systemd}} - but this requires the AUR package [https://aur.archlinux.org/packages/pyjournalctl/ pyjournalctl] to be installed!<br />
<br />
If your firewall is shorewall:<br />
[ssh-shorewall]<br />
enabled = true<br />
filter = sshd<br />
action = shorewall<br />
sendmail-whois[name=SSH, dest=your@mail.org, sender=fail2ban@mail.com]<br />
logpath = /var/log/auth.log<br />
maxretry = 5<br />
<br />
{{Note|You can set {{Ic|BLACKLIST}} to {{Ic|ALL}} in {{ic|/etc/shorewall/shorewall.conf}} otherwise the rule added to ban an IP address will affect only new connections.}}<br />
<br />
Also do not forget to add/change:<br />
LogLevel VERBOSE<br />
in your {{ic|/etc/ssh/sshd_config}}. Else, password failures are not logged correctly.<br />
<br />
== See also ==<br />
<br />
* [[sshguard]]</div>Asdil12https://wiki.archlinux.org/index.php?title=Bluetooth_keyboard&diff=293345Bluetooth keyboard2014-01-17T14:22:07Z<p>Asdil12: </p>
<hr />
<div>[[Category:Bluetooth]]<br />
[[Category:Keyboards]]<br />
[[ru:Bluetooth Keyboard]]<br />
This article describes how to set up a Bluetooth HID keyboard with Arch Linux, bluez version 5.<br />
<br />
== Pairing process ==<br />
<br />
Login to the affected computer by a wired keyboard or by ssh.<br />
<br />
First, make sure the local BT controller (e.g. a BT dongle the built in BT radio) is recognized:<br />
{{hc|# lsusb|<br />
Bus 001 Device 004: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)<br />
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter<br />
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp. LAN9500 Ethernet 10/100 Adapter / SMSC9512/9514 Hub<br />
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub<br />
}}<br />
<br />
The above output is from a Raspberry-Pi revision 'B' with archlinux-arm and a Keysonic BT Dongle.<br />
<br />
Start bluetooth service with ''systemctl'', or even better, enable it permanently in the start up process. See [[systemd]].<br />
<br />
Three items worth remembering:<br />
* BT devices (keyboard) and controllers (dongle) need to be paired once.<br />
* The BT controller needs to be powered up after every boot.<br />
* The BT controller needs to be told to connect to the keyboard after every boot.<br />
<br />
''Pairing'' is a one time process, required only once. There are BT keyboards sold with a BT dongle which come already paired, but that's not certain. We will use the {{ic|bluetoothctl}} command from bluez5 to pair our dongle and the keyboard. <br />
<br />
''Power up'' can be done with {{ic|bluetoothctl}}, or with {{ic|hciconfig}} which is more suitable for scripting. See below.<br />
<br />
Same for ''connecting'', either {{ic|bluetoothctl}} or {{ic|hcitool}} can be used, the latter is more useful for scripting.<br />
<br />
We will use {{ic|bluetoothctl}} for the pairing process:<br />
<br />
{{hc|# bluetoothctl -a|<br />
[bluetooth]#<br />
}}<br />
puts you at the {{ic|[bluetooth]#}} prompt. If you are on a colour console: the word "bluetooth" is in the default colour as long as no devices are available, and blue as soon as required devices and/or controllers have been found.<br />
<br />
While in ''bluetoothctl'' power up the controller:<br />
{{hc|[bluetooth]# power on|<br />
Changing power on succeeded<br />
[CHG] Controller 06:05:04:03:02:01 Powered: yes<br />
}}<br />
<br />
Next, tell {{ic|bluetoothctl}} to look only for keyboards, and make that the default agent:<br />
{{hc|[bluetooth]# agent KeyboardOnly|<br />
Agent registered<br />
}}<br />
<br />
{{hc|[bluetooth]# default-agent|<br />
Default agent request successful<br />
}}<br />
<br />
Next, put your controller (the local dongle) in ''pairable'' mode:<br />
{{hc|[bluetooth]# pairable on|<br />
Changing pairable on succeeded<br />
}}<br />
<br />
Next, put your keyboard in an active mode, where it is ''discoverable'', i.e. pairable. Some keyboards have a special button for this on the underside, or require a special key combination to be pressed. See the documentation of your keyboard. Please note that this ''discoverability'' of a device is time limited, some devices are only visible 30 seconds, other for 2 minutes. Your mileage may vary.<br />
<br />
Next, let the controller scan the BT frequencies for a suitable device:<br />
{{hc|[bluetooth]# scan on|<br />
Discovery started<br />
[CHG] Controller 06:05:04:03:02:01 Discovering: yes<br />
}}<br />
<br />
After a few seconds the adress of the keyboard should be listed as found. This line will repeat over and over, but won't stop you from entering new commands.<br />
<br />
Next, actually do the pairing. The address used is the BT-MAC address of the keyboard:<br />
{{hc|[bluetooth]# pair 01:02:03:04:05:06|<br />
Pairing successful<br />
}}<br />
<br />
Next, make this a trusted device (this allows the device to establish the connection on itself). Again, the BT-MAC address is the address of the keyboard device:<br />
{{hc|[bluetooth]# trust 01:02:03:04:05:06|<br />
Trusted <br />
}}<br />
<br />
Next and finally connect to the device (keyboard). Again, the BT-MAC address is the address of the keyboard device:<br />
{{hc|[bluetooth]# connect 01:02:03:04:05:06|<br />
Connection successful<br />
}}<br />
<br />
Done. Leave the {{ic|bluetoothctl}} utility:<br />
[bluetooth]# quit<br />
<br />
Now the external device (i.e. keyboard) and the USB BT dongle are paired permanently, unless you break the pairing intenionally. This does not mean that the keyboard will connect automatically to your BT device after a boot. ''Power up'' of the controller and ''connecting'' device and controller needs to be done after every startup of your computer.<br />
<br />
== Manually enabling a Bluetooth Keyboard ==<br />
<br />
Although the device and the controller are now paired (see above), you need to connect them every time the computer starts. <br />
<br />
First the BT controller (i.e. BT Dongle) needs to be powered up. This is done with the {{ic|hciconfig}} utility. We assume that you have only one BT device connected, and this one has the symbolic name {{ic|hci0}}. <br />
# hciconfig hci0 up<br />
<br />
Next, make the connection, now using the {{ic|hcitool}} utility. Make sure that the keyboard is powered up and connectable, i.e. not in a power saving sleep state.<br />
# hcitool cc 01:02:03:04:05:06<br />
<br />
Your BT keyboard should be useable now, even if an error message ("Can't create connection: Input/output error") is shown. Next we will discuss how to automate this process with [[systemd]].<br />
<br />
== Automatically enabling a Bluetooth Keyboard ==<br />
<br />
Here is one way to activate a Bluetooth keyboard after a system start. There are certainly other, more elegant ways, but for the moment this has to do. For these tests you need to be logged in to the affected computer, perhaps by a wired keyboard, or by ssh.<br />
<br />
We will write an custom systemd service file. Your need to know:<br />
* the MAC address of the BT keyboard. Find out with the '''scan on''' command of the {{ic|bluetoothctl}} utility.<br />
* the HCI device identifier of the controller. Find out with <br />
{{hc|# hcitool dev|<br />
Devices:<br />
hci0 06:05:04:03:02:01<br />
}}<br />
We are looking for the identifier 'hci0' in this case. The MAC address shown here is the address of the controller, not the address of the keyboard itself.<br />
<br />
Now create a config file {{ic|/etc/btkbd.conf}} which contains these two data items, the hci-identifier and the keyboard MAC address.<br />
<br />
{{bc|<nowiki><br />
# Config file for btkbd.service<br />
# change when required (e.g. keyboard hardware changes, more hci devices are connected)<br />
BTKBDMAC = <mac address here><br />
HCIDEVICE = <hci-device identifier here><br />
</nowiki>}}<br />
<br />
Next, create a new service file at {{ic|/etc/systemd/system/btkdb.service}}. <br />
<br />
{{bc|<nowiki><br />
[Unit]<br />
Description=systemd Unit to automatically start a Bluetooth keyboard<br />
Documentation=https://wiki.archlinux.org/index.php/Bluetooth_Keyboard<br />
Requires=dbus-org.bluez.service<br />
After=dbus-bluez.org.service<br />
ConditionPathExists=/etc/btkbd.conf<br />
ConditionPathExists=/usr/bin/hcitool<br />
ConditionPathExists=/usr/bin/hciconfig<br />
<br />
[Service]<br />
Type=oneshot<br />
EnvironmentFile=/etc/btkbd.conf<br />
ExecStart=<br />
ExecStart=/usr/bin/hciconfig ${HCIDEVICE} up<br />
# ignore errors on connect, spurious problems with bt? so start next command with -<br />
ExecStart=-/usr/bin/hcitool cc ${BTKBDMAC}<br />
</nowiki>}}<br />
<br />
Now start this service with the usual systemd utility and see what happens. Since my keyboard always reports an error on startup, the second command in the service unit file starts with a '-', ignoring any errors from hcitool. YMMV, test with {{ic|hcitool}} on the command line and see what happens.<br />
<br />
If all is ok, permanently enable this service with systemd's tools.<br />
<br />
== Troubleshooting ==<br />
{{Expansion|TBD}}<br />
* What if the BT controller does not show up in {{ic|lsusb}} ?<br />
* What if the BT controller is not visible in {{ic|bluetoothctl}} ?<br />
* My BT keyboard still does not work. What to do?<br />
** Check: Does it have power? <br />
** Check: Did it connect to the BT controller? If not, try with another controller or your smart phone.<br />
<br />
== Xorg ==<br />
Device should be added as {{ic|/dev/input/event*}} and your Xorg should add it automatically if you did not disable such feature.</div>Asdil12https://wiki.archlinux.org/index.php?title=OpenVPN&diff=276677OpenVPN2013-09-26T15:09:27Z<p>Asdil12: /* DNS */ mark openvpn interfaces as private - not use the vpn nameserver for non-vpn domains</p>
<hr />
<div>[[Category:Virtual Private Network]]<br />
[[de:OpenVPN]]<br />
[[zh-CN:OpenVPN]]<br />
{{Expansion|(at least) add support for ipv6 and L2 ethernet bridging}}<br />
<br />
This article describes a basic installation and configuration of [http://openvpn.net OpenVPN], suitable for private and small business use. For more detailed information, please see the official [http://openvpn.net/index.php/manuals/427-openvpn-22.html OpenVPN 2.2 man page] and the [http://openvpn.net/index.php/open-source/documentation OpenVPN documentation].<br />
<br />
OpenVPN is a robust and highly flexible [[Wikipedia:VPN|VPN]] daemon. OpenVPN supports [[Wikipedia:SSL/TLS|SSL/TLS]] security, [[Wikipedia:Bridging_(networking)|ethernet bridging]], [[Wikipedia:Transmission_Control_Protocol|TCP]] or [[Wikipedia:User_Datagram_Protocol|UDP]] [[Wikipedia:Tunneling_protocol|tunnel transport]] through [[Wikipedia:Proxy_server|proxies]] or [[Wikipedia:Network address translation|NAT]], support for dynamic IP addresses and [[Wikipedia:Dynamic_Host_Configuration_Protocol|DHCP]], scalability to hundreds or thousands of users, and portability to most major OS platforms.<br />
<br />
OpenVPN is tightly bound to the [http://www.openssl.org OpenSSL] library, and derives much of its crypto capabilities from it.<br />
<br />
OpenVPN supports conventional encryption using a [[Wikipedia:Pre-shared_key|pre-shared secret key]] (Static Key mode) or [[Wikipedia:Public_key|public key security]] ([[Wikipedia:SSL/TLS|SSL/TLS]] mode) using client & server certificates. OpenVPN also supports non-encrypted TCP/UDP tunnels.<br />
<br />
OpenVPN is designed to work with the [[Wikipedia:TUN/TAP|TUN/TAP]] virtual networking interface that exists on most platforms.<br />
<br />
Overall, OpenVPN aims to offer many of the key features of [[Wikipedia:Ipsec|IPSec]] but with a relatively lightweight footprint.<br />
<br />
OpenVPN was written by James Yonan and is published under the [[Wikipedia:GNU General Public License|GNU General Public License (GPL)]].<br />
<br />
== Install OpenVPN ==<br />
<br />
[[pacman|Install]] {{Pkg|openvpn}} from the [[official repositories]].<br />
<br />
{{Note|The software contained in this package supports both server and client mode, so install it on all machines that need to create vpn connections.}}<br />
<br />
== Configure the system for TUN/TAP support ==<br />
<br />
OpenVPN requires TUN/TAP support. Make sure to load at boot the {{ic|tun}} module. <br />
<br />
Read [[Kernel modules]] for more information.<br />
<br />
The default kernel is already properly configured, but if you use another kernel make sure to enable the TUN/TAP module. If {{ic|$ zgrep CONFIG_TUN /proc/config.gz}} returns {{ic|1=CONFIG_TUN=n}}, make the following change to the kernel config file and rebuild the kernel.<br />
<br />
{{hc|Kernel config file|<br />
Device Drivers<br />
--> Network device support<br />
[M] Universal TUN/TAP device driver support}}<br />
<br />
== Connect to a VPN provided by a third party ==<br />
<br />
To connect to a VPN provided by a third party, most of the following can most likely be ignored. Use the certificates and instructions given by your provider, for instance see: [[Airvpn]].<br />
<br />
== Create a Public Key Infrastructure (PKI) from scratch ==<br />
<br />
If you are setting up OpenVPN from scratch, you will need to create a [[Wikipedia:Public key infrastructure|Public Key Infrastructure (PKI)]].<br />
<br />
Create the needed certificates and keys by following: [[Create a Public Key Infrastructure Using the easy-rsa Scripts]].<br />
<br />
The final step of the key creation process is to copy the files needed to the correct machines through a secure channel.<br />
<br />
{{Note|The rest of this article assumes that the keys and certificates are placed in {{ic|/etc/openvpn}}.}}<br />
<br />
The public ca.crt certificate is needed on all servers and clients. The private ca.key key is secret and only needed on the key generating machine.<br />
<br />
A server needs server.crt, and dh2048.pem (public), and server.key and ta.key (private).<br />
<br />
A client needs client.crt (public), and client.key and ta.key (private).<br />
<br />
== A basic L3 IP routing configuration ==<br />
<br />
{{Note|Unless otherwise explicitly stated, the rest of this article assumes this basic configuration.}}<br />
<br />
OpenVPN is an extremely versatile piece of software and many configurations are possible, in fact machines can be both "servers" and "clients", blurring the distinction between server and client.<br />
<br />
What really distinguishes a server from a client (apart from the type of certificate used) is the configuration file itself. The openvpn daemon startup script reads all the .conf configuration files it finds in /etc/openvpn on startup and acts accordingly. In fact if it finds more than one configuration file, it will start one OpenVPN processes per configuration file.<br />
<br />
This article explains how to setup a server called elmer, and a client that connects to it called bugs. More servers and clients can easily be added, by creating more key/certificate pairs and adding more server and client configuration files.<br />
<br />
The OpenVPN package comes with a collection of example configuration files for different purposes. The sample server and client configuration files make an ideal starting point for a basic OpenVPN setup with the following features:<br />
<br />
* Uses [[Wikipedia:Public key infrastructure|Public Key Infrastructure (PKI)]] for authentication.<br />
* Creates a VPN using a virtual TUN network interface (OSI L3 IP routing).<br />
* Listens for client connections on UDP port 1194 (OpenVPN's [[Wikipedia:Port_number|official IANA port number]]).<br />
* Distributes virtual addresses to connecting clients from the 10.8.0.0/24 subnet.<br />
<br />
For more advanced configurations, please see the official [http://openvpn.net/index.php/manuals/427-openvpn-22.html OpenVPN 2.2 man page] and the [http://openvpn.net/index.php/open-source/documentation OpenVPN documentation].<br />
<br />
=== The server configuration file ===<br />
<br />
Copy the example server configuration file to {{ic|/etc/openvpn/server.conf}}:<br />
<br />
# cp /usr/share/openvpn/examples/server.conf /etc/openvpn/server.conf<br />
<br />
Edit the following:<br />
<br />
* The ca, cert, key, and dh parameters to reflect the path and names of the keys and certificates. Specifying the paths will allow you to run the OpenVPN executable from any directory for testing purposes.<br />
* Enable the SSL/TLS HMAC handshake protection. '''Note the use of the parameter 0 for a server'''.<br />
* It is recommended to run OpenVPN with reduced privileges once it has initialized, do this by uncommenting the user and group directives.<br />
<br />
{{hc|/etc/openvpn/server.conf|<br />
ca /etc/openvpn/ca.crt<br />
cert /etc/openvpn/elmer.crt<br />
key /etc/openvpn/elmer.key<br />
<br />
dh /etc/openvpn/dh2048.pem<br />
.<br />
.<br />
tls-auth /etc/openvpn/ta.key '''0'''<br />
.<br />
.<br />
user nobody<br />
group nobody<br />
}}<br />
<br />
{{Note|Note that if the server is behind a firewall or a NAT translating router, you will have to forward the OpenVPN UDP port (1194) to the server.}}<br />
<br />
=== The client configuration file ===<br />
<br />
Copy the example client configuration file to {{ic|/etc/openvpn/client.conf}}:<br />
<br />
# cp /usr/share/openvpn/examples/client.conf /etc/openvpn/client.conf<br />
<br />
Edit the following:<br />
<br />
* The remote directive to reflect either the server's [[Wikipedia:Fully qualified domain name|Fully Qualified Domain Name]] hostname (as known to the client) or its IP address.<br />
* Uncomment the user and group directives to drop privileges.<br />
* The ca, cert, and key parameters to reflect the path and names of the keys and certificates.<br />
* Enable the SSL/TLS HMAC handshake protection. '''Note the use of the parameter 1 for a client'''.<br />
<br />
{{hc|/etc/openvpn/client.conf|<br />
remote elmer.acmecorp.org 1194<br />
.<br />
.<br />
user nobody<br />
group nobody<br />
.<br />
.<br />
ca /etc/openvpn/ca.crt<br />
cert /etc/openvpn/bugs.crt<br />
key /etc/openvpn/bugs.key<br />
.<br />
.<br />
tls-auth /etc/openvpn/ta.key '''1'''<br />
}}<br />
<br />
=== Testing the OpenVPN configuration ===<br />
<br />
Run {{ic|# openvpn /etc/openvpn/server.conf}} on the server, and {{ic|# openvpn /etc/openvpn/client.conf}} on the client. You should see something similar to this:<br />
<br />
{{hc|# openvpn /etc/openvpn/server.conf|2=<br />
Wed Dec 28 14:41:26 2011 OpenVPN 2.2.1 x86_64-unknown-linux-gnu [SSL] [LZO2] [EPOLL] [eurephia] built on Aug 13 2011<br />
Wed Dec 28 14:41:26 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables<br />
Wed Dec 28 14:41:26 2011 Diffie-Hellman initialized with 2048 bit key<br />
.<br />
.<br />
Wed Dec 28 14:41:54 2011 bugs/95.126.136.73:48904 MULTI: primary virtual IP for bugs/95.126.136.73:48904: 10.8.0.6<br />
Wed Dec 28 14:41:57 2011 bugs/95.126.136.73:48904 PUSH: Received control message: 'PUSH_REQUEST'<br />
Wed Dec 28 14:41:57 2011 bugs/95.126.136.73:48904 SENT CONTROL [bugs]: 'PUSH_REPLY,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5' (status=1)<br />
}}<br />
<br />
{{hc|# openvpn /etc/openvpn/client.conf|2=<br />
Wed Dec 28 14:41:50 2011 OpenVPN 2.2.1 i686-pc-linux-gnu [SSL] [LZO2] [EPOLL] [eurephia] built on Aug 13 2011<br />
Wed Dec 28 14:41:50 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables<br />
Wed Dec 28 14:41:50 2011 LZO compression initialized<br />
.<br />
.<br />
Wed Dec 28 14:41:57 2011 GID set to nobody<br />
Wed Dec 28 14:41:57 2011 UID set to nobody<br />
Wed Dec 28 14:41:57 2011 Initialization Sequence Completed<br />
}}<br />
<br />
On the server, find the IP assigned to the tunX device:<br />
<br />
{{hc|# ip addr show|2=<br />
.<br />
.<br />
40: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100<br />
link/none<br />
inet 10.8.0.1 peer 10.8.0.2/32 scope global tun0<br />
}}<br />
<br />
Here we see that the server end of the tunnel has been given the IP address 10.8.0.1.<br />
<br />
Do the same on the client:<br />
<br />
{{hc|# ip addr show|2=<br />
.<br />
.<br />
37: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100<br />
link/none<br />
inet 10.8.0.6 peer 10.8.0.5/32 scope global tun0<br />
}}<br />
<br />
And the client side has been given the IP 10.8.0.6.<br />
<br />
Now try pinging the interfaces.<br />
<br />
On the server:<br />
<br />
{{hc|# ping -c3 10.8.0.6|2=<br />
PING 10.8.0.6 (10.8.0.6) 56(84) bytes of data.<br />
64 bytes from 10.8.0.6: icmp_req=1 ttl=64 time=238 ms<br />
64 bytes from 10.8.0.6: icmp_req=2 ttl=64 time=237 ms<br />
64 bytes from 10.8.0.6: icmp_req=3 ttl=64 time=205 ms<br />
<br />
--- 10.8.0.6 ping statistics ---<br />
3 packets transmitted, 3 received, 0% packet loss, time 2002ms<br />
rtt min/avg/max/mdev = 205.862/227.266/238.788/15.160 ms<br />
}}<br />
<br />
On the client:<br />
<br />
{{hc|# ping -c3 10.8.0.1|2=<br />
PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data.<br />
64 bytes from 10.8.0.1: icmp_req=1 ttl=64 time=158 ms<br />
64 bytes from 10.8.0.1: icmp_req=2 ttl=64 time=158 ms<br />
64 bytes from 10.8.0.1: icmp_req=3 ttl=64 time=157 ms<br />
<br />
--- 10.8.0.1 ping statistics ---<br />
3 packets transmitted, 3 received, 0% packet loss, time 2001ms<br />
rtt min/avg/max/mdev = 157.426/158.278/158.940/0.711 ms<br />
}}<br />
<br />
You now have a working OpenVPN installation, and your client (bugs) will be able to use services on the server (elmer), and vice versa.<br />
<br />
{{Note|If using a firewall, make sure that ip packets on the TUN device are not blocked.}}<br />
<br />
=== Configure the MTU with Fragment and MSS ===<br />
<br />
{{Note|If you do not configure MTU then you will notice that small packets like ping and DNS will work, however web browsing will not work.}}<br />
<br />
Now it is time to configure the maximum segment size (MSS). In order to do this we need to discover what is the smallest MTU along the path between the client and server. In order to do this you can ping the server and disable fragmentation. Then specify the max packetsize.<br />
<br />
{{hc|# ping -c5 -M do -s 1500 elmer.acmecorp.org|2=<br />
PING elmer.acmecorp.org (99.88.77.66) 1500(1528) bytes of data.<br />
From 1.2.3.4 (99.88.77.66) icmp_seq=1 Frag needed and DF set (mtu = 576)<br />
From 1.2.3.4 (99.88.77.66) icmp_seq=1 Frag needed and DF set (mtu = 576)<br />
From 1.2.3.4 (99.88.77.66) icmp_seq=1 Frag needed and DF set (mtu = 576)<br />
From 1.2.3.4 (99.88.77.66) icmp_seq=1 Frag needed and DF set (mtu = 576)<br />
From 1.2.3.4 (99.88.77.66) icmp_seq=1 Frag needed and DF set (mtu = 576)<br />
<br />
--- core.myrelay.net ping statistics ---<br />
0 packets transmitted, 0 received, +5 errors<br />
}}<br />
<br />
We received an ICMP message telling us the MTU is 576 bytes. The means we need to fragment the UDP packets smaller then 576 bytes to allow for some UDP overhead.<br />
<br />
{{hc|# ping -c5 -M do -s 548 elmer.acmecorp.org|2=<br />
PING elmer.acmecorp.org (99.88.77.66) 548(576) bytes of data.<br />
556 bytes from 99.88.77.66: icmp_seq=1 ttl=48 time=206 ms<br />
556 bytes from 99.88.77.66: icmp_seq=2 ttl=48 time=224 ms<br />
556 bytes from 99.88.77.66: icmp_seq=3 ttl=48 time=206 ms<br />
556 bytes from 99.88.77.66: icmp_seq=4 ttl=48 time=207 ms<br />
556 bytes from 99.88.77.66: icmp_seq=5 ttl=48 time=208 ms<br />
<br />
--- myrelay.net ping statistics ---<br />
5 packets transmitted, 5 received, 0% packet loss, time 4001ms<br />
rtt min/avg/max/mdev = 206.027/210.603/224.158/6.832 ms<br />
}}<br />
<br />
After some trial and error..., we discover that we need to fragment packets on 548 bytes. In order to do this we specify this fragment size in the configuration and instruct OpenVPN to fix the Maximum Segment Size (MSS).<br />
<br />
{{hc|/etc/openvpn/client.conf|<br />
remote elmer.acmecorp.org 1194<br />
.<br />
.<br />
fragment 548<br />
mssfix<br />
.<br />
.<br />
user nobody<br />
group nobody<br />
.<br />
.<br />
ca /etc/openvpn/ca.crt<br />
cert /etc/openvpn/bugs.crt<br />
key /etc/openvpn/bugs.key<br />
.<br />
.<br />
tls-auth /etc/openvpn/ta.key '''1'''<br />
}}<br />
<br />
<br />
{{Note|This will add about 3min's to OpenVPN start time. It is advisable to configure the fragment size unless your client is a laptop that will be connecting over many different networks and the bottle neck is on the client side.}}<br />
<br />
You can also allow OpenVPN to do this for you by having OpenVPN do the ping testing every time the client connects to the VPN.<br />
{{hc|/etc/openvpn/client.conf|<br />
remote elmer.acmecorp.org 1194<br />
.<br />
.<br />
mtu-test<br />
.<br />
.<br />
user nobody<br />
group nobody<br />
.<br />
.<br />
ca /etc/openvpn/ca.crt<br />
cert /etc/openvpn/bugs.crt<br />
key /etc/openvpn/bugs.key<br />
.<br />
.<br />
tls-auth /etc/openvpn/ta.key '''1'''<br />
}}<br />
<br />
== Starting OpenVPN ==<br />
<br />
=== Manual startup ===<br />
<br />
To troubleshoot a vpn connection, start the daemon manually with: {{ic|# openvpn /etc/openvpn/client.conf}}.<br />
<br />
=== Systemd service configuration ===<br />
<br />
To start openvpn automatically at system boot, [[Daemon|enable]] {{ic|openvpn@''<configuration>''.service}}.<br />
<br />
For example, if the configuration file is {{ic|/etc/openvpn/client.conf}}, the service name is {{ic|openvpn@client.service}}.<br />
<br />
== Advanced L3 IP routing==<br />
<br />
=== Prerequisites for routing a LAN ===<br />
<br />
==== IPv4 forwarding ====<br />
<br />
For a host to be able to forward IPv4 packets between the LAN and VPN, it must be able to forward the packets between its NIC and its tun/tap device.<br />
<br />
Edit {{ic|etc/sysctl.conf}} to permanently enable ipv4 packet forwarding (takes effect at the next boot):<br />
<br />
{{hc|/etc/sysctl.conf|2=<br />
# Enable packet forwarding<br />
net.ipv4.ip_forward=1<br />
}}<br />
<br />
To temporarily enable without rebooting: {{ic|# echo 1 > /proc/sys/net/ipv4/ip_forward}}<br />
<br />
==== Promiscuous LAN interface ====<br />
<br />
The forwarding host's NIC (enp1s0 in the following examples) must also be able to accept packets for a different IP address than it is configured for, something known as [[Wikipedia:Promiscuous_mode|promiscious mode]]. To set the {{ic|enp1s0}} in promiscuous mode using systemd use [[ Systemd/Services#Set_network_interface_in_promiscuous_mode | this service file ]] and enable it using:<br />
<br />
# systemctl enable promiscuous@enp1s0.service<br />
<br />
To temporarily enable without rebooting: {{ic|# ip link set dev enp1s0 promisc on}}.<br />
<br />
<br />
==== Routing tables ====<br />
<br />
{{Accuracy|Investigate if a routing protocol like RIP, QUAGGA, BIRD, etc can be used}}<br />
<br />
By default, all IP packets on a LAN addressed to a different subnet get sent to the default gateway. If the LAN/VPN gateway is also the default gateway, there is no problem and the packets get properly forwarded. If not, the gateway has no way of knowing where to send the packets. There are a couple of solutions to this problem.<br />
<br />
* Add a static route to the default gateway routing the VPN subnet to the LAN/VPN gateway's IP address.<br />
* Add a static route on each host on the LAN that needs to send IP packets back to the VPN.<br />
* Use [[iptables]]' NAT feature on the LAN/VPN gateway to masquerade the incoming VPN IP packets.<br />
<br />
=== Connect the server LAN to a client ===<br />
<br />
The server is on a LAN using the 10.66.0.0/24 subnet. To inform the client about the available subnet, add a push directive to the server configuration file:{{hc|/etc/openvpn/server.conf|push "route 10.66.0.0 255.255.255.0"}}<br />
<br />
{{Note|<br />
* Remember to enable ipv4 forwarding and to make the LAN interface promiscuous on the server. Make sure the server LAN knows how to reach the VPN client.<br />
* To route more LANs from the server to the client, add more push directives to the server configuration file, but keep in mind that the server side LANs will need to know how to route to the client.<br />
}}<br />
<br />
=== Connect the client LAN to a server ===<br />
<br />
Prerequisites:<br />
<br />
* Any subnets used on the client side, must be unique and not in use on the server or by any other client. In this example we will use 192.168.4.0/24 for the clients LAN.<br />
* Each client's certificate has a unique Common Name, in this case bugs.<br />
* The server may not use the duplicate-cn directive in its config file.<br />
<br />
Create a client configuration directory on the server. It will be searched for a file named the same as the client's common name, and the directives will be applied to the client when it connects.<br />
<br />
# mkdir -p /etc/openvpn/ccd<br />
<br />
Create a file in the client configuration directory called bugs, containing the {{ic|iroute 192.168.4.0 255.255.255.0}} directive. It tells the server what subnet should be routed to the client:<br />
<br />
{{hc|/etc/openvpn/ccd/bugs|iroute 192.168.4.0 255.255.255.0}}<br />
<br />
Add the client-config-dir and the {{ic|route 192.168.4.0 255.255.255.0}} directive to the server configuration file. It tells the server what subnet should be routed from the tun device to the server LAN:<br />
<br />
{{hc|/etc/openvpn/server.conf|<br />
client-config-dir ccd<br />
route 192.168.4.0 255.255.255.0<br />
}}<br />
<br />
{{Note|<br />
* Remember to enable ipv4 forwarding and to make the LAN interface promiscuous on the client. Make sure the client LAN knows how to reach the VPN server.<br />
* To route more LANs from the client to the server, add more iroute and route directives to the appropriate configuration files, but keep in mind that the client side LANs will need to know how to route to the server.<br />
}}<br />
<br />
=== Connect both the client and server LANs ===<br />
<br />
Combine the two previous sections:<br />
<br />
{{hc|/etc/openvpn/server.conf|<br />
push "route 10.66.0.0 255.255.255.0"<br />
.<br />
.<br />
client-config-dir ccd<br />
route 192.168.4.0 255.255.255.0<br />
}}<br />
<br />
{{hc|/etc/openvpn/ccd/bugs|iroute 192.168.4.0 255.255.255.0}}<br />
<br />
{{Note|Remember to enable ipv4 forwarding and to make the LAN interfaces promiscuous on both the client and the server. Make sure that all the LANs or the needed hosts can route to all the destinations.}}<br />
<br />
=== Connect clients and client LANs ===<br />
<br />
By default clients will not see each other, to allow ip packets to flow between clients and/or client LANs add a client-to-client directive to the server configuration file: {{hc|/etc/openvpn/server.conf|client-to-client}}<br />
<br />
In order for another client or client LAN to see a specific client LAN you will need to add a push directive for each client subnet to the server configuration file (this will make the server announce the available subnet(s) to other clients):<br />
<br />
{{hc|/etc/openvpn/server.conf|<br />
client-to-client<br />
push "route 192.168.4.0 255.255.255.0"<br />
push "route 192.168.5.0 255.255.255.0"<br />
.<br />
.<br />
}}<br />
<br />
{{Note|As always, make sure that the routing is properly configured.}}<br />
<br />
== L2 Ethernet bridging ==<br />
<br />
{{Expansion|Please add a well thought out section on L2 bridging.}}<br />
<br />
For now see: [[OpenVPN Bridge]]<br />
<br />
== Contributions that do not yet fit into the main article ==<br />
<br />
{{Accuracy|Not quite sure where this fits into the main article yet}}<br />
<br />
=== Routing client traffic through the server ===<br />
<br />
Append the following to your server's openvpn.conf configuration file:<br />
<br />
push "redirect-gateway def1"<br />
push "dhcp-option DNS 192.168.1.1"<br />
<br />
Change "192.168.1.1" to your preferred DNS IP address.<br />
<br />
If you have problems with non responsive DNS after connecting to server, install [[BIND]] as simple DNS forwarder and push openvpn ip address of server as DNS to clients.<br />
<br />
==== Configure ufw for routing ====<br />
<br />
Configure your ufw settings to enable routing traffic from clients through server.<br />
<br />
You must change default forward policy, edit /etc/sysctl.conf to permanently enable ipv4 packet forwarding. Takes effect at the next boot.<br />
{{hc|/etc/sysctl.conf|2=<br />
# Enable packet forwarding<br />
net.ipv4.ip_forward=1<br />
}} <br />
<br />
And then configure ufw in {{ic|/etc/default/ufw}}:<br />
<br />
{{hc|/etc/default/ufw|2=<br />
DEFAULT_FORWARD_POLICY="ACCEPT"<br />
}}<br />
<br />
Now change {{ic|/etc/ufw/before.rules}}, and add the following code after the header and before the "*filter" line. Don't forget to change the IP/subnet mask to match the one in {{ic|/etc/openvpn/server.conf}}.<br />
<br />
{{hc|/etc/ufw/before.rules|2=<br />
# NAT (Network Address Translation) table rules<br />
*nat<br />
:POSTROUTING ACCEPT [0:0]<br />
<br />
# Allow traffic from clients to enp1s0<br />
-A POSTROUTING -s 10.8.0.0/8 -o enp1s0 -j MASQUERADE<br />
<br />
# don't delete the "COMMIT" line or the NAT table rules above won't be processed<br />
COMMIT<br />
}}<br />
<br />
Open openvpn port 1194:<br />
<br />
ufw allow 1194<br />
<br />
==== Using iptables ====<br />
<br />
Use an iptable for NAT forwarding:<br />
<br />
echo 1 > /proc/sys/net/ipv4/ip_forward<br />
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o enp1s0 -j MASQUERADE<br />
<br />
If running Arch Linux in a OpenVZ VPS environment [http://thecodeninja.net/linux/openvpn-archlinux-openvz-vps/]:<br />
<br />
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o venet0 -j SNAT --to (venet0 ip)<br />
<br />
If all is well, make the changes permanent:<br />
<br />
Edit {{ic|/etc/conf.d/iptables}} and change IPTABLES_FORWARD=1<br />
<br />
# iptables-save > /etc/iptables/iptables.rules<br />
<br />
=== Configuring LDAP authorization ===<br />
<br />
{{Accuracy|what does the following do, and is the package still supported?}}<br />
You may also want to install {{AUR|openvpn-authldap-plugin}}, available in the [[AUR]].<br />
<br />
=== Deprecated older wiki content ===<br />
<br />
{{Accuracy|See how this older content can be fitted into the new article}}<br />
<br />
====Using PAM and passwords to authenticate====<br />
<br />
{{bc|<br />
port 1194<br />
proto udp<br />
mtu-test<br />
dev tap<br />
ca /etc/openvpn/easy-rsa/keys/ca.crt<br />
cert /etc/openvpn/easy-rsa/keys/<MYSERVER>.crt<br />
key /etc/openvpn/easy-rsa/keys/<MYSERVER>.key<br />
dh /etc/openvpn/easy-rsa/keys/dh2048.pem<br />
server 192.168.56.0 255.255.255.0<br />
ifconfig-pool-persist ipp.txt<br />
;learn-address ./script<br />
client-to-client<br />
;duplicate-cn<br />
keepalive 10 120<br />
;tls-auth ta.key 0<br />
comp-lzo<br />
;max-clients 100<br />
;user nobody<br />
;group nobody<br />
persist-key<br />
persist-tun<br />
status /var/log/openvpn-status.log<br />
verb 3<br />
client-cert-not-required<br />
username-as-common-name<br />
plugin /usr/lib/openvpn/plugins/openvpn-plugin-auth-pam.so login<br />
}}<br />
<br />
==== Using certs to authenticate ====<br />
<br />
{{bc|<br />
port 1194<br />
proto tcp<br />
dev tun0<br />
<br />
ca /etc/openvpn/easy-rsa/keys/ca.crt<br />
cert /etc/openvpn/easy-rsa/keys/<MYSERVER>.crt<br />
key /etc/openvpn/easy-rsa/keys/<MYSERVER>.key<br />
dh /etc/openvpn/easy-rsa/keys/dh2048.pem<br />
<br />
server 10.8.0.0 255.255.255.0<br />
ifconfig-pool-persist ipp.txt<br />
keepalive 10 120<br />
comp-lzo<br />
user nobody<br />
group nobody<br />
persist-key<br />
persist-tun<br />
status /var/log/openvpn-status.log<br />
verb 3<br />
<br />
log-append /var/log/openvpn<br />
status /tmp/vpn.status 10<br />
}}<br />
<br />
==== Routing traffic through the server ====<br />
<br />
Append the following to your server's openvpn.conf configuration file:<br />
<br />
push "dhcp-option DNS 192.168.1.1"<br />
push "redirect-gateway def1"<br />
<br />
Change "192.168.1.1" to your external DNS IP address.<br />
<br />
Use an iptable for NAT forwarding:<br />
<br />
echo 1 > /proc/sys/net/ipv4/ip_forward<br />
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o enp1s0 -j MASQUERADE<br />
<br />
If running ArchLinux in a OpenVZ VPS environment [http://thecodeninja.net/linux/openvpn-archlinux-openvz-vps/]:<br />
<br />
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o venet0 -j SNAT --to (venet0 ip)<br />
<br />
If all is well, make the changes permanent:<br />
<br />
Edit {{ic|/etc/conf.d/iptables}} and change IPTABLES_FORWARD=1<br />
<br />
# iptables-save > /etc/iptables/iptables.rules<br />
<br />
==== Setting up the client ====<br />
<br />
The clientside .conf file<br />
<br />
===== With password authentication =====<br />
<br />
{{bc|<br />
client<br />
dev tap<br />
proto udp<br />
mtu-test<br />
remote <address> 1194<br />
resolv-retry infinite<br />
nobind<br />
persist-tun<br />
comp-lzo<br />
verb 3<br />
auth-user-pass passwd<br />
ca ca.crt<br />
}}<br />
<br />
passwd file (referenced by auth-user-pass) must contain two lines:<br />
* first line - username<br />
* second - password<br />
<br />
===== Certificates authentication =====<br />
<br />
{{bc|<br />
client<br />
remote <MYSERVER> 1194<br />
dev tun0<br />
proto tcp<br />
resolv-retry infinite<br />
nobind<br />
persist-key<br />
persist-tun<br />
verb 2<br />
ca ca.crt<br />
cert client1.crt<br />
key client1.key<br />
comp-lzo<br />
}}<br />
Copy three files from server to remote computer.<br />
ca.crt<br />
client1.crt<br />
client1.key<br />
<br />
Install the tunnel/tap module:<br />
<br />
# modprobe tun<br />
<br />
To have the '''tun''' module loaded automatically at boot time add it to the Modules line in /etc/rc.conf<br />
<br />
===== DNS =====<br />
<br />
The DNS servers used by the system are defined in {{ic|/etc/resolv.conf}}. Traditionally, this file is the responsibility of whichever program deals with connecting the system to the network (e.g. Wicd, NetworkManager, etc...) However, OpenVPN will need to modify this file if you want to be able to resolve names on the remote side. To achieve this in a sensible way, install '''openresolv''', which makes it possible for more than one program to modify resolv.conf without stepping on each-other's toes. Before continuing, test openresolv by restarting your network connection and ensuring that resolv.conf states that it was generated by "resolvconf", and that your DNS resolution still works as before. You should not need to configure openresolv; it should be automatically detected and used by your network system.<br />
<br />
Next, save the following script at {{ic|/usr/share/openvpn/update-resolv-conf}}:<br />
{{bc|<nowiki><br />
#!/bin/bash<br />
#<br />
# Parses DHCP options from openvpn to update resolv.conf<br />
# To use set as 'up' and 'down' script in your openvpn *.conf:<br />
# up /etc/openvpn/update-resolv-conf<br />
# down /etc/openvpn/update-resolv-conf<br />
#<br />
# Used snippets of resolvconf script by Thomas Hood <jdthood@yahoo.co.uk><br />
# and Chris Hanson<br />
# Licensed under the GNU GPL. See /usr/share/common-licenses/GPL.<br />
# 07/2013 colin@daedrum.net Fixed intet name<br />
# 05/2006 chlauber@bnc.ch<br />
#<br />
# Example envs set from openvpn:<br />
# foreign_option_1='dhcp-option DNS 193.43.27.132'<br />
# foreign_option_2='dhcp-option DNS 193.43.27.133'<br />
# foreign_option_3='dhcp-option DOMAIN be.bnc.ch'<br />
<br />
[ -x $(which resolvconf) ] || exit 0<br />
<br />
case $script_type in<br />
<br />
up)<br />
for optionname in ${!foreign_option_*} ; do<br />
option="${!optionname}"<br />
echo $option<br />
part1=$(echo "$option" | cut -d " " -f 1)<br />
if [ "$part1" == "dhcp-option" ] ; then<br />
part2=$(echo "$option" | cut -d " " -f 2)<br />
part3=$(echo "$option" | cut -d " " -f 3)<br />
if [ "$part2" == "DNS" ] ; then<br />
IF_DNS_NAMESERVERS="$IF_DNS_NAMESERVERS $part3"<br />
fi<br />
if [ "$part2" == "DOMAIN" ] ; then<br />
IF_DNS_SEARCH="$IF_DNS_SEARCH $part3"<br />
fi<br />
fi<br />
done<br />
R=""<br />
if [ "$IF_DNS_SEARCH" ] ; then<br />
R="${R}search $IF_DNS_SEARCH<br />
"<br />
fi<br />
for NS in $IF_DNS_NAMESERVERS ; do<br />
R="${R}nameserver $NS<br />
"<br />
done<br />
echo -n "$R" | resolvconf -p -a "${dev}"<br />
;;<br />
down)<br />
resolvconf -d "${dev}"<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
Remember to make the file executable with:<br />
$ chmod +x /usr/share/openvpn/update-resolv-conf<br />
Next, add the following lines to your OpenVPN client configuration file:<br />
<br />
script-security 2<br />
up /usr/share/openvpn/update-resolv-conf<br />
down /usr/share/openvpn/update-resolv-conf<br />
<br />
Now, when your launch your OpenVPN connection, you should find that your resolv.conf file is updated accordingly, and also returns to normal when your close the connection.<br />
<br />
===== Webmin =====<br />
<br />
{{AUR|webmin-plugin-openvpn}} is available in the [[AUR]].<br />
{{Note|You must add "openvpn" to the end of /etc/webmin/webmin.acl.}}<br />
<br />
==== Connecting to the server ====<br />
<br />
You need to start the service on the server<br />
<br />
/etc/rc.d/openvpn start<br />
<br />
You can add it to rc.conf to make it permanent.<br />
<br />
On the client, in the home directory create a folder that will hold your OpenVPN client config files along with the '''.crt'''/'''.key''' files. Assuming your OpenVPN config folder is called '''.openvpn''' and your client config file is '''vpn1.conf''', to connect to the server issue the following command:<br />
<br />
# cd ~/.openvpn && openvpn vpn1.conf</div>Asdil12https://wiki.archlinux.org/index.php?title=DeveloperWiki:Automated_Package_Build_System&diff=276495DeveloperWiki:Automated Package Build System2013-09-24T09:37:08Z<p>Asdil12: fix list</p>
<hr />
<div>[[Category:Package development]]<br />
== What is an Automated Build System ==<br />
One of the best examples of an automated package build systems is the Fedora Koji project, Koji is a continuous build system for all of the rpms in the Fedora and RHEL projects. The main benefit of an automated build system is that all of the packages need to pass through a common gate, a common checkpoint for quality and consistency.<br />
<br />
While the Koji build server is referenced heavily the Arch equivalent will need to be very different, in both architecture and the general goals of the project.<br />
<br />
== Naming ==<br />
The proposed name for the Arch package build system is Quarters, the logic being that what really feeds pacman is quarters.<br />
<br />
Alternative naming options will be considered<br />
<br />
== Design Proposal ==<br />
One of the main aspects of the Arch distribution compared to distributions like Fedora is money. The Fedora project can go out and buy servers by the arm full, but Arch will need to continue to rely on volunteer equipment and working with what we can get our hands on. While these aspects will effect the nature of the package build system, they cannot allow for the compromise of the quality of the Arch Linux distribution.<br />
<br />
=== Proposed Features ===<br />
<br />
# Simplicity<br />
## Avoid requiring too many daemons<br />
## No Authentication systems<br />
## No database dependencies<br />
## Simple https communication<br />
## Able to interact with distributed components over any reasonable link quality<br />
# Distributed<br />
## Need to be able to distribute the build load to systems all over the world<br />
## All communication needs to be encrypted (duh)<br />
## Builders make decisions by peer review<br />
# Data Model<br />
## Information on the available packages is made by parsing live pacman data (pacman is fast enough)<br />
## Packages to build is presented to the builders via serialized format (probably json)<br />
# Communication<br />
## All build communication is based on gathering presented data, all pulls, not puts<br />
## All servers are state machines, the status of the distributed build environment is assessed by parsing the "global" state machine<br />
## Command system to move packages manually from the build repos to the final repos<br />
# Build Cleanliness<br />
## Every package is built in its own clean chroot environment<br />
# Packages can be pulled and polled from many sources<br />
## SVN<br />
## AUR (plugable?)<br />
## GIT<br />
## Other scms ()<br />
## Web interface<br />
# Building Requirements<br />
## All packages need to be build-able, this includes the base toolchain<br />
## Trigger mass rebuilds of package, with version bumps<br />
## Track Packager data through the build process, do not allow the packager to be lost to the builder<br />
# System Interaction points<br />
## Detached cli interface sends signals to the master<br />
## Master server reads signals and acts on them<br />
<br />
== Programming Language ==<br />
It has been proposed that the application be developed in Python. Python is fast enough, has the libs we need, and who doesn't understand python?<br />
<br />
Sorry, but this project is too big for bash, and bash is too slow.<br />
<br />
I thought about OCaml, but I figured that it should be something that everyone can hack on.<br />
<br />
Try and go for python3<br />
<br />
== Builder Process ==<br />
The process that the builders will use is based on state information, the master server presents the master state, which is the list validated builders and the packages to be built; Only packages which have met all deps and makeedeps in binary repos will be presented. The master server will only present packages which are ready to be built. The builders then download the master server's state information. The builders pick package(s) to build, post the package that they have claimed and then query the other builders to see if any other builder has claimed it. If the builder needs to change the package to build then it will just post a claim on a new package. Unless it is the first build on the builder then the peer process of determining which package needs to be built will be done while a package is already being built.<br />
<br />
The master will regularly poll the states of the builders, the builders will post their states for the master and for the peers. The builder states will have all the information that the master needs to retrieve the built packages or the information for the failed build.<br />
<br />
==Component Build Out==<br />
Quarters will consist of a number of individual components. These components are all pieces of the distributed system, the components will also interact via a common language independent medium and https.<br />
<br />
=== Master Server Components ===<br />
The components required for the operation of the master server<br />
<br />
==== Core Loop ====<br />
The core loop or the core of the master does what most daemons do, takes in the config information, does the double pid form magic, etc.<br />
<br />
The core loop will primarily act by continually querying the distributed components for changes, thee components are the builders and the package parsers.<br />
<br />
==== Determine Packages Which are Ready to be Built ====<br />
The master will need to query the pacman repositories available, primarily the live repositories and the build repository. The names and versions of all available packages will be queried, then presented as a dictionary: {<packages name>: <version>}. This information is then compared to the information returned by the SCMS, then compiling a list of packages that need to be built is a simple task.<br />
<br />
==== Maintain Package Repositories ====<br />
A number of package repos will need to be maintained, a build repo will be maintained which simply contains all of the build packages, this is not to be a public repo, but is used by the builders to meed build dependencies.<br />
<br />
Once a package has been signed off it can be moved from the build repo to the live repo with a command. The command will ensure that the package that is entering the live repository has all deps met. If the package that is being moved to a live repository does not have all deps met the dependent packages will be presented for the move as well.<br />
<br />
This method satisfies both automatic building from scms and maintaining the manual process of moving packages into the live repos.<br />
<br />
==== Package Parsers ====<br />
The package parsers will be pluggable modules that return predictable data about the state of source package data stored in either a source control manager or an interface such as the abs or the AUR.<br />
<br />
The idea here is that as long as the data queried from the source is uniform there can be any number of usable interfaces. The primary system will need to be svn, since this is what the main package tree is stored in, then git and then an AUR parser. More interfaces can be added on later if we or anyone else wants them.<br />
<br />
All parsers need to return a similar data structure and may need to do some package preparation. The data structure will need to be defined and static, but it should just be a python dict, something json likes.<br />
<br />
===== SVN Parser =====<br />
This is the main package parser, the parser needs to be able to ready the PKGBUILDS for specific info, particularly pkgver, pkgname and pkgrel, then compare the values to the list of packages that are already built.<br />
Once the packages that need updating have been found the parser needs to return a data structure containing the packages that need to be built.<br />
The main challenge here is figuring out the fastest way to parse an SVN repo, they can be somewhat slow.<br />
<br />
==== Package Manipulators ====<br />
For full functionality most parsers will need companion manipulators, these are interfaces that can manipulate the PKGBUILDS in the underlying SCM. This is needed for mass rebuilds, so that certain packages can trigger deps to auto increment in the SCM. Once the PKGBUILDS have been auto incremented then they will be picked up for rebuilding.<br />
<br />
=== Build Server Components ===<br />
The build server will run on a host of different nodes. The build server needs to have a number of capabilities. Primarily it will need ample disk space to maintain multiple chroot environments as well as have enough ram and free cpu power.<br />
<br />
==== Master Queries ====<br />
The Build Server will need to be able to continually get a fresh state from the master.<br />
<br />
==== Peer Review System ====<br />
The builders will need to be able to download the build state from all of the peer builders. The list of builders will be provided by the master.<br />
<br />
After download the builder will need to analyze the state of the other builders and determine what package(s) that this builder should claim. The builder should always have package names ready, so long as packages are being presented by the master.<br />
<br />
I am still debating on this, I might have the master just present packages for the builders, but I still think that a peer system might be better.<br />
<br />
==== Main Loop ====<br />
The builder will need to maintain a single top level loop that controls all of the builder processes and continually queries the master and executes peer reviews.<br />
<br />
==== Chroot Builders ====<br />
The main loop will be able to spawn the configured number of chroot builders at the same time. These builders need to be maintained, inasmuch that the number of available packages to build needs to be kept ahead of the builders.<br />
<br />
=== Builder Considerations ===<br />
The builders will need to support many simultaneous chroots. A savvy admin for instance could use tmpfs file systems or ssd cards to maintain more and higher speed chroots. So the number of simultaneous package builders needs to be configurable with no limit. Disk IO will be the holding factor for many builds, since fresh chroot copies and updates need to be performed frequently.<br />
<br />
==== Threading ====<br />
When spawning a package builder, the python threading module cannot be used, Quarters as a whole will require multiple processes to operate properly. The threading module, and subsequently the python GIL should be avoided. Instead the multiprocessing module should be used.<br />
<br />
==== Builder Security ====<br />
While unexpected, the builders need to be protected from malicious code intended to compromise the system. When chroots are constructed the top chroot dir needs to have the barrier attribute test with setattr. Also the builds should be run as an unprivileged user inside the chroot. These precautions will defend against the two main ways to break a chroot, pwd manipulation and dev node hijacking.<br />
<br />
=== Standalone Components ===<br />
These components are used by multiple services<br />
<br />
==== Https Server ====<br />
Each component will need to be able to present files via an https server. The package will require a standalone https server written in python.<br />
<br />
Quarters will also need to be able to allow for any http server to be used if the admin choses to use something other than the python https server<br />
<br />
==== Pacman Module ====<br />
Nearly all components will need to interact with pacman, he last I checked there we problems with the python bindings for alpm, if I am mistaken, I am all ears.<br />
<br />
Some standard functions with respect to pacman will need to be made available.<br />
<br />
==== PKGBUILD Parser ====<br />
I know, this is a bottomless pit, the requirements for the PKGBUILD parser are not extensive, although a number of parameters will need to be reliably extracted.<br />
<br />
==== Standard Utils Module====<br />
That anoying module that sets up logging and other more globally needed functions.<br />
<br />
<br />
----<br />
Links:<br />
<br />
* https://github.com/asdil12/aurbs - An automated build system for the AUR, written in python3 - added for code reference<br />
* https://github.com/archlinuxarm/plugbuild - An automated distributed build system used to build archlinux-arm, written in perl</div>Asdil12https://wiki.archlinux.org/index.php?title=DeveloperWiki:Automated_Package_Build_System&diff=276494DeveloperWiki:Automated Package Build System2013-09-24T09:36:22Z<p>Asdil12: add plugbuild link</p>
<hr />
<div>[[Category:Package development]]<br />
== What is an Automated Build System ==<br />
One of the best examples of an automated package build systems is the Fedora Koji project, Koji is a continuous build system for all of the rpms in the Fedora and RHEL projects. The main benefit of an automated build system is that all of the packages need to pass through a common gate, a common checkpoint for quality and consistency.<br />
<br />
While the Koji build server is referenced heavily the Arch equivalent will need to be very different, in both architecture and the general goals of the project.<br />
<br />
== Naming ==<br />
The proposed name for the Arch package build system is Quarters, the logic being that what really feeds pacman is quarters.<br />
<br />
Alternative naming options will be considered<br />
<br />
== Design Proposal ==<br />
One of the main aspects of the Arch distribution compared to distributions like Fedora is money. The Fedora project can go out and buy servers by the arm full, but Arch will need to continue to rely on volunteer equipment and working with what we can get our hands on. While these aspects will effect the nature of the package build system, they cannot allow for the compromise of the quality of the Arch Linux distribution.<br />
<br />
=== Proposed Features ===<br />
<br />
# Simplicity<br />
## Avoid requiring too many daemons<br />
## No Authentication systems<br />
## No database dependencies<br />
## Simple https communication<br />
## Able to interact with distributed components over any reasonable link quality<br />
# Distributed<br />
## Need to be able to distribute the build load to systems all over the world<br />
## All communication needs to be encrypted (duh)<br />
## Builders make decisions by peer review<br />
# Data Model<br />
## Information on the available packages is made by parsing live pacman data (pacman is fast enough)<br />
## Packages to build is presented to the builders via serialized format (probably json)<br />
# Communication<br />
## All build communication is based on gathering presented data, all pulls, not puts<br />
## All servers are state machines, the status of the distributed build environment is assessed by parsing the "global" state machine<br />
## Command system to move packages manually from the build repos to the final repos<br />
# Build Cleanliness<br />
## Every package is built in its own clean chroot environment<br />
# Packages can be pulled and polled from many sources<br />
## SVN<br />
## AUR (plugable?)<br />
## GIT<br />
## Other scms ()<br />
## Web interface<br />
# Building Requirements<br />
## All packages need to be build-able, this includes the base toolchain<br />
## Trigger mass rebuilds of package, with version bumps<br />
## Track Packager data through the build process, do not allow the packager to be lost to the builder<br />
# System Interaction points<br />
## Detached cli interface sends signals to the master<br />
## Master server reads signals and acts on them<br />
<br />
== Programming Language ==<br />
It has been proposed that the application be developed in Python. Python is fast enough, has the libs we need, and who doesn't understand python?<br />
<br />
Sorry, but this project is too big for bash, and bash is too slow.<br />
<br />
I thought about OCaml, but I figured that it should be something that everyone can hack on.<br />
<br />
Try and go for python3<br />
<br />
== Builder Process ==<br />
The process that the builders will use is based on state information, the master server presents the master state, which is the list validated builders and the packages to be built; Only packages which have met all deps and makeedeps in binary repos will be presented. The master server will only present packages which are ready to be built. The builders then download the master server's state information. The builders pick package(s) to build, post the package that they have claimed and then query the other builders to see if any other builder has claimed it. If the builder needs to change the package to build then it will just post a claim on a new package. Unless it is the first build on the builder then the peer process of determining which package needs to be built will be done while a package is already being built.<br />
<br />
The master will regularly poll the states of the builders, the builders will post their states for the master and for the peers. The builder states will have all the information that the master needs to retrieve the built packages or the information for the failed build.<br />
<br />
==Component Build Out==<br />
Quarters will consist of a number of individual components. These components are all pieces of the distributed system, the components will also interact via a common language independent medium and https.<br />
<br />
=== Master Server Components ===<br />
The components required for the operation of the master server<br />
<br />
==== Core Loop ====<br />
The core loop or the core of the master does what most daemons do, takes in the config information, does the double pid form magic, etc.<br />
<br />
The core loop will primarily act by continually querying the distributed components for changes, thee components are the builders and the package parsers.<br />
<br />
==== Determine Packages Which are Ready to be Built ====<br />
The master will need to query the pacman repositories available, primarily the live repositories and the build repository. The names and versions of all available packages will be queried, then presented as a dictionary: {<packages name>: <version>}. This information is then compared to the information returned by the SCMS, then compiling a list of packages that need to be built is a simple task.<br />
<br />
==== Maintain Package Repositories ====<br />
A number of package repos will need to be maintained, a build repo will be maintained which simply contains all of the build packages, this is not to be a public repo, but is used by the builders to meed build dependencies.<br />
<br />
Once a package has been signed off it can be moved from the build repo to the live repo with a command. The command will ensure that the package that is entering the live repository has all deps met. If the package that is being moved to a live repository does not have all deps met the dependent packages will be presented for the move as well.<br />
<br />
This method satisfies both automatic building from scms and maintaining the manual process of moving packages into the live repos.<br />
<br />
==== Package Parsers ====<br />
The package parsers will be pluggable modules that return predictable data about the state of source package data stored in either a source control manager or an interface such as the abs or the AUR.<br />
<br />
The idea here is that as long as the data queried from the source is uniform there can be any number of usable interfaces. The primary system will need to be svn, since this is what the main package tree is stored in, then git and then an AUR parser. More interfaces can be added on later if we or anyone else wants them.<br />
<br />
All parsers need to return a similar data structure and may need to do some package preparation. The data structure will need to be defined and static, but it should just be a python dict, something json likes.<br />
<br />
===== SVN Parser =====<br />
This is the main package parser, the parser needs to be able to ready the PKGBUILDS for specific info, particularly pkgver, pkgname and pkgrel, then compare the values to the list of packages that are already built.<br />
Once the packages that need updating have been found the parser needs to return a data structure containing the packages that need to be built.<br />
The main challenge here is figuring out the fastest way to parse an SVN repo, they can be somewhat slow.<br />
<br />
==== Package Manipulators ====<br />
For full functionality most parsers will need companion manipulators, these are interfaces that can manipulate the PKGBUILDS in the underlying SCM. This is needed for mass rebuilds, so that certain packages can trigger deps to auto increment in the SCM. Once the PKGBUILDS have been auto incremented then they will be picked up for rebuilding.<br />
<br />
=== Build Server Components ===<br />
The build server will run on a host of different nodes. The build server needs to have a number of capabilities. Primarily it will need ample disk space to maintain multiple chroot environments as well as have enough ram and free cpu power.<br />
<br />
==== Master Queries ====<br />
The Build Server will need to be able to continually get a fresh state from the master.<br />
<br />
==== Peer Review System ====<br />
The builders will need to be able to download the build state from all of the peer builders. The list of builders will be provided by the master.<br />
<br />
After download the builder will need to analyze the state of the other builders and determine what package(s) that this builder should claim. The builder should always have package names ready, so long as packages are being presented by the master.<br />
<br />
I am still debating on this, I might have the master just present packages for the builders, but I still think that a peer system might be better.<br />
<br />
==== Main Loop ====<br />
The builder will need to maintain a single top level loop that controls all of the builder processes and continually queries the master and executes peer reviews.<br />
<br />
==== Chroot Builders ====<br />
The main loop will be able to spawn the configured number of chroot builders at the same time. These builders need to be maintained, inasmuch that the number of available packages to build needs to be kept ahead of the builders.<br />
<br />
=== Builder Considerations ===<br />
The builders will need to support many simultaneous chroots. A savvy admin for instance could use tmpfs file systems or ssd cards to maintain more and higher speed chroots. So the number of simultaneous package builders needs to be configurable with no limit. Disk IO will be the holding factor for many builds, since fresh chroot copies and updates need to be performed frequently.<br />
<br />
==== Threading ====<br />
When spawning a package builder, the python threading module cannot be used, Quarters as a whole will require multiple processes to operate properly. The threading module, and subsequently the python GIL should be avoided. Instead the multiprocessing module should be used.<br />
<br />
==== Builder Security ====<br />
While unexpected, the builders need to be protected from malicious code intended to compromise the system. When chroots are constructed the top chroot dir needs to have the barrier attribute test with setattr. Also the builds should be run as an unprivileged user inside the chroot. These precautions will defend against the two main ways to break a chroot, pwd manipulation and dev node hijacking.<br />
<br />
=== Standalone Components ===<br />
These components are used by multiple services<br />
<br />
==== Https Server ====<br />
Each component will need to be able to present files via an https server. The package will require a standalone https server written in python.<br />
<br />
Quarters will also need to be able to allow for any http server to be used if the admin choses to use something other than the python https server<br />
<br />
==== Pacman Module ====<br />
Nearly all components will need to interact with pacman, he last I checked there we problems with the python bindings for alpm, if I am mistaken, I am all ears.<br />
<br />
Some standard functions with respect to pacman will need to be made available.<br />
<br />
==== PKGBUILD Parser ====<br />
I know, this is a bottomless pit, the requirements for the PKGBUILD parser are not extensive, although a number of parameters will need to be reliably extracted.<br />
<br />
==== Standard Utils Module====<br />
That anoying module that sets up logging and other more globally needed functions.<br />
<br />
<br />
----<br />
Links:<br />
<br />
- https://github.com/asdil12/aurbs - An automated build system for the AUR, written in python3 - added for code reference<br />
- https://github.com/archlinuxarm/plugbuild - An automated distributed build system used to build archlinux-arm, written in perl</div>Asdil12https://wiki.archlinux.org/index.php?title=DeveloperWiki:Automated_Package_Build_System&diff=276411DeveloperWiki:Automated Package Build System2013-09-23T09:38:11Z<p>Asdil12: added code reference for existing automated build system (for aur pkgs)</p>
<hr />
<div>[[Category:Package development]]<br />
== What is an Automated Build System ==<br />
One of the best examples of an automated package build systems is the Fedora Koji project, Koji is a continuous build system for all of the rpms in the Fedora and RHEL projects. The main benefit of an automated build system is that all of the packages need to pass through a common gate, a common checkpoint for quality and consistency.<br />
<br />
While the Koji build server is referenced heavily the Arch equivalent will need to be very different, in both architecture and the general goals of the project.<br />
<br />
== Naming ==<br />
The proposed name for the Arch package build system is Quarters, the logic being that what really feeds pacman is quarters.<br />
<br />
Alternative naming options will be considered<br />
<br />
== Design Proposal ==<br />
One of the main aspects of the Arch distribution compared to distributions like Fedora is money. The Fedora project can go out and buy servers by the arm full, but Arch will need to continue to rely on volunteer equipment and working with what we can get our hands on. While these aspects will effect the nature of the package build system, they cannot allow for the compromise of the quality of the Arch Linux distribution.<br />
<br />
=== Proposed Features ===<br />
<br />
# Simplicity<br />
## Avoid requiring too many daemons<br />
## No Authentication systems<br />
## No database dependencies<br />
## Simple https communication<br />
## Able to interact with distributed components over any reasonable link quality<br />
# Distributed<br />
## Need to be able to distribute the build load to systems all over the world<br />
## All communication needs to be encrypted (duh)<br />
## Builders make decisions by peer review<br />
# Data Model<br />
## Information on the available packages is made by parsing live pacman data (pacman is fast enough)<br />
## Packages to build is presented to the builders via serialized format (probably json)<br />
# Communication<br />
## All build communication is based on gathering presented data, all pulls, not puts<br />
## All servers are state machines, the status of the distributed build environment is assessed by parsing the "global" state machine<br />
## Command system to move packages manually from the build repos to the final repos<br />
# Build Cleanliness<br />
## Every package is built in its own clean chroot environment<br />
# Packages can be pulled and polled from many sources<br />
## SVN<br />
## AUR (plugable?)<br />
## GIT<br />
## Other scms ()<br />
## Web interface<br />
# Building Requirements<br />
## All packages need to be build-able, this includes the base toolchain<br />
## Trigger mass rebuilds of package, with version bumps<br />
## Track Packager data through the build process, do not allow the packager to be lost to the builder<br />
# System Interaction points<br />
## Detached cli interface sends signals to the master<br />
## Master server reads signals and acts on them<br />
<br />
== Programming Language ==<br />
It has been proposed that the application be developed in Python. Python is fast enough, has the libs we need, and who doesn't understand python?<br />
<br />
Sorry, but this project is too big for bash, and bash is too slow.<br />
<br />
I thought about OCaml, but I figured that it should be something that everyone can hack on.<br />
<br />
Try and go for python3<br />
<br />
== Builder Process ==<br />
The process that the builders will use is based on state information, the master server presents the master state, which is the list validated builders and the packages to be built; Only packages which have met all deps and makeedeps in binary repos will be presented. The master server will only present packages which are ready to be built. The builders then download the master server's state information. The builders pick package(s) to build, post the package that they have claimed and then query the other builders to see if any other builder has claimed it. If the builder needs to change the package to build then it will just post a claim on a new package. Unless it is the first build on the builder then the peer process of determining which package needs to be built will be done while a package is already being built.<br />
<br />
The master will regularly poll the states of the builders, the builders will post their states for the master and for the peers. The builder states will have all the information that the master needs to retrieve the built packages or the information for the failed build.<br />
<br />
==Component Build Out==<br />
Quarters will consist of a number of individual components. These components are all pieces of the distributed system, the components will also interact via a common language independent medium and https.<br />
<br />
=== Master Server Components ===<br />
The components required for the operation of the master server<br />
<br />
==== Core Loop ====<br />
The core loop or the core of the master does what most daemons do, takes in the config information, does the double pid form magic, etc.<br />
<br />
The core loop will primarily act by continually querying the distributed components for changes, thee components are the builders and the package parsers.<br />
<br />
==== Determine Packages Which are Ready to be Built ====<br />
The master will need to query the pacman repositories available, primarily the live repositories and the build repository. The names and versions of all available packages will be queried, then presented as a dictionary: {<packages name>: <version>}. This information is then compared to the information returned by the SCMS, then compiling a list of packages that need to be built is a simple task.<br />
<br />
==== Maintain Package Repositories ====<br />
A number of package repos will need to be maintained, a build repo will be maintained which simply contains all of the build packages, this is not to be a public repo, but is used by the builders to meed build dependencies.<br />
<br />
Once a package has been signed off it can be moved from the build repo to the live repo with a command. The command will ensure that the package that is entering the live repository has all deps met. If the package that is being moved to a live repository does not have all deps met the dependent packages will be presented for the move as well.<br />
<br />
This method satisfies both automatic building from scms and maintaining the manual process of moving packages into the live repos.<br />
<br />
==== Package Parsers ====<br />
The package parsers will be pluggable modules that return predictable data about the state of source package data stored in either a source control manager or an interface such as the abs or the AUR.<br />
<br />
The idea here is that as long as the data queried from the source is uniform there can be any number of usable interfaces. The primary system will need to be svn, since this is what the main package tree is stored in, then git and then an AUR parser. More interfaces can be added on later if we or anyone else wants them.<br />
<br />
All parsers need to return a similar data structure and may need to do some package preparation. The data structure will need to be defined and static, but it should just be a python dict, something json likes.<br />
<br />
===== SVN Parser =====<br />
This is the main package parser, the parser needs to be able to ready the PKGBUILDS for specific info, particularly pkgver, pkgname and pkgrel, then compare the values to the list of packages that are already built.<br />
Once the packages that need updating have been found the parser needs to return a data structure containing the packages that need to be built.<br />
The main challenge here is figuring out the fastest way to parse an SVN repo, they can be somewhat slow.<br />
<br />
==== Package Manipulators ====<br />
For full functionality most parsers will need companion manipulators, these are interfaces that can manipulate the PKGBUILDS in the underlying SCM. This is needed for mass rebuilds, so that certain packages can trigger deps to auto increment in the SCM. Once the PKGBUILDS have been auto incremented then they will be picked up for rebuilding.<br />
<br />
=== Build Server Components ===<br />
The build server will run on a host of different nodes. The build server needs to have a number of capabilities. Primarily it will need ample disk space to maintain multiple chroot environments as well as have enough ram and free cpu power.<br />
<br />
==== Master Queries ====<br />
The Build Server will need to be able to continually get a fresh state from the master.<br />
<br />
==== Peer Review System ====<br />
The builders will need to be able to download the build state from all of the peer builders. The list of builders will be provided by the master.<br />
<br />
After download the builder will need to analyze the state of the other builders and determine what package(s) that this builder should claim. The builder should always have package names ready, so long as packages are being presented by the master.<br />
<br />
I am still debating on this, I might have the master just present packages for the builders, but I still think that a peer system might be better.<br />
<br />
==== Main Loop ====<br />
The builder will need to maintain a single top level loop that controls all of the builder processes and continually queries the master and executes peer reviews.<br />
<br />
==== Chroot Builders ====<br />
The main loop will be able to spawn the configured number of chroot builders at the same time. These builders need to be maintained, inasmuch that the number of available packages to build needs to be kept ahead of the builders.<br />
<br />
=== Builder Considerations ===<br />
The builders will need to support many simultaneous chroots. A savvy admin for instance could use tmpfs file systems or ssd cards to maintain more and higher speed chroots. So the number of simultaneous package builders needs to be configurable with no limit. Disk IO will be the holding factor for many builds, since fresh chroot copies and updates need to be performed frequently.<br />
<br />
==== Threading ====<br />
When spawning a package builder, the python threading module cannot be used, Quarters as a whole will require multiple processes to operate properly. The threading module, and subsequently the python GIL should be avoided. Instead the multiprocessing module should be used.<br />
<br />
==== Builder Security ====<br />
While unexpected, the builders need to be protected from malicious code intended to compromise the system. When chroots are constructed the top chroot dir needs to have the barrier attribute test with setattr. Also the builds should be run as an unprivileged user inside the chroot. These precautions will defend against the two main ways to break a chroot, pwd manipulation and dev node hijacking.<br />
<br />
=== Standalone Components ===<br />
These components are used by multiple services<br />
<br />
==== Https Server ====<br />
Each component will need to be able to present files via an https server. The package will require a standalone https server written in python.<br />
<br />
Quarters will also need to be able to allow for any http server to be used if the admin choses to use something other than the python https server<br />
<br />
==== Pacman Module ====<br />
Nearly all components will need to interact with pacman, he last I checked there we problems with the python bindings for alpm, if I am mistaken, I am all ears.<br />
<br />
Some standard functions with respect to pacman will need to be made available.<br />
<br />
==== PKGBUILD Parser ====<br />
I know, this is a bottomless pit, the requirements for the PKGBUILD parser are not extensive, although a number of parameters will need to be reliably extracted.<br />
<br />
==== Standard Utils Module====<br />
That anoying module that sets up logging and other more globally needed functions.<br />
<br />
<br />
----<br />
Links:<br />
<br />
- https://github.com/asdil12/aurbs - An automated build system for the AUR, written in python3 - added for code reference</div>Asdil12https://wiki.archlinux.org/index.php?title=OpenVPN&diff=254660OpenVPN2013-04-20T10:10:36Z<p>Asdil12: /* DNS */ changed update-resolv-conf script to support multiple domains</p>
<hr />
<div>[[Category:Virtual Private Network]]<br />
[[de:OpenVPN]]<br />
[[zh-CN:OpenVPN]]<br />
{{Expansion|(at least) add support for ipv6 and L2 ethernet bridging}}<br />
<br />
This article describes a basic installation and configuration of [http://openvpn.net OpenVPN], suitable for private and small business use. For more detailed information, please see the official [http://openvpn.net/index.php/manuals/427-openvpn-22.html OpenVPN 2.2 man page] and the [http://openvpn.net/index.php/open-source/documentation OpenVPN documentation].<br />
<br />
OpenVPN is a robust and highly flexible [[Wikipedia:VPN|VPN]] daemon. OpenVPN supports [[Wikipedia:SSL/TLS|SSL/TLS]] security, [[Wikipedia:Bridging_(networking)|ethernet bridging]], [[Wikipedia:Transmission_Control_Protocol|TCP]] or [[Wikipedia:User_Datagram_Protocol|UDP]] [[Wikipedia:Tunneling_protocol|tunnel transport]] through [[Wikipedia:Proxy_server|proxies]] or [[Wikipedia:Network address translation|NAT]], support for dynamic IP addresses and [[Wikipedia:Dynamic_Host_Configuration_Protocol|DHCP]], scalability to hundreds or thousands of users, and portability to most major OS platforms.<br />
<br />
OpenVPN is tightly bound to the [http://www.openssl.org OpenSSL] library, and derives much of its crypto capabilities from it.<br />
<br />
OpenVPN supports conventional encryption using a [[Wikipedia:Pre-shared_key|pre-shared secret key]] (Static Key mode) or [[Wikipedia:Public_key|public key security]] ([[Wikipedia:SSL/TLS|SSL/TLS]] mode) using client & server certificates. OpenVPN also supports non-encrypted TCP/UDP tunnels.<br />
<br />
OpenVPN is designed to work with the [[Wikipedia:TUN/TAP|TUN/TAP]] virtual networking interface that exists on most platforms.<br />
<br />
Overall, OpenVPN aims to offer many of the key features of [[Wikipedia:Ipsec|IPSec]] but with a relatively lightweight footprint.<br />
<br />
OpenVPN was written by James Yonan and is published under the [[Wikipedia:GNU General Public License|GNU General Public License (GPL)]].<br />
<br />
==Install OpenVPN==<br />
[[pacman|Install]] {{Pkg|openvpn}} from the [[official repositories]].<br />
<br />
{{Note|The software contained in this package supports both server and client mode, so install it on all machines that need to create vpn connections.}}<br />
<br />
==Configure the system for TUN/TAP support==<br />
<br />
OpenVPN requires TUN/TAP support. Make sure to load at boot the {{ic|tun}} module. <br />
<br />
Read [[Kernel Modules]] for more information.<br />
<br />
The default kernel is already properly configured, but if you use another kernel make sure to enable the TUN/TAP module. If {{ic|$ zgrep CONFIG_TUN /proc/config.gz}} returns {{ic|<nowiki>CONFIG_TUN=n</nowiki>}}, make the following change to the kernel config file and rebuild the kernel.<br />
<br />
{{hc|Kernel config file|<br />
Device Drivers<br />
--> Network device support<br />
[M] Universal TUN/TAP device driver support}}<br />
<br />
==Connect to a VPN provided by a third party==<br />
<br />
To connect to a VPN provided by a third party, most of the following can most likely be ignored. Use the certificates and instructions given by your provider, for instance see: [[Airvpn]].<br />
<br />
==Create a Public Key Infrastructure (PKI) from scratch==<br />
<br />
If you are setting up OpenVPN from scratch, you will need to create a [[Wikipedia:Public key infrastructure|Public Key Infrastructure (PKI)]].<br />
<br />
Create the needed certificates and keys by following: [[Create a Public Key Infrastructure Using the easy-rsa Scripts]].<br />
<br />
The final step of the key creation process is to copy the files needed to the correct machines through a secure channel.<br />
<br />
{{Note|The rest of this article assumes that the keys and certificates are placed in /etc/openvpn.}}<br />
<br />
The public ca.crt certificate is needed on all servers and clients. The private ca.key key is secret and only needed on the key generating machine.<br />
<br />
A server needs server.crt, and dh2048.pem (public), and server.key and ta.key (private).<br />
<br />
A client needs client.crt (public), and client.key and ta.key (private).<br />
<br />
==A basic L3 IP routing configuration==<br />
<br />
{{Note|Unless otherwise explicitly stated, the rest of this article assumes this basic configuration.}}<br />
<br />
OpenVPN is an extremely versatile piece of software and many configurations are possible, in fact machines can be both "servers" and "clients", blurring the distinction between server and client.<br />
<br />
What really distinguishes a server from a client (apart from the type of certificate used) is the configuration file itself. The openvpn daemon startup script reads all the .conf configuration files it finds in /etc/openvpn on startup and acts accordingly. In fact if it finds more than one configuration file, it will start one OpenVPN processes per configuration file.<br />
<br />
This article explains how to setup a server called elmer, and a client that connects to it called bugs. More servers and clients can easily be added, by creating more key/certificate pairs and adding more server and client configuration files.<br />
<br />
The OpenVPN package comes with a collection of example configuration files for different purposes. The sample server and client configuration files make an ideal starting point for a basic OpenVPN setup with the following features:<br />
<br />
* Uses [[Wikipedia:Public key infrastructure|Public Key Infrastructure (PKI)]] for authentication.<br />
* Creates a VPN using a virtual TUN network interface (OSI L3 IP routing).<br />
* Listens for client connections on UDP port 1194 (OpenVPN's [[Wikipedia:Port_number|official IANA port number]]).<br />
* Distributes virtual addresses to connecting clients from the 10.8.0.0/24 subnet.<br />
<br />
For more advanced configurations, please see the official [http://openvpn.net/index.php/manuals/427-openvpn-22.html OpenVPN 2.2 man page] and the [http://openvpn.net/index.php/open-source/documentation OpenVPN documentation].<br />
<br />
===The server configuration file===<br />
<br />
Copy the example server configuration file to /etc/openvpn/server.conf<br />
<br />
{{bc|# cp /usr/share/openvpn/examples/server.conf /etc/openvpn/server.conf}}<br />
<br />
Edit the following:<br />
<br />
* The ca, cert, key, and dh parameters to reflect the path and names of the keys and certificates. Specifying the paths will allow you to run the OpenVPN executable from any directory for testing purposes.<br />
* Enable the SSL/TLS HMAC handshake protection. '''Note the use of the parameter 0 for a server'''.<br />
*It is recommended to run OpenVPN with reduced privileges once it has initialized, do this by uncommenting the user and group directives.<br />
<br />
{{hc|/etc/openvpn/server.conf|<br />
ca /etc/openvpn/ca.crt<br />
cert /etc/openvpn/elmer.crt<br />
key /etc/openvpn/elmer.key<br />
<br />
dh /etc/openvpn/dh2048.pem<br />
.<br />
.<br />
tls-auth /etc/openvpn/ta.key '''0'''<br />
.<br />
.<br />
user nobody<br />
group nobody<br />
}}<br />
<br />
{{Note|Note that if the server is behind a firewall or a NAT translating router, you will have to forward the OpenVPN UDP port (1194) to the server.}}<br />
<br />
===The client configuration file===<br />
<br />
Copy the example client configuration file to /etc/openvpn/client.conf<br />
<br />
{{bc|# cp /usr/share/openvpn/examples/client.conf /etc/openvpn/client.conf}}<br />
<br />
Edit the following:<br />
<br />
* The remote directive to reflect either the server's [[Wikipedia:Fully qualified domain name|Fully Qualified Domain Name]] hostname (as known to the client) or its IP address.<br />
* Uncomment the user and group directives to drop privileges.<br />
* The ca, cert, and key parameters to reflect the path and names of the keys and certificates.<br />
* Enable the SSL/TLS HMAC handshake protection. '''Note the use of the parameter 1 for a client'''.<br />
<br />
{{hc|/etc/openvpn/client.conf|<br />
remote elmer.acmecorp.org 1194<br />
.<br />
.<br />
user nobody<br />
group nobody<br />
.<br />
.<br />
ca /etc/openvpn/ca.crt<br />
cert /etc/openvpn/bugs.crt<br />
key /etc/openvpn/bugs.key<br />
.<br />
.<br />
tls-auth /etc/openvpn/ta.key '''1'''<br />
}}<br />
<br />
===Testing the OpenVPN configuration===<br />
<br />
Run {{ic|# openvpn /etc/openvpn/server.conf}} on the server, and {{ic|# openvpn /etc/openvpn/client.conf}} on the client. You should see something similar to this:<br />
<br />
{{hc|# openvpn /etc/openvpn/server.conf|<nowiki><br />
Wed Dec 28 14:41:26 2011 OpenVPN 2.2.1 x86_64-unknown-linux-gnu [SSL] [LZO2] [EPOLL] [eurephia] built on Aug 13 2011<br />
Wed Dec 28 14:41:26 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables<br />
Wed Dec 28 14:41:26 2011 Diffie-Hellman initialized with 2048 bit key<br />
.<br />
.<br />
Wed Dec 28 14:41:54 2011 bugs/95.126.136.73:48904 MULTI: primary virtual IP for bugs/95.126.136.73:48904: 10.8.0.6<br />
Wed Dec 28 14:41:57 2011 bugs/95.126.136.73:48904 PUSH: Received control message: 'PUSH_REQUEST'<br />
Wed Dec 28 14:41:57 2011 bugs/95.126.136.73:48904 SENT CONTROL [bugs]: 'PUSH_REPLY,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5' (status=1)<br />
</nowiki>}}<br />
<br />
{{hc|# openvpn /etc/openvpn/client.conf|<nowiki><br />
Wed Dec 28 14:41:50 2011 OpenVPN 2.2.1 i686-pc-linux-gnu [SSL] [LZO2] [EPOLL] [eurephia] built on Aug 13 2011<br />
Wed Dec 28 14:41:50 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables<br />
Wed Dec 28 14:41:50 2011 LZO compression initialized<br />
.<br />
.<br />
Wed Dec 28 14:41:57 2011 GID set to nobody<br />
Wed Dec 28 14:41:57 2011 UID set to nobody<br />
Wed Dec 28 14:41:57 2011 Initialization Sequence Completed<br />
</nowiki>}}<br />
<br />
On the server, find the IP assigned to the tunX device:<br />
<br />
{{hc|# ip addr show|<nowiki><br />
.<br />
.<br />
40: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100<br />
link/none<br />
inet 10.8.0.1 peer 10.8.0.2/32 scope global tun0</nowiki>}}<br />
<br />
Here we see that the server end of the tunnel has been given the IP address 10.8.0.1.<br />
<br />
Do the same on the client:<br />
<br />
{{hc|# ip addr show|<nowiki><br />
.<br />
.<br />
37: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100<br />
link/none<br />
inet 10.8.0.6 peer 10.8.0.5/32 scope global tun0</nowiki>}}<br />
<br />
And the client side has been given the IP 10.8.0.6.<br />
<br />
Now try pinging the interfaces.<br />
<br />
On the server:<br />
<br />
{{hc|# ping -c3 10.8.0.6|<nowiki><br />
PING 10.8.0.6 (10.8.0.6) 56(84) bytes of data.<br />
64 bytes from 10.8.0.6: icmp_req=1 ttl=64 time=238 ms<br />
64 bytes from 10.8.0.6: icmp_req=2 ttl=64 time=237 ms<br />
64 bytes from 10.8.0.6: icmp_req=3 ttl=64 time=205 ms<br />
<br />
--- 10.8.0.6 ping statistics ---<br />
3 packets transmitted, 3 received, 0% packet loss, time 2002ms<br />
rtt min/avg/max/mdev = 205.862/227.266/238.788/15.160 ms<br />
</nowiki>}}<br />
<br />
On the client:<br />
<br />
{{hc|# ping -c3 10.8.0.1|<nowiki><br />
PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data.<br />
64 bytes from 10.8.0.1: icmp_req=1 ttl=64 time=158 ms<br />
64 bytes from 10.8.0.1: icmp_req=2 ttl=64 time=158 ms<br />
64 bytes from 10.8.0.1: icmp_req=3 ttl=64 time=157 ms<br />
<br />
--- 10.8.0.1 ping statistics ---<br />
3 packets transmitted, 3 received, 0% packet loss, time 2001ms<br />
rtt min/avg/max/mdev = 157.426/158.278/158.940/0.711 ms<br />
</nowiki>}}<br />
<br />
You now have a working OpenVPN installation, and your client (bugs) will be able to use services on the server (elmer), and vice versa.<br />
<br />
{{Note|If using a firewall, make sure that ip packets on the TUN device are not blocked.}}<br />
<br />
===Configure the MTU with Fragment and MSS===<br />
<br />
{{Note|If you do not configure MTU then you will notice that small packets like ping and DNS will work, however web browsing will not work.}}<br />
<br />
Now it is time to configure the maximum segment size (MSS). In order to do this we need to discover what is the smallest MTU along the path between the client and server. In order to do this you can ping the server and disable fragmentation. Then specify the max packetsize.<br />
<br />
{{hc|# ping -c5 -M do -s 1500 elmer.acmecorp.org|<nowiki><br />
PING elmer.acmecorp.org (99.88.77.66) 1500(1528) bytes of data.<br />
From 1.2.3.4 (99.88.77.66) icmp_seq=1 Frag needed and DF set (mtu = 576)<br />
From 1.2.3.4 (99.88.77.66) icmp_seq=1 Frag needed and DF set (mtu = 576)<br />
From 1.2.3.4 (99.88.77.66) icmp_seq=1 Frag needed and DF set (mtu = 576)<br />
From 1.2.3.4 (99.88.77.66) icmp_seq=1 Frag needed and DF set (mtu = 576)<br />
From 1.2.3.4 (99.88.77.66) icmp_seq=1 Frag needed and DF set (mtu = 576)<br />
<br />
--- core.myrelay.net ping statistics ---<br />
0 packets transmitted, 0 received, +5 errors<br />
</nowiki>}}<br />
<br />
We received an ICMP message telling us the MTU is 576 bytes. The means we need to fragment the UDP packets smaller then 576 bytes to allow for some UDP overhead.<br />
<br />
{{hc|# ping -c5 -M do -s 548 elmer.acmecorp.org|<nowiki><br />
PING elmer.acmecorp.org (99.88.77.66) 548(576) bytes of data.<br />
556 bytes from 99.88.77.66: icmp_seq=1 ttl=48 time=206 ms<br />
556 bytes from 99.88.77.66: icmp_seq=2 ttl=48 time=224 ms<br />
556 bytes from 99.88.77.66: icmp_seq=3 ttl=48 time=206 ms<br />
556 bytes from 99.88.77.66: icmp_seq=4 ttl=48 time=207 ms<br />
556 bytes from 99.88.77.66: icmp_seq=5 ttl=48 time=208 ms<br />
<br />
--- myrelay.net ping statistics ---<br />
5 packets transmitted, 5 received, 0% packet loss, time 4001ms<br />
rtt min/avg/max/mdev = 206.027/210.603/224.158/6.832 ms<br />
</nowiki>}}<br />
<br />
After some trial and error..., we discover that we need to fragment packets on 548 bytes. In order to do this we specify this fragment size in the configuration and instruct OpenVPN to fix the Maximum Segment Size (MSS).<br />
<br />
{{hc|/etc/openvpn/client.conf|<br />
remote elmer.acmecorp.org 1194<br />
.<br />
.<br />
fragment 548<br />
mssfix<br />
.<br />
.<br />
user nobody<br />
group nobody<br />
.<br />
.<br />
ca /etc/openvpn/ca.crt<br />
cert /etc/openvpn/bugs.crt<br />
key /etc/openvpn/bugs.key<br />
.<br />
.<br />
tls-auth /etc/openvpn/ta.key '''1'''<br />
}}<br />
<br />
<br />
{{Note|This will add about 3min's to OpenVPN start time. It is advisable to configure the fragment size unless your client is a laptop that will be connecting over many different networks and the bottle neck is on the client side.}}<br />
<br />
You can also allow OpenVPN to do this for you by having OpenVPN do the ping testing every time the client connects to the VPN.<br />
{{hc|/etc/openvpn/client.conf|<br />
remote elmer.acmecorp.org 1194<br />
.<br />
.<br />
mtu-test<br />
.<br />
.<br />
user nobody<br />
group nobody<br />
.<br />
.<br />
ca /etc/openvpn/ca.crt<br />
cert /etc/openvpn/bugs.crt<br />
key /etc/openvpn/bugs.key<br />
.<br />
.<br />
tls-auth /etc/openvpn/ta.key '''1'''<br />
}}<br />
<br />
==Starting OpenVPN==<br />
<br />
===Manual startup===<br />
<br />
To troubleshoot a vpn connection, start the daemon manually with: {{ic|# openvpn /etc/openvpn/client.conf}}.<br />
<br />
=== Systemd service configuration ===<br />
<br />
To start openvpn automatically at system boot, [[Daemon|enable]] {{ic|openvpn@''<configuration>''.service}}.<br />
<br />
For example, if the configuration file is {{ic|/etc/openvpn/client.conf}}, the service name is {{ic|openvpn@client.service}}.<br />
<br />
==Advanced L3 IP routing==<br />
<br />
===Prerequisites for routing a LAN===<br />
<br />
====IPv4 forwarding====<br />
<br />
For a host to be able to forward IPv4 packets between the LAN and VPN, it must be able to forward the packets between its NIC and its tun/tap device.<br />
<br />
Edit {{ic|etc/sysctl.conf}} to permanently enable ipv4 packet forwarding (takes effect at the next boot):<br />
<br />
{{hc|/etc/sysctl.conf|<nowiki><br />
# Enable packet forwarding<br />
net.ipv4.ip_forward=1<br />
</nowiki>}}<br />
<br />
To temporarily enable without rebooting: {{ic|# echo 1 > /proc/sys/net/ipv4/ip_forward}}<br />
<br />
====Promiscuous LAN interface====<br />
<br />
The forwarding host's NIC (eth0 in the following examples) must also be able to accept packets for a different IP address than it is configured for, something known as [[Wikipedia:Promiscuous_mode|promiscious mode]]. To enable, add the following to {{ic|/etc/rc.local}} (takes effect at the next boot):<br />
<br />
{{hc|/etc/rc.local|ip link set dev eth0 promisc on}}<br />
<br />
To temporarily enable without rebooting: {{ic|# ip link set dev eth0 promisc on}}<br />
<br />
To set the {{ic|eth0}} in promiscuous mode using systemd use [[ Systemd/Services#Set_network_interface_in_promiscuous_mode | this service file ]] and enable it using:<br />
<br />
# systemctl enable promiscuous@eth0.service<br />
<br />
====Routing tables====<br />
<br />
{{Accuracy|Investigate if a routing protocol like RIP, QUAGGA, BIRD, etc can be used}}<br />
<br />
By default, all IP packets on a LAN addressed to a different subnet get sent to the default gateway. If the LAN/VPN gateway is also the default gateway, there is no problem and the packets get properly forwarded. If not, the gateway has no way of knowing where to send the packets. There are a couple of solutions to this problem.<br />
<br />
* Add a static route to the default gateway routing the VPN subnet to the LAN/VPN gateway's IP address.<br />
* Add a static route on each host on the LAN that needs to send IP packets back to the VPN.<br />
* Use [[iptables]]' NAT feature on the LAN/VPN gateway to masquerade the incoming VPN IP packets.<br />
<br />
===Connect the server LAN to a client===<br />
<br />
The server is on a LAN using the 10.66.0.0/24 subnet. To inform the client about the available subnet, add a push directive to the server configuration file:{{hc|/etc/openvpn/server.conf|push "route 10.66.0.0 255.255.255.0"}}<br />
<br />
{{Note|Remember to enable ipv4 forwarding and to make the LAN interface promiscuous on the server. Make sure the server LAN knows how to reach the VPN client.}}<br />
<br />
{{Note|To route more LANs from the server to the client, add more push directives to the server configuration file, but keep in mind that the server side LANs will need to know how to route to the client.}}<br />
<br />
===Connect the client LAN to a server===<br />
<br />
Prerequisites:<br />
<br />
* Any subnets used on the client side, must be unique and not in use on the server or by any other client. In this example we will use 192.168.4.0/24 for the clients LAN.<br />
* Each client's certificate has a unique Common Name, in this case bugs.<br />
* The server may not use the duplicate-cn directive in its config file.<br />
<br />
Create a client configuration directory on the server. It will be searched for a file named the same as the client's common name, and the directives will be applied to the client when it connects.<br />
<br />
{{bc|# mkdir -p /etc/openvpn/ccd}}<br />
<br />
Create a file in the client configuration directory called bugs, containing the {{ic|iroute 192.168.4.0 255.255.255.0}} directive. It tells the server what subnet should be routed to the client:<br />
<br />
{{hc|/etc/openvpn/ccd/bugs|iroute 192.168.4.0 255.255.255.0}}<br />
<br />
Add the client-config-dir and the {{ic|route 192.168.4.0 255.255.255.0}} directive to the server configuration file. It tells the server what subnet should be routed from the tun device to the server LAN:<br />
<br />
{{hc|/etc/openvpn/server.conf|<br />
client-config-dir ccd<br />
route 192.168.4.0 255.255.255.0<br />
}}<br />
<br />
{{Note|Remember to enable ipv4 forwarding and to make the LAN interface promiscuous on the client. Make sure the client LAN knows how to reach the VPN server.}}<br />
<br />
{{Note|To route more LANs from the client to the server, add more iroute and route directives to the appropriate configuration files, but keep in mind that the client side LANs will need to know how to route to the server.}}<br />
<br />
===Connect both the client and server LANs===<br />
<br />
Combine the two previous sections:<br />
<br />
{{hc|/etc/openvpn/server.conf|<br />
push "route 10.66.0.0 255.255.255.0"<br />
.<br />
.<br />
client-config-dir ccd<br />
route 192.168.4.0 255.255.255.0<br />
}}<br />
<br />
<br />
{{hc|/etc/openvpn/ccd/bugs|iroute 192.168.4.0 255.255.255.0}}<br />
<br />
<br />
{{Note|Remember to enable ipv4 forwarding and to make the LAN interfaces promiscuous on both the client and the server. Make sure that all the LANs or the needed hosts can route to all the destinations.}}<br />
<br />
===Connect clients and client LANs===<br />
<br />
By default clients will not see each other, to allow ip packets to flow between clients and/or client LANs add a client-to-client directive to the server configuration file: {{hc|/etc/openvpn/server.conf|client-to-client}}<br />
<br />
In order for another client or client LAN to see a specific client LAN you will need to add a push directive for each client subnet to the server configuration file (this will make the server announce the available subnet(s) to other clients):<br />
<br />
{{hc|/etc/openvpn/server.conf|<br />
client-to-client<br />
push "route 192.168.4.0 255.255.255.0"<br />
push "route 192.168.5.0 255.255.255.0"<br />
.<br />
.<br />
}}<br />
<br />
{{Note|As always, make sure that the routing is properly configured.}}<br />
<br />
==L2 Ethernet bridging==<br />
<br />
{{Expansion|Please add a well thought out section on L2 bridging.}}<br />
<br />
For now see: [[OpenVPN Bridge]]<br />
<br />
==Contributions that do not yet fit into the main article==<br />
<br />
{{Accuracy|Not quite sure where this fits into the main article yet}}<br />
<br />
===Routing client traffic through the server===<br />
<br />
Append the following to your server's openvpn.conf configuration file:<br />
{{bc|<br />
push "redirect-gateway def1"<br />
push "dhcp-option DNS 192.168.1.1"<br />
}}<br />
Change "192.168.1.1" to your preferred DNS IP address.<br />
<br />
If you have problems with non responsive DNS after connecting to server, install [[BIND]] as simple DNS forwarder and push openvpn ip address of server as DNS to clients.<br />
<br />
====Configure ufw for routing====<br />
Configure your ufw settings to enable routing traffic from clients through server.<br />
<br />
You must change default forward policy, edit /etc/sysctl.conf to permanently enable ipv4 packet forwarding. Takes effect at the next boot.<br />
{{hc|/etc/sysctl.conf|<nowiki><br />
# Enable packet forwarding<br />
net.ipv4.ip_forward=1<br />
</nowiki>}} <br />
<br />
And then configure ufw in '''/etc/default/ufw'''<br />
<br />
{{hc|/etc/default/ufw|<nowiki><br />
DEFAULT_FORWARD_POLICY="ACCEPT"<br />
</nowiki>}}<br />
<br />
Now change '''/etc/ufw/before.rules''', and add the following code after the header and before the "*filter" line. Don't forget to change the IP/subnet mask to match the one in '''/etc/openvpn/server.conf'''.<br />
<br />
{{hc|/etc/ufw/before.rules|<nowiki><br />
# NAT (Network Address Translation) table rules<br />
*nat<br />
:POSTROUTING ACCEPT [0:0]<br />
<br />
# Allow traffic from clients to eth0<br />
-A POSTROUTING -s 10.8.0.0/8 -o eth0 -j MASQUERADE<br />
<br />
# don't delete the "COMMIT" line or the NAT table rules above won't be processed<br />
COMMIT<br />
</nowiki>}}<br />
<br />
Open openvpn port 1194<br />
<br />
{{bc|<br />
ufw allow 1194<br />
}}<br />
<br />
====Using iptables====<br />
<br />
Use an iptable for NAT forwarding:<br />
{{bc|<br />
echo 1 > /proc/sys/net/ipv4/ip_forward<br />
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE<br />
}}<br />
<br />
If running ArchLinux in a OpenVZ VPS environment [http://thecodeninja.net/linux/openvpn-archlinux-openvz-vps/]:<br />
{{bc|<br />
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o venet0 -j SNAT --to (venet0 ip)<br />
}}<br />
<br />
If all is well, make the changes permanent:<br />
<br />
Edit '''/etc/conf.d/iptables''' and change IPTABLES_FORWARD=1<br />
<br />
{{bc|<br />
/etc/rc.d/iptables save<br />
}}<br />
<br />
<br />
===Configuring LDAP authorization===<br />
<br />
{{Accuracy|what does the following do, and is the package still supported?}}<br />
You may also want to install {{AUR|openvpn-authldap-plugin}}, available in the [[Arch User Repository]].<br />
<br />
===Deprecated older wiki content===<br />
<br />
{{Accuracy|See how this older content can be fitted into the new article}}<br />
<br />
====Using PAM and passwords to authenticate====<br />
{{bc|<br />
port 1194<br />
proto udp<br />
mtu-test<br />
dev tap<br />
ca /etc/openvpn/easy-rsa/keys/ca.crt<br />
cert /etc/openvpn/easy-rsa/keys/<MYSERVER>.crt<br />
key /etc/openvpn/easy-rsa/keys/<MYSERVER>.key<br />
dh /etc/openvpn/easy-rsa/keys/dh2048.pem<br />
server 192.168.56.0 255.255.255.0<br />
ifconfig-pool-persist ipp.txt<br />
;learn-address ./script<br />
client-to-client<br />
;duplicate-cn<br />
keepalive 10 120<br />
;tls-auth ta.key 0<br />
comp-lzo<br />
;max-clients 100<br />
;user nobody<br />
;group nobody<br />
persist-key<br />
persist-tun<br />
status /var/log/openvpn-status.log<br />
verb 3<br />
client-cert-not-required<br />
username-as-common-name<br />
plugin /usr/lib/openvpn/openvpn-auth-pam.so login<br />
}}<br />
<br />
====Using certs to authenticate====<br />
{{bc|<br />
port 1194<br />
proto tcp<br />
dev tun0<br />
<br />
ca /etc/openvpn/easy-rsa/keys/ca.crt<br />
cert /etc/openvpn/easy-rsa/keys/<MYSERVER>.crt<br />
key /etc/openvpn/easy-rsa/keys/<MYSERVER>.key<br />
dh /etc/openvpn/easy-rsa/keys/dh2048.pem<br />
<br />
server 10.8.0.0 255.255.255.0<br />
ifconfig-pool-persist ipp.txt<br />
keepalive 10 120<br />
comp-lzo<br />
user nobody<br />
group nobody<br />
persist-key<br />
persist-tun<br />
status /var/log/openvpn-status.log<br />
verb 3<br />
<br />
log-append /var/log/openvpn<br />
status /tmp/vpn.status 10<br />
}}<br />
<br />
====Routing traffic through the server====<br />
<br />
Append the following to your server's openvpn.conf configuration file:<br />
{{bc|<br />
push "dhcp-option DNS 192.168.1.1"<br />
push "redirect-gateway def1"<br />
}}<br />
Change "192.168.1.1" to your external DNS IP address.<br />
<br />
Use an iptable for NAT forwarding:<br />
{{bc|<br />
echo 1 > /proc/sys/net/ipv4/ip_forward<br />
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE<br />
}}<br />
<br />
If running ArchLinux in a OpenVZ VPS environment [http://thecodeninja.net/linux/openvpn-archlinux-openvz-vps/]:<br />
{{bc|<br />
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o venet0 -j SNAT --to (venet0 ip)<br />
}}<br />
<br />
If all is well, make the changes permanent:<br />
<br />
Edit /etc/conf.d/iptables and change IPTABLES_FORWARD=1<br />
<br />
{{bc|<br />
/etc/rc.d/iptables save<br />
}}<br />
<br />
====Setting up the Client====<br />
The clientside .conf file<br />
=====With password authentication=====<br />
{{bc|<br />
client<br />
dev tap<br />
proto udp<br />
mtu-test<br />
remote <address> 1194<br />
resolv-retry infinite<br />
nobind<br />
persist-tun<br />
comp-lzo<br />
verb 3<br />
auth-user-pass passwd<br />
ca ca.crt<br />
}}<br />
<br />
passwd file (referenced by auth-user-pass) must contain two lines:<br />
* first line - username<br />
* second - password<br />
<br />
=====Certs authentication=====<br />
{{bc|<br />
client<br />
remote <MYSERVER> 1194<br />
dev tun0<br />
proto tcp<br />
resolv-retry infinite<br />
nobind<br />
persist-key<br />
persist-tun<br />
verb 2<br />
ca ca.crt<br />
cert client1.crt<br />
key client1.key<br />
comp-lzo<br />
}}<br />
Copy three files from server to remote computer.<br />
ca.crt<br />
client1.crt<br />
client1.key<br />
<br />
Install the tunnel/tap module:<br />
{{bc|<br />
# sudo modprobe tun<br />
}}<br />
<br />
To have the '''tun''' module loaded automatically at boot time add it to the Modules line in /etc/rc.conf<br />
<br />
=====DNS=====<br />
The DNS servers used by the system are defined in '''/etc/resolv.conf'''. Traditionally, this file is the responsibility of whichever program deals with connecting the system to the network (e.g. Wicd, NetworkManager, etc...) However, OpenVPN will need to modify this file if you want to be able to resolve names on the remote side. To achieve this in a sensible way, install '''openresolv''', which makes it possible for more than one program to modify resolv.conf without stepping on each-other's toes. Before continuing, test openresolv by restarting your network connection and ensuring that resolv.conf states that it was generated by "resolvconf", and that your DNS resolution still works as before. You should not need to configure openresolv; it should be automatically detected and used by your network system.<br />
<br />
Next, save the following script at '''/usr/share/openvpn/update-resolv-conf''':<br />
{{bc|<nowiki><br />
#!/bin/bash<br />
#<br />
# Parses DHCP options from openvpn to update resolv.conf<br />
# To use set as 'up' and 'down' script in your openvpn *.conf:<br />
# up /etc/openvpn/update-resolv-conf<br />
# down /etc/openvpn/update-resolv-conf<br />
#<br />
# Used snippets of resolvconf script by Thomas Hood <jdthood@yahoo.co.uk><br />
# and Chris Hanson<br />
# Licensed under the GNU GPL. See /usr/share/common-licenses/GPL.<br />
#<br />
# 05/2006 chlauber@bnc.ch<br />
#<br />
# Example envs set from openvpn:<br />
# foreign_option_1='dhcp-option DNS 193.43.27.132'<br />
# foreign_option_2='dhcp-option DNS 193.43.27.133'<br />
# foreign_option_3='dhcp-option DOMAIN be.bnc.ch'<br />
<br />
[ -x /usr/sbin/resolvconf ] || exit 0<br />
<br />
case $script_type in<br />
<br />
up)<br />
for optionname in ${!foreign_option_*} ; do<br />
option="${!optionname}"<br />
echo $option<br />
part1=$(echo "$option" | cut -d " " -f 1)<br />
if [ "$part1" == "dhcp-option" ] ; then<br />
part2=$(echo "$option" | cut -d " " -f 2)<br />
part3=$(echo "$option" | cut -d " " -f 3)<br />
if [ "$part2" == "DNS" ] ; then<br />
IF_DNS_NAMESERVERS="$IF_DNS_NAMESERVERS $part3"<br />
fi<br />
if [ "$part2" == "DOMAIN" ] ; then<br />
IF_DNS_SEARCH="$IF_DNS_SEARCH $part3"<br />
fi<br />
fi<br />
done<br />
R=""<br />
if [ "$IF_DNS_SEARCH" ] ; then<br />
R="${R}search $IF_DNS_SEARCH<br />
"<br />
fi<br />
for NS in $IF_DNS_NAMESERVERS ; do<br />
R="${R}nameserver $NS<br />
"<br />
done<br />
echo -n "$R" | /usr/sbin/resolvconf -a "${dev}.inet"<br />
;;<br />
down)<br />
/usr/sbin/resolvconf -d "${dev}.inet"<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
Remember to make the file executable with:<br />
$ chmod +x /usr/share/openvpn/update-resolv-conf<br />
Next, add the following lines to your OpenVPN client configuration file:<br />
{{bc|<br />
script-security 2<br />
up /usr/share/openvpn/update-resolv-conf<br />
down /usr/share/openvpn/update-resolv-conf<br />
}}<br />
<br />
Now, when your launch your OpenVPN connection, you should find that your resolv.conf file is updated accordingly, and also returns to normal when your close the connection.<br />
<br />
=====Webmin=====<br />
<br />
{{AUR|webmin-plugin-openvpn}} is available in the [[AUR]].<br />
{{Note|You must add "openvpn" to the end of /etc/webmin/webmin.acl.}}<br />
<br />
====Connecting to the Server====<br />
You need to start the service on the server<br />
{{bc|<br />
/etc/rc.d/openvpn start<br />
}}<br />
You can add it to rc.conf to make it permanent.<br />
<br />
On the client, in the home directory create a folder that will hold your OpenVPN client config files along with the '''.crt'''/'''.key''' files. Assuming your OpenVPN config folder is called '''.openvpn''' and your client config file is '''vpn1.conf''', to connect to the server issue the following command:<br />
{{bc|<br />
cd ~/.openvpn && sudo openvpn vpn1.conf<br />
}}</div>Asdil12