https://wiki.archlinux.org/api.php?action=feedcontributions&user=Kgizdov&feedformat=atomArchWiki - User contributions [en]2024-03-28T15:46:52ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=DeveloperWiki:Google_Summer_of_Code&diff=596957DeveloperWiki:Google Summer of Code2020-02-08T01:14:45Z<p>Kgizdov: add Arch Linux Installer project</p>
<hr />
<div>[[Category:Arch development]]<br />
The Arch Linux development team is considering to participate this year in [https://summerofcode.withgoogle.com/ Google Summer of Code (GSoC)], here is a draft on what areas we are needing improvements.<br />
<br />
The main idea here is to help the development of these tools, improving it, making patches and fixing bugs for now.<br />
<br />
=== Project Ideas ===<br />
<br />
* Aurweb rewrite in Python<br />
* PKGBUILD Language server (implement a [https://langserver.org/ Language Server Protocol])<br />
* Archweb - Implement an official pkgstats<br />
* Signing enclave system -https://github.com/archlinux/signstar<br />
* Package rebuilder list - https://github.com/archlinux/rebuilder<br />
* Package version crawler - https://github.com/archlinux/sandcrawler<br />
* Dbscripts rewrite in Python (svn2git) - https://github.com/archlinux/arch-repo-management<br />
* Arch Linux Installer (arch-installer) - https://github.com/kgizdov/arch-installer<br />
<br />
==== Pacman-related Ideas ====<br />
<br />
* adding sync db write into libalpm, and use that to reimplement repo-add/repo-remove<br />
* --print-format should work for many, many more options<br />
* iterator interface for databases<br />
* getting pacman to compile in C++ and switching to some STL<br />
* parallel computations<br />
<br />
=== Potential Mentors ===<br />
<br />
* AUR - Lukas<br />
* Archweb - Jelle<br />
* Pacman - Allan<br />
* arch-installer - Konstantin</div>Kgizdovhttps://wiki.archlinux.org/index.php?title=Libvirt&diff=594603Libvirt2020-01-11T14:17:26Z<p>Kgizdov: update note about firewalld configuration</p>
<hr />
<div>{{DISPLAYTITLE:libvirt}}<br />
[[Category:Virtualization]]<br />
[[ja:libvirt]]<br />
[[zh-hans:Libvirt]]<br />
[[zh-hant:Libvirt]]<br />
{{Related articles start}}<br />
{{Related|:Category:Hypervisors}}<br />
{{Related|:PCI passthrough via OVMF}}<br />
{{Related articles end}}<br />
<br />
Libvirt is collection of software that provides a convenient way to manage virtual machines and other virtualization functionality, such as storage and network interface management. These software pieces include a long term stable C API, a daemon (libvirtd), and a command line utility (virsh). A primary goal of libvirt is to provide a single way to manage multiple different virtualization providers/hypervisors, such as the [[QEMU|KVM/QEMU]], [[Xen]], [[LXC]], [http://openvz.org OpenVZ] or [[VirtualBox]] [[:Category:Hypervisors|hypervisors]] ([http://libvirt.org/drivers.html among others]).<br />
<br />
Some of the major libvirt features are:<br />
*'''VM management''': Various domain lifecycle operations such as start, stop, pause, save, restore, and migrate. Hotplug operations for many device types including disk and network interfaces, memory, and CPUs.<br />
*'''Remote machine support''': All libvirt functionality is accessible on any machine running the libvirt daemon, including remote machines. A variety of network transports are supported for connecting remotely, with the simplest being SSH, which requires no extra explicit configuration.<br />
*'''Storage management''': Any host running the libvirt daemon can be used to manage various types of storage: create file images of various formats (qcow2, vmdk, raw, ...), mount NFS shares, enumerate existing LVM volume groups, create new LVM volume groups and logical volumes, partition raw disk devices, mount iSCSI shares, and much more.<br />
*'''Network interface management''': Any host running the libvirt daemon can be used to manage physical and logical network interfaces. Enumerate existing interfaces, as well as configure (and create) interfaces, bridges, vlans, and bond devices.<br />
*'''Virtual NAT and Route based networking''': Any host running the libvirt daemon can manage and create virtual networks. Libvirt virtual networks use firewall rules to act as a router, providing VMs transparent access to the host machines network.<br />
<br />
== Installation ==<br />
<br />
Because of its daemon/client architecture, libvirt needs only be installed on the machine which will host the virtualized system. Note that the server and client can be the same physical machine.<br />
<br />
=== Server ===<br />
<br />
[[Install]] the {{pkg|libvirt}} package, as well as at least one hypervisor:<br />
<br />
* The [http://libvirt.org/drvqemu.html libvirt KVM/QEMU driver] is the primary ''libvirt'' driver and if [[QEMU#Enabling_KVM|KVM is enabled]], fully virtualized, hardware accelerated guests will be available. See the [[QEMU]] article for more information.<br />
<br />
* Other [http://libvirt.org/drivers.html supported hypervisors] include [[LXC]], [[VirtualBox]] and [[Xen]]. See the respective articles for installation instructions. With respect to {{ic|libvirtd}} installation note: <br />
** The [http://libvirt.org/drvlxc.html libvirt LXC driver] has no dependency on the [[LXC]] userspace tools provided by {{Pkg|lxc}}, therefore there is no need to install the package if planning on using the driver.<br />
** [[Xen]] support is available, but not by default. You need to use the [[ABS]] to modify {{Pkg|libvirt}}'s [[PKGBUILD]] and build it without the {{ic|--without-xen}} option. As VirtualBox in turn has no planned stable support for Xen, you might as well replace it with {{ic|--without-vbox}}.<br />
<br />
For network connectivity, install: <br />
<br />
* {{Pkg|ebtables}}, and {{Pkg|dnsmasq}} for the [http://wiki.libvirt.org/page/VirtualNetworking#The_default_configuration default] NAT/DHCP networking.<br />
* {{Pkg|bridge-utils}} for bridged networking.<br />
* {{Pkg|openbsd-netcat}} for remote management over [[SSH]].<br />
<br />
{{Note|If you are using [[firewalld]], as of {{ic|libvirt}} 5.1.0 and [[firewalld]] 0.7.0 you no longer need to change the firewall backend to [[iptables]]. {{ic|libvirt}} now installs a zone called 'libvirt' in [[firewalld]] and manages its required network rules there. [https://libvirt.org/firewall.html Firewall and network filtering in libvirt]}}<br />
<br />
=== Client ===<br />
<br />
The client is the user interface that will be used to manage and access the virtual machines.<br />
<br />
* {{App|virsh|Command line program for managing and configuring domains.|https://libvirt.org/|{{Pkg|libvirt}}}}<br />
* {{App|[[Wikipedia:GNOME Boxes|GNOME Boxes]]|Simple GNOME 3 application to access remote or virtual systems.|https://wiki.gnome.org/Apps/Boxes|{{Pkg|gnome-boxes}}}}<br />
* {{App|Libvirt Sandbox|Application sandbox toolkit.|https://sandbox.libvirt.org/|{{AUR|libvirt-sandbox}}}}<br />
* {{App|Remote Viewer|Simple remote display client.|https://virt-manager.org/|{{Pkg|virt-viewer}}}}<br />
* {{App|Qt VirtManager|Qt application for managing virtual machines.|https://github.com/F1ash/qt-virt-manager|{{AUR|qt-virt-manager}}}}<br />
* {{App|[[Wikipedia:Virtual Machine Manager|Virtual Machine Manager]]|Graphically manage KVM, Xen, or LXC via libvirt.|https://virt-manager.org/|{{Pkg|virt-manager}}}}<br />
<br />
A list of libvirt-compatible software can be found [http://libvirt.org/apps.html here].<br />
<br />
== Configuration ==<br />
<br />
For '''''system'''''-level administration (i.e. global settings and image-''volume'' location), libvirt minimally requires [[#Set up authentication|setting up authorization]], and [[#Daemon|starting the daemon]].<br />
<br />
{{Note|For user-'''''session''''' administration, daemon setup and configuration is ''not'' required; authorization, however, is limited to local abilities; the front-end will launch a local instance of the '''libvirtd''' daemon.}}<br />
<br />
=== Set up authentication ===<br />
<br />
From [http://libvirt.org/auth.html#ACL_server_config libvirt: Connection authentication]:<br />
:The libvirt daemon allows the administrator to choose the authentication mechanisms used for client connections on each network socket independently. This is primarily controlled via the libvirt daemon master config file in {{ic|/etc/libvirt/libvirtd.conf}}. Each of the libvirt sockets can have its authentication mechanism configured independently. There is currently a choice of {{ic|none}}, {{ic|polkit}} and {{ic|sasl}}. <br />
<br />
Because {{Pkg|libvirt}} pulls {{Pkg|polkit}} as a dependency during installation, [[#Using polkit|polkit]] is used as the default value for the {{ic|unix_sock_auth}} parameter ([http://libvirt.org/auth.html#ACL_server_polkit source]). [[#Authenticate with file-based permissions|File-based permissions]] remain nevertheless available.<br />
<br />
==== Using polkit ====<br />
{{Note|A system reboot may be required before authenticating with {{ic|polkit}} works correctly.}}<br />
<br />
The ''libvirt'' daemon provides two [[Polkit#Actions|polkit actions]] in {{ic|/usr/share/polkit-1/actions/org.libvirt.unix.policy}}:<br />
* {{ic|org.libvirt.unix.manage}} for full management access (RW daemon socket), and<br />
* {{ic|org.libvirt.unix.monitor}} for monitoring only access (read-only socket).<br />
<br />
The default policy for the RW daemon socket will require to authenticate as an admin. This is akin to [[sudo]] auth, but does not require that the client application ultimately run as root. Default policy will still allow any application to connect to the RO socket.<br />
<br />
Arch defaults to consider anybody in the {{ic|wheel}} group as an administrator: this is defined in {{ic|/etc/polkit-1/rules.d/50-default.rules}} (see [[Polkit#Administrator identities]]). Therefore there is no need to create a new group and rule file '''if your user is a member of the {{ic|wheel}} group''': upon connection to the RW socket (e.g. via {{Pkg|virt-manager}}) you will be prompted for your user's password.<br />
<br />
{{Note|Prompting for a password relies on the presence of an [[Polkit#Authentication_agents|authentication agent]] on the system. Console users may face an issue with the default {{ic|pkttyagent}} agent which may or may not work properly.}}<br />
<br />
{{Tip|If you want to configure passwordless authentication, see [[Polkit#Bypass password prompt]].}}<br />
<br />
As of libvirt 1.2.16 (commit:[http://libvirt.org/git/?p=libvirt.git;a=commit;h=e94979e901517af9fdde358d7b7c92cc055dd50c]), members of the {{ic|libvirt}} group have passwordless access to the RW daemon socket by default. The easiest way to ensure your user has access is to ensure the libvirt group exists and they are a member of it.<br />
<br />
You may change the group authorized to access the RW daemon socket. As an example, to authorize the {{ic|kvm}} group, create the following file:<br />
<br />
{{hc|/etc/polkit-1/rules.d/50-libvirt.rules|<nowiki><br />
/* Allow users in kvm group to manage the libvirt<br />
daemon without authentication */<br />
polkit.addRule(function(action, subject) {<br />
if (action.id == "org.libvirt.unix.manage" &&<br />
subject.isInGroup("kvm")) {<br />
return polkit.Result.YES;<br />
}<br />
});</nowiki><br />
}}<br />
<br />
Then [[Users_and_groups#Other_examples_of_user_management|add yourself]] to the {{ic|kvm}} group and relogin. Replace ''kvm'' with any group of your preference just make sure it exists and that your user is a member of it (see [[Users and groups]] for more information).<br />
<br />
Do not forget to relogin for group changes to take effect.<br />
<br />
==== Authenticate with file-based permissions ====<br />
<br />
To define file-based permissions for users in the ''libvirt'' group to manage virtual machines, uncomment and define:<br />
<br />
{{hc|/etc/libvirt/libvirtd.conf|<nowiki><br />
#unix_sock_group = "libvirt"<br />
#unix_sock_ro_perms = "0777" # set to 0770 to deny non-group libvirt users<br />
#unix_sock_rw_perms = "0770"<br />
#auth_unix_ro = "none"<br />
#auth_unix_rw = "none"<br />
</nowiki>}}<br />
<br />
While some guides mention changed permissions of certain libvirt directories to ease management, keep in mind permissions are lost on package update. To edit these system directories, root user is expected.<br />
<br />
=== Daemon ===<br />
<br />
{{Style|Can you make it simpler with only 2 small sentences?}}<br />
<br />
[[Start]] both {{ic|libvirtd.service}} and {{ic|virtlogd.service}}. Optionally [[enable]] {{ic|libvirtd.service}}. There is no need to enable {{ic|virtlogd.service}}, since {{ic|libvirtd.service}}, when enabled, also enables the {{ic|virtlogd.socket}} and {{ic|virtlockd.socket}} [[Systemd#Using_units|units]].<br />
<br />
=== Unencrypt TCP/IP sockets ===<br />
<br />
{{Warning|This method is used to help remote domain, connection speed for trusted networks. This is the least secure connection method. This should ''only'' be used for testing or use over a secure, private, and trusted network. SASL is not enabled here, so all TCP traffic is ''cleartext''. For real world use ''always'' enable SASL.}}<br />
<br />
Edit {{ic|/etc/libvirt/libvirtd.conf}}:<br />
{{hc|/etc/libvirt/libvirtd.conf|<nowiki><br />
listen_tls = 0<br />
listen_tcp = 1<br />
auth_tcp="none"<br />
</nowiki>}}<br />
<br />
It is also necessary to start the server in listening mode by editing {{ic|/etc/conf.d/libvirtd}}:<br />
<br />
{{hc|/etc/conf.d/libvirtd|2=LIBVIRTD_ARGS="--listen"}}<br />
<br />
=== Access virtual machines using their hostnames ===<br />
<br />
For host access to guests on non-isolated, bridged networks, enable the {{ic|libvirt}} NSS module provided by {{Pkg|libvirt}}.<br />
<br />
Edit {{ic|/etc/nsswitch.conf}}:<br />
{{hc|/etc/nsswitch.conf|<nowiki><br />
hosts: files libvirt libvirt_guest dns myhostname<br />
</nowiki>}}<br />
<br />
{{Note|While commands such as {{ic|ping}} and {{ic|ssh}} should work with virtual machine hostnames, commands such as {{ic|host}} and {{ic|nslookup}} may fail or produce unexpected results because they rely on DNS. Use {{ic|getent hosts <vm-hostname>}} instead.}}<br />
<br />
== Test ==<br />
<br />
To test if libvirt is working properly on a ''system'' level:<br />
<br />
$ virsh -c qemu:///system<br />
<br />
To test if libvirt is working properly for a user-''session'':<br />
<br />
$ virsh -c qemu:///session<br />
<br />
== Management ==<br />
<br />
Libvirt management is done mostly with three tools: {{Pkg|virt-manager}} (GUI), {{ic|virsh}}, and {{ic|guestfish}} (which is part of {{Pkg|libguestfs}}).<br />
<br />
=== virsh ===<br />
<br />
The virsh program is for managing guest ''domains'' (virtual machines) and works well for scripting, virtualization administration. Though most virsh commands require root privileges to run due to the communication channels used to talk to the hypervisor, typical management, creation, and running of domains (like that done with VirtualBox) can be done as a regular user.<br />
<br />
Virsh includes an interactive terminal that can be entered if no commands are passed (options are allowed though): {{ic|virsh}}. The interactive terminal has support for tab completion.<br />
<br />
From the command line:<br />
<br />
$ virsh [option] <command> [argument]...<br />
<br />
From the interactive terminal:<br />
<br />
virsh # <command> [argument]...<br />
<br />
Help is available:<br />
<br />
$ virsh help [option*] or [group-keyword*]<br />
<br />
=== Storage pools ===<br />
<br />
A pool is a location where storage ''volumes'' can be kept. What libvirt defines as ''volumes'' others may define as "virtual disks" or "virtual machine images". Pool locations may be a directory, a network filesystem, or partition (this includes a [[LVM]]). Pools can be toggled active or inactive and allocated for space.<br />
<br />
On the ''system''-level, {{ic|/var/lib/libvirt/images/}} will be activated by default; on a user-''session'', {{ic|virt-manager}} creates {{ic|$HOME/VirtualMachines}}.<br />
<br />
Print active and inactive storage pools:<br />
<br />
$ virsh pool-list --all<br />
<br />
==== Create a new pool using virsh ====<br />
<br />
If one wanted to ''add'' a storage pool, here are examples of the command form, adding a directory, and adding a LVM volume:<br />
<br />
$ virsh pool-define-as name type [source-host] [source-path] [source-dev] [source-name] [<target>] [--source-format format]<br />
$ virsh pool-define-as ''poolname'' dir - - - - /home/''username''/.local/libvirt/images<br />
$ virsh pool-define-as ''poolname'' fs - - ''/dev/vg0/images'' - ''mntpoint''<br />
<br />
The above command defines the information for the pool, to build it:<br />
<br />
$ virsh pool-build ''poolname''<br />
$ virsh pool-start ''poolname''<br />
$ virsh pool-autostart ''poolname''<br />
<br />
To remove it:<br />
<br />
$ virsh pool-undefine ''poolname''<br />
<br />
{{Tip|For LVM storage pools:<br />
* It is a good practice to dedicate a volume group to the storage pool only. <br />
* Choose a LVM volume group that differs from the pool name, otherwise when the storage pool is deleted the LVM group will be too.<br />
}}<br />
<br />
==== Create a new pool using virt-manager ====<br />
<br />
First, connect to a hypervisor (e.g. QEMU/KVM ''system'', or user-''session''). Then, right-click on a connection and select ''Details''; select the ''Storage'' tab, push the ''+'' button on the lower-left, and follow the wizard.<br />
<br />
=== Storage volumes ===<br />
<br />
Once the pool has been created, volumes can be created inside the pool. ''If building a new domain (virtual machine), this step can be skipped as a volume can be created in the domain creation process.''<br />
<br />
==== Create a new volume with virsh ====<br />
<br />
Create volume, list volumes, resize, and delete:<br />
$ virsh vol-create-as ''poolname'' ''volumename'' 10GiB --format aw|bochs|raw|qcow|qcow2|vmdk<br />
$ virsh vol-upload --pool ''poolname'' ''volumename'' ''volumepath''<br />
$ virsh vol-list ''poolname''<br />
$ virsh vol-resize --pool ''poolname'' ''volumename'' 12GiB<br />
$ virsh vol-delete --pool ''poolname'' ''volumename''<br />
$ virsh vol-dumpxml --pool ''poolname'' ''volumename'' # for details.<br />
<br />
==== virt-manager backing store type bug ====<br />
<br />
{{out of date|This bug was fixed upstream in 2016. Numerous libvirt releases have occurred since then.}}<br />
<br />
On newer versions of {{ic|virt-manager}} you can now specify a backing store to use when creating a new disk. This is very useful, in that you can have new domains be based on base images saving you both time and disk space when provisioning new virtual systems. There is a bug (https://bugzilla.redhat.com/show_bug.cgi?id=1235406) in the current version of {{ic|virt-manager}} which causes {{ic|virt-manager}} to choose the wrong type of the backing image in the case where the backing image is a {{ic|qcow2}} type. In this case, it will errantly pick the backing type as {{ic|raw}}. This will cause the new image to be unable to read from the backing store, and effectively remove the utility of having a backing store at all.<br />
<br />
There is a workaround for this issue. {{ic|qemu-img}} has long been able to do this operation directly. If you wish to have a backing store for your new domain before this bug is fixed, you may use the following command.<br />
<br />
$ qemu-img create -f qcow2 -o backing_file=<path to backing image>,backing_fmt=qcow2 <disk name> <disk size><br />
<br />
Then you can use this image as the base for your new domain and it will use the backing store as a COW volume saving you time and disk space.<br />
<br />
=== Domains ===<br />
<br />
Virtual machines are called ''domains''. If working from the command line, use {{ic|virsh}} to list, create, pause, shutdown domains, etc. {{ic|virt-viewer}} can be used to view domains started with {{ic|virsh}}. Creation of domains is typically done either graphically with {{ic|virt-manager}} or with {{ic|virt-install}} (a command line program installed as part of the {{pkg|virt-install}} package).<br />
<br />
Creating a new domain typically involves using some installation media, such as an {{ic|.iso}} from the storage pool or an optical drive.<br />
<br />
Print active and inactive domains:<br />
<br />
# virsh list --all<br />
<br />
{{note|[[SELinux]] has a built-in exemption for libvirt that allows volumes in {{ic|/var/lib/libvirt/images/}} to be accessed. If using SELinux and there are issues with the volumes, ensure that volumes are in that directory, or ensure that other storage pools are correctly labeled.}}<br />
<br />
==== Create a new domain using virt-install ====<br />
<br />
{{Accuracy|{{ic|/usr/share/libosinfo}} isn't provided by any official packages, including {{Pkg|libosinfo}}.|section=Where_is_'/usr/share/libosinfo/db/oses/os.xml'?}}<br />
<br />
For an extremely detailed domain (virtual machine) setup, it is easier to [[#Create a new domain using virt-manager]]. However, basics can easily be done with {{ic|virt-install}} and still run quite well. Minimum specifications are {{ic|--name}}, {{ic|--memory}}, guest storage ({{ic|--disk}}, {{ic|--filesystem}}, or {{ic|--nodisks}}), and an install method (generally an {{ic|.iso}} or CD). See {{man|1|virt-install}} for more details and information about unlisted options.<br />
<br />
Arch Linux install (two GiB, qcow2 format volume create; user-networking):<br />
<br />
$ virt-install \<br />
--name arch-linux_testing \<br />
--memory 1024 \ <br />
--vcpus=2,maxvcpus=4 \<br />
--cpu host \<br />
--cdrom $HOME/Downloads/arch-linux_install.iso \<br />
--disk size=2,format=qcow2 \<br />
--network user \<br />
--virt-type kvm<br />
<br />
Fedora testing (Xen hypervisor, non-default pool, do not originally view):<br />
<br />
$ virt-install \<br />
--connect xen:/// \<br />
--name fedora-testing \<br />
--memory 2048 \<br />
--vcpus=2 \<br />
--cpu=host \<br />
--cdrom /tmp/fedora20_x84-64.iso \<br />
--os-type=linux --os-variant=fedora20 \<br />
--disk pool=testing,size=4 \<br />
--network bridge=br0 \<br />
--graphics=vnc \<br />
--noautoconsole<br />
$ virt-viewer --connect xen:/// fedora-testing<br />
<br />
Windows:<br />
<br />
$ virt-install \<br />
--name=windows7 \<br />
--memory 2048 \<br />
--cdrom /dev/sr0 \<br />
--os-variant=win7 \<br />
--disk /mnt/storage/domains/windows7.qcow2,size=20GiB \<br />
--network network=vm-net \<br />
--graphics spice<br />
<br />
{{Tip|Run {{ic|1=osinfo-query --fields=name,short-id,version os}} to get argument for {{ic|--os-variant}}; this will help define some specifications for the domain. However, {{ic|--memory}} and {{ic|--disk}} will need to be entered; one can look within the appropriate {{ic|/usr/share/libosinfo/db/oses/''os''.xml}} if needing these specifications. After installing, it will likely be preferable to install the [http://www.spice-space.org/download.html Spice Guest Tools] that include the [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization_Host_Configuration_and_Guest_Installation_Guide/form-Virtualization_Host_Configuration_and_Guest_Installation_Guide-Para_virtualized_drivers-Mounting_the_image_with_virt_manager.html VirtIO drivers]. For a Windows VirtIO network driver there is also {{Aur|virtio-win}}. These drivers are referenced by a {{ic|1=<model type='virtio' />}} in the guest's {{ic|.xml}} configuration section for the device. A bit more information can also be found on the [[QEMU#Preparing_a_Windows_guest|QEMU article]].}}<br />
<br />
Import existing volume:<br />
<br />
$ virt-install \<br />
--name demo \<br />
--memory 512 \<br />
--disk /home/user/VMs/mydisk.img \<br />
--import<br />
<br />
==== Create a new domain using virt-manager ====<br />
<br />
First, connect to the hypervisor (e.g. QEMU/KVM ''system'' or user ''session''), right click on a connection and select ''New'', and follow the wizard.<br />
<br />
* On the ''fourth step'', de-selecting ''Allocate entire disk now'' will make setup quicker and can save disk space in the interum; ''however'', it may cause volume fragmentation over time.<br />
* On the ''fifth step'', open ''Advanced options'' and make sure that ''Virt Type'' is set to ''kvm'' (this is usually the preferred method). If additional hardware setup is required, select the ''Customize configuration before install'' option.<br />
<br />
==== Manage a domain ====<br />
<br />
Start a domain:<br />
<br />
$ virsh start ''domain''<br />
$ virt-viewer --connect qemu:///session ''domain''<br />
<br />
Gracefully attempt to shutdown a domain; force off a domain:<br />
<br />
$ virsh shutdown ''domain''<br />
$ virsh destroy ''domain''<br />
<br />
Autostart domain on libvirtd start:<br />
<br />
$ virsh autostart ''domain''<br />
$ virsh autostart ''domain'' --disable<br />
<br />
Shutdown domain on host shutdown:<br />
<br />
: Running domains can be automatically suspended/shutdown at host shutdown using the {{ic|libvirt-guests.service}} systemd service. This same service will resume/startup the suspended/shutdown domain automatically at host startup. Read {{ic|/etc/conf.d/libvirt-guests}} for service options.<br />
<br />
Edit a domain's XML configuration:<br />
<br />
$ virsh edit ''domain''<br />
<br />
{{note|Virtual Machines started directly by QEMU are not managable by libvirt tools.}}<br />
<br />
=== Networks ===<br />
<br />
A [https://jamielinux.com/docs/libvirt-networking-handbook/ decent overview of libvirt networking].<br />
<br />
Four network types exist that can be created to connect a domain to:<br />
<br />
* bridge — a virtual device; shares data directly with a physical interface. Use this if the host has ''static'' networking, it does not need to connect other domains, the domain requires full inbound and outbound trafficking, and the domain is running on a ''system''-level. See [[Network bridge]] on how to add a bridge additional to the default one. After creation, it needs to be specified in the respective guest's {{ic|.xml}} configuration file. <br />
* network — a virtual network; has ability to share with other domains. Use a virtual network if the host has ''dynamic'' networking (e.g. NetworkManager), or using wireless.<br />
* macvtap — connect directly to a host physical interface.<br />
* user — local ability networking. Use this only for a user ''session''.<br />
<br />
{{ic|virsh}} has the ability to create networking with numerous options for most users, however, it is easier to create network connectivity with a graphic user interface (like {{ic|virt-manager}}), or to do so on [[#Create a new domain using virt-install|creation with virt-install]].<br />
<br />
{{note|libvirt handles DHCP and DNS with {{pkg|dnsmasq}}, launching a separate instance for every virtual network. It also adds iptables rules for proper routing, and enables the {{ic|ip_forward}} kernel parameter. This also means that having dnsmasq running on the host system is not necessary to support libvirt requirements (and could interfere with libvirt dnsmasq instances).}}<br />
<br />
==== IPv6 ====<br />
<br />
When adding an IPv6 address through any of the configuration tools, you will likely receive the following error:<br />
Check the host setup: enabling IPv6 forwarding with RA routes without accept_ra set to 2 is likely to cause routes loss. Interfaces to look at: ''eth0''<br />
<br />
Fix this by running the following command (replace {{ic|''eth0''}} with the name of your physical interface):<br />
<br />
# sysctl net.ipv6.conf.eth0.accept_ra=2<br />
<br />
=== Snapshots ===<br />
<br />
Snapshots take the disk, memory, and device state of a domain at a point-of-time, and save it for future use. They have many uses, from saving a "clean" copy of an OS image to saving a domain's state before a potentially destructive operation. Snapshots are identified with a unique name.<br />
<br />
Snapshots are saved within the volume itself and the volume must be the format: qcow2 or raw. Snapshots use deltas so they have the potentiality to not take much space.<br />
<br />
==== Create a snapshot ====<br />
<br />
{{Out of date|Some of this data appears to be dated.}}<br />
<br />
Once a snapshot is taken it is saved as a new block device and the original snapshot is taken offline. Snapshots can be chosen from and also merged into another (even without shutting down the domain).<br />
<br />
Print a running domain's volumes (running domains can be printed with {{ic|virsh list}}):<br />
<br />
{{hc|# virsh domblklist ''domain''|<nowiki><br />
Target Source<br />
------------------------------------------------<br />
vda /vms/domain.img<br />
</nowiki>}}<br />
<br />
To see a volume's physical properties:<br />
<br />
{{hc|# qemu-img info /vms/domain.img|<nowiki><br />
image: /vms/domain.img<br />
file format: qcow2<br />
virtual size: 50G (53687091200 bytes)<br />
disk size: 2.1G<br />
cluster_size: 65536<br />
</nowiki>}}<br />
<br />
Create a disk-only snapshot (the option {{ic|--atomic}} will prevent the volume from being modified if snapshot creation fails):<br />
<br />
# virsh snapshot-create-as ''domain'' snapshot1 --disk-only --atomic<br />
<br />
List snapshots:<br />
<br />
{{hc|# virsh snapshot-list ''domain''|<nowiki><br />
Name Creation Time State<br />
------------------------------------------------------------<br />
snapshot1 2012-10-21 17:12:57 -0700 disk-snapshot<br />
</nowiki>}}<br />
<br />
One can they copy the original image with {{ic|1=cp --sparse=true}} or {{ic|rsync -S}} and then merge the the original back into snapshot:<br />
<br />
# virsh blockpull --domain ''domain'' --path /vms/''domain''.snapshot1<br />
<br />
{{ic|domain.snapshot1}} becomes a new volume. After this is done the original volume ({{ic|domain.img}} and snapshot metadata can be deleted. The {{ic|virsh blockcommit}} would work opposite to {{ic|blockpull}} but it seems to be currently under development (including {{ic|snapshot-revert feature}}, scheduled to be released sometime next year.<br />
<br />
=== Other management ===<br />
<br />
Connect to non-default hypervisor:<br />
<br />
$ virsh --connect xen:///<br />
virsh # uri<br />
xen:///<br />
<br />
Connect to the QEMU hypervisor over SSH; and the same with logging:<br />
<br />
$ virsh --connect qemu+ssh://''username''@''host''/system<br />
$ LIBVIRT_DEBUG=1 virsh --connect qemu+ssh://''username''@''host''/system<br />
<br />
Connect a graphic console over SSH:<br />
<br />
$ virt-viewer --connect qemu+ssh://''username''@''host''/system ''domain''<br />
$ virt-manager --connect qemu+ssh://''username''@''host''/system ''domain''<br />
<br />
{{Note|If you are having problems connecting to a remote RHEL server (or anything other than Arch, really), try the two workarounds mentioned in {{bug|30748}} and {{bug|22068}}.}}<br />
<br />
Connect to the VirtualBox hypervisor (''VirtualBox support in libvirt is not stable yet and may cause libvirtd to crash''):<br />
<br />
$ virsh --connect vbox:///system<br />
<br />
Network configurations:<br />
<br />
$ virsh -c qemu:///system net-list --all<br />
$ virsh -c qemu:///system net-dumpxml default<br />
<br />
== Python connectivity code ==<br />
<br />
The {{Pkg|libvirt-python}} package provides a Python API in {{ic|/usr/lib/python3.x/site-packages/libvirt.py}}.<br />
<br />
General examples are given in {{ic|/usr/share/doc/libvirt-python-''your_libvirt_version''/examples/}}<br />
<br />
Unofficial example using {{Pkg|qemu}} and {{Pkg|openssh}}:<br />
<br />
{{bc|<nowiki><br />
#! /usr/bin/env python3<br />
import socket<br />
import sys<br />
import libvirt<br />
<br />
conn = libvirt.open("qemu+ssh://xxx/system")<br />
print("Trying to find node on xxx")<br />
domains = conn.listDomainsID()<br />
for domainID in domains:<br />
domConnect = conn.lookupByID(domainID)<br />
if domConnect.name() == 'xxx-node':<br />
print("Found shared node on xxx with ID {}".format(domainID))<br />
domServ = domConnect<br />
break<br />
</nowiki>}}<br />
<br />
== UEFI Support ==<br />
<br />
Libvirt can support UEFI virtual machines through QEMU and [https://github.com/tianocore/edk2 OVMF].<br />
<br />
Install the {{Pkg|ovmf}} package.<br />
<br />
[[Restart]] {{ic|libvirtd}}.<br />
<br />
Now you are ready to create a UEFI virtual machine. Create a new virtual machine through {{Pkg|virt-manager}}. When you get to the final page of the 'New VM' wizard, do the following: <br />
<br />
* Click 'Customize before install', then select 'Finish'<br />
* On the 'Overview' screen, Change the 'Firmware' field to select the 'UEFI x86_64' option.<br />
* Click 'Begin Installation'<br />
* The boot screen you'll see should use linuxefi commands to boot the installer, and you should be able to run efibootmgr inside that system, to verify that you're running an UEFI OS. <br />
<br />
For more information about this, refer to [https://fedoraproject.org/wiki/Using_UEFI_with_QEMU this fedora wiki page].<br />
<br />
== PulseAudio ==<br />
<br />
The PulseAudio daemon normally runs under your regular user account, and will only accept connections from the same user. This can be a problem if QEMU is being run as root through [[libvirt]]. To run QEMU as a regular user, edit {{ic|/etc/libvirt/qemu.conf}} and set the {{ic|user}} option to your username.<br />
<br />
user = "dave"<br />
<br />
You will also need to tell QEMU to use the PulseAudio backend and identify the server to connect to. First add the qemu namespace to you domain.<br />
<br />
<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'><br />
<br />
Then add the following section to your domain configuration using {{ic|virsh edit}}.<br />
<br />
<qemu:commandline><br />
<qemu:env name='QEMU_AUDIO_DRV' value='pa'/><br />
<qemu:env name='QEMU_PA_SERVER' value='/run/user/1000/pulse/native'/><br />
</qemu:commandline><br />
<br />
{{ic|1000}} is your user id. Change it if necessary.<br />
<br />
== Hypervisor CPU use ==<br />
Default VM configuration generated by virt-manager may cause rather high (10-20%) CPU use caused by the QEMU process.<br />
If you plan to run the VM in headless mode, consider removing some of the unnecessary devices.<br />
<br />
== See also ==<br />
<br />
* [http://libvirt.org/drvqemu.html Official libvirt web site]<br />
* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Virtualization_Deployment_and_Administration_Guide/index.html Red Hat Virtualization Deployment and Administration Guide]<br />
* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Virtualization_Tuning_and_Optimization_Guide/index.html Red Hat Virtualization Tuning and Optimization Guide]<br />
* [http://docs.slackware.com/howtos:general_admin:kvm_libvirt Slackware KVM and libvirt]<br />
* [http://www-01.ibm.com/support/knowledgecenter/linuxonibm/liaat/liaatkvm.htm IBM KVM]<br />
* [https://jamielinux.com/docs/libvirt-networking-handbook/ libvirt Networking Handbook]</div>Kgizdovhttps://wiki.archlinux.org/index.php?title=Package_Maintainers&diff=553238Package Maintainers2018-11-05T16:00:23Z<p>Kgizdov: Add Konstantin Gizdov as a TU</p>
<hr />
<div>[[Category:Arch development]]<br />
[[Category:Teams]]<br />
[[es:Trusted Users]]<br />
[[fr:TU]]<br />
[[ja:Trusted Users]]<br />
[[pt:Trusted Users]]<br />
The [https://www.archlinux.org/people/trusted-users/ Trusted Users] serve the following purposes:<br />
# Maintain the ''community'' repository as an intermediary between Arch Linux's [[official repositories]] and the unsupported package collection in the [[AUR]].<br />
# Maintain, manage, and watch over the operation of the [[AUR]].<br />
<br />
== How do I become a TU? ==<br />
The ''minimum'' requirements to becoming a TU are as follows:<br />
* know basic shell scripting<br />
* maintain a few packages in AUR with clean, high-quality PKGBUILDs<br />
* basic community involvement (mailing list, forums, IRC)<br />
* know Google-Fu<br />
* a general idea of the kind of packages you want to maintain (basically, why do you want to become TU?)<br />
<br />
Even though you could become a TU by merely fulfilling those minimum requirements, the people judging you during the [https://aur.archlinux.org/trusted-user/TUbylaws.html#_standard_voting_procedure standard voting procedure] might expect more from you. Such as:<br />
* involvement in the bug tracker (reporting, research, info)<br />
* patches for Arch projects<br />
* involvement in a few open-source projects (even if they are your own)<br />
<br />
If you still feel up to becoming a TU after reading these lines, the first step is to find a TU who agrees to sponsor you. Once sponsored, you should write a witty application signed with your GPG key to the aur-general mailing list.<br />
<br />
{{Note|Should the TU you contact decline to sponsor your application, you should make this fact known if you seek sponsorship from another TU.}}<br />
<br />
For more information, see the [https://aur.archlinux.org/trusted-user/TUbylaws.html Trusted User Bylaws] and [[AUR Trusted User Guidelines]].<br />
<br />
== Active Trusted Users ==<br />
{| class="wikitable"<br />
! Nick<br />
! Name<br />
! E-Mail<br />
|-<br />
|[https://aur.archlinux.org/packages/?K=Alad&SeB=m alad]||[[User:Alad|Alad Wenter]]||alad@archlinux.org<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=alucryd&SeB=m alucryd]||Maxime Gauduin||alucryd@archlinux.org<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=anatolik&SeB=m anatolik]||Anatol Pomozov||anatol dot pomozov + arch at gmail<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=andrewSC&SeB=m andrewSC]||Andrew Crerar||andrew (at) crerar (dot) io<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=anthraxx&SeB=m anthraxx]||[[User:anthraxx|Levente Polyak]]||anthraxx [at] archlinux [dot] org<br />
|-<br />
|[https://aur.archlinux.org/packages/?SeB=m&K=arcanis arcanis]||Evgeniy Alekseev||arcanis DOT arch AT gmail DOT com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=ArchangeGabriel&SeB=m ArchangeGabriel]||Bruno Pagani||bruno.n.pagani@gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages/?SeB=m&K=arojas arojas]||Antonio Rojas||arojas@archlinux.org<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Barthalion&SeB=m Barthalion]||Bartłomiej Piotrowski||spam@bpiotrowski.pl<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=BlackIkeEagle&SeB=m BlackIkeEagle]||[[User:BlackEagle|Ike Devolder]]||ike DOT devolder AT gmail DOT com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=bluewind&SeB=m Bluewind]||Florian Pritz|| bluewind@xinu.at<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=City-busz&SeB=m City-busz]||[[User:City-busz|Balló György]]||ballogyor+arch at gmail dot com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=coderobe&SeB=m coderobe]||Robin Broda||ebova ng oebqn qbg zr (rot13)<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=ConnorBehan&SeB=m ConnorBehan]||Connor Behan||connor.behan@gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=lfleischer&SeB=m lfleischer]||Lukas Fleischer||lfleischer at archlinux dot org<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=eworm&SeB=m eworm]||Christian Hesse||mail@eworm.de<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Dragonlord&SeB=m Dragonlord]||[[User:Drag0nl0rd|Jaroslav Lichtblau]]||dragonlord @ aur archlinux org<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=dvzrv&SeB=m dvzrv]||[[User:Davezerave|David Runge]]|| dave@sleepmap.de<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=eschwartz&SeB=m eschwartz]||Eli Schwartz|| eschwartz@archlinux.org<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=escondida&SeB=m escondida]||Ivy Foster||code @ escondida dot tk<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=farseerfc&SeB=m farseerfc]||Jiachen Yang||farseerfc[at]gmail[dot]com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=felixonmars&SeB=m felixonmars]||Felix Yan||felixonmars@archlinux.org<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=FFY00&SeB=m FFY00]||Filipe Laíns||[mailto:lains@archlinux.org lains@archlinux.org]<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Foxboron&SeB=m Foxboron]||Morten Linderud||foxboron@archlinux.org<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=foxxx0&SeB=m foxxx0]||Thore Bödecker||me [at] foxxx0 [dot] de<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=giniu&SeB=m giniu]||[[User:giniu|Andrzej Giniewicz]]||gginiu@gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages/?SeB=m&K=grazzolini grazzolini]||Giancarlo Razzolini||grazzolini [at] gmail [dot] com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=heftig&SeB=m heftig]||Jan Alexander Steffens||jan.steffens@gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=jelly&SeB=m jelly]||Jelle van der Waa|| jelle vdwaa nl<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=jleclanche&SeB=m jleclanche]||[[User:jleclanche|Jerome Leclanche]]||jerome''@''leclan''.''ch<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=jsteel&SeB=m jsteel]||Jonathan Steel||jsteel at aur.archlinux.org<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=kgizdov&SeB=m kgizdov]||Konstantin Gizdov||arch@kge.pw<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=keenerd&SeB=m keenerd]||Kyle Keen||keenerd@gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Kyrias&SeB=m Kyrias]||[[User:Kyrias|Johannes Löthberg]]||johannes@kyriasis.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=lordheavy&SeB=m Lordheavy]||[[User:Lordheavy|Laurent Carlier]]||lordheavym at gmail com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=mtorromeo&SeB=m mtorromeo]||Massimiliano Torromeo||massimiliano.torromeo@gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Muflone&SeB=m Muflone]||Fabio Castelli||webreg (at) vbsimple.net<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=NicoHood&SeB=m NicoHood]||NicoHood||archlinux (cat) nicohood (dog) de<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=sangy&SeB=m sangy]||Santiago Torres-Arias|| santiago @ archlinux ⇶ org<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=schivmeister&SeB=m schivmeister]||[[User:Schivmeister|Ray Rashif]]||schiv archlinux org<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=schuay&SeB=m schuay]||Jakob Gruber||jakob.gruber@gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=seblu&SeB=m seblu]||Sébastien Luttringer||s е b l u ''at'' a r c h l і n ux ''dot'' o r g<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=sergej&SeB=m sergej]||[[User:Sergej|Sergej Pupykin]]||pupykin.s+arch@gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=shibumi&SeB=m shibumi]||[[User:shibumi|Christian Rebischke]]||Chris.Rebischke [at] archlinux [dot] org<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=stativ&SeB=m stativ]||Lukas Jirkovsky||l.jirkovsky strange_curved_character gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=svenstaro&SeB=m svenstaro]||[[User:svenstaro|Sven-Hendrik Haase]]||sh@lutzhaase.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=tensor5&SeB=m tensor5]||Nicola Squartini||tensor5@gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=wild&SeB=m wild]||[[User:vild|Dan Printzell]]||[mailto:arch@vild.io arch@vild.io]<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Xyne&SeB=m Xyne]||Xyne||ca . archlinux @ xyne, in reverse order<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=xyproto&SeB=m xyproto]||Alexander F. Rødseth||xyproto@archlinux.org<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=yan12125&SeB=m yan12125]||Chih-Hsuan Yen||yan12125@gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=zorun&SeB=m zorun]||Baptiste Jonglez||archlinux bitsofnetworks org<br />
|}<br />
<br />
== Inactive Trusted Users ==<br />
{| class="wikitable"<br />
! Nick<br />
! Name<br />
! E-Mail<br />
! Comments/Reference<br />
|-<br />
|}<br />
<br />
== Some Past Trusted Users ==<br />
{| class="wikitable"<br />
! Nick<br />
! Name<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=abhidg&SeB=m abhidg]||Abhishek Dasgupta<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Allan&SeB=m Allan]||Allan McRae<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Ambrevar&SeB=m Ambrevar]||[[User:Ambrevar|Pierre Neidhardt]]<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=anders&SeB=m anders]||Anders Bergh<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=angvp&SeB=m angvp]||[[User:Angvp|Angel Velásquez]]<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Atsutane&SeB=m Atsutane]||Thorsten Töpper<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=bardo&SeB=m bardo]||Corrado Primier<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=ndr&SeB=m ndr]||Andrea Scarpino<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=bfinch&SeB=m bfinch]||Bob Finch<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=brain0&SeB=m brain0]||Thomas Bächler<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=bjorn&SeB=m bjorn]||[[User:Bjørn|Bjørn Lindeijer]]<br />
|- <br />
|[https://aur.archlinux.org/packages/?K=Cinelli&SeB=m cinelli] ||Federico Cinelli<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=codemac&SeB=m codemac]||Jeff Mickey<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=cmb&SeB=m cmb]||Chris Brannon<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Daenyth&SeB=m Daenyth]||Daenyth Blank<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=DaNiMoTh&SeB=m DaNiMoTh]||JJ. DaNiMoTh<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=dejari&SeB=m dejari]||Leslie P. Polzer<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=dsa&SeB=m dsa]||Douglas Soares de Andrade<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=dtw&SeB=m dtw]||Phil Dillon-Thiselton<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=elasticdog&SeB=m elasticdog]||Aaron Bull Schaefer<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=encelo&SeB=m encelo]||Angelo Theodorou<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=even&SeB=m even] ||Kessia Pinheiro<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=faidoc&SeB=m Faidoc]||Alexandre Filgueira<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=falconindy&SeB=m falconindy]||Dave Reisner<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=foutrelis&SeB=m foutrelis]||Evangelos Foutras<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=filoktetes&SeB=m filoktetes]||Robert Emil Berge<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=firmicus&SeB=m firmicus]||François Charette<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=flexiondotorg&SeB=m flexiondotorg]||Martin Wimpress<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=ganja_guru&SeB=m ganja_guru]||Varun Acharya<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=gcarrier&SeB=m gcarrier]||Geoffroy Carrier<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Ghost1227&SeB=m Ghost1227]||Dan Griffiths<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=gtmanfred&SeB=m gtmanfred]||Daniel Wallace<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=gummibaerchen&SeB=m gummibaerchen]||Timm Preetz<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=hdoria&SeB=m hdoria]||Hugo Doria<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=iphitus&SeB=m iphitus]||James Rayner<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=itsbrad212&SeB=m itsbrad212]||Brad Fanella<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=kaitocracy&SeB=m kaitocracy]||Kaiting Chen<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=louipc&SeB=m louipc]||Loui Chang<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=mOLOk&SeB=m mOLOk]||Alessio Bolognino<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=nesl247&SeB=m nesl247]||Alex Heck<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Neverth&SeB=m Neverth]||Mikko Seppälä<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Partition&SeB=m Partition]||Mateusz Herych<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=petelewis&SeB=m petelewis]||Peter Lewis<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=PirateJonno&SeB=m PirateJonno]||Jonathan Conder<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=phrakture&SeB=m phrakture]||Aaron Griffin<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Pierre&SeB=m Pierre]||Pierre Schmitz<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=pizzapunk&SeB=m pizzapunk]||Alexander Fehr<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=pjmattal&SeB=m pjmattal]||Paul Mattal<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=pressh&SeB=m pressh]||Ronald van Haren<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Ranguvar&SeB=m Ranguvar]||Devin Cofer<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Romashka&SeB=m Romashka]||Roman Kyrylych<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=shastry&SeB=m shastry]||Vinay S Shastry<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Snowman&SeB=m Snowman]||Eric Bélanger<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=shinlun&SeB=m shinlun]||Shinlun Hsieh<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=speps&SeB=m speps]||SpepS<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=StefanHusmann&SeB=m StefanHusmann]||Stefan Husmann<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=STiAT&SeB=m STiAT]||Georg Grabler<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=swiergot&SeB=m swiergot]||Jaroslaw Swierczynski<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=tardo&SeB=m tardo]||Shehzad Qureshi<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=td123&SeB=m td123]||Thomas Dziedzic<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=thatch45&SeB=m thatch45]||Thomas S Hatch<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=thotypous&SeB=m thotypous]||Paulo Matias<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=tredaelli&SeB=m tredaelli]||Timothy Redaelli<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=vegai&SeB=m vegai]||Vesa Kaihlavirta<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=voidnull&SeB=m voidnull]||Giovanni Scafora<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=wizzomafizzo&SeB=m wizzomafizzo]||Callan Barrett<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=wonder&SeB=m wonder]|| Ionut Biru<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Xilon&SeB=m Xilon]||Sebastian Nowicki<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=xterminus&SeB=m xterminus]||Charles Mauch<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=zeus&SeB=m zeus]||Zhukov Pavel<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Dicebot&SeB=m Dicebot]||Mihails Strasuns<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=thestinger&SeB=m thestinger]||Daniel Micay<br />
|}</div>Kgizdovhttps://wiki.archlinux.org/index.php?title=Dell_XPS_13_(9350)&diff=461848Dell XPS 13 (9350)2017-01-07T14:31:57Z<p>Kgizdov: /* TPM */ added useful packages for TPM 1.2</p>
<hr />
<div>[[Category:Dell]]<br />
[[ja:Dell XPS 13 (9350)]]<br />
{{Note|This page refers to the early 2016 model of XPS 13. For the late 2016 model see [[Dell XPS 13 (9360)]].}}<br />
{| class="wikitable" style="float: right;"<br />
| '''Device''' || '''Status''' || '''Modules'''<br />
|-<br />
| Video || {{G|Working}} || i915<br />
|-<br />
| External screen || {{Y|Partial or does not work at all}} || ?<br />
|-<br />
| Wireless || {{G|Working}} || brcmfmac<br />
|-<br />
| Bluetooth || {{G|Works after installing firmware}}|| btbcm<br />
|-<br />
| Audio || {{G|Working}} || snd_hda_intel<br />
|-<br />
| Touchpad || {{G|Working}} || ?<br />
|-<br />
| Webcam || {{G|Working}} || uvcvideo<br />
|-<br />
| Card Reader || {{G|Working}} || rtsx_pci<br />
|-<br />
| Wireless switch || {{G|Working}} || intel_hid<br />
|-<br />
| Function/Multimedia Keys || {{G|Working}} || ?<br />
|-<br />
| TPM 1.2/2.0 || {{G|Working}} || tpm<br />
|}<br />
<br />
The Dell XPS 13 2016 (9350) is the third-generation model of the XPS 13 line. The laptop is available in both a standard edition with Windows installed as well as a Developer Edition which only differs in that it comes with Ubuntu installed as well as the Broadcom WiFi card replaced with an Intel WiFi card. Just like the older versions ([[Dell XPS 13 (9333)]] and [[Dell XPS 13 (9343)]]) it can be bought in different hardware configurations.<br />
<br />
The installation process for Arch on the XPS 13 does not differ from any other PC. For installation help, please see the [[Installation guide]] and [[UEFI]]. This page covers the current status of hardware support on Arch, as well as post-installation recommendations.<br />
<br />
As of kernel 4.3, the Intel Skylake architecture is supported.<br />
<br />
== Content adaptive brightness control ==<br />
In the XPS 13 the display panels (both FHD and QHD+) come with adaptive brightness embedded in the panel firmware, this "content adaptive brightness control" (usually referred to as CABC or DBC) will adjust the screen brightness depending on the content displayed on the screen and will generally be found undesirable, especially for Linux users who are likely to be switching between dark and light screen content. Dell has issued a fix for this however it is only available to run in Windows and for the QHD+ model of the laptop so this precaution should be taken before installing Linux, the FHD model of the XPS 13 (9350) cannot be fixed. This is not a problem with the panel but rather a problem with the way the panels are configured for the XPS 13, as the same panel exists in the Dell's Latitude 13 7000 series (e7370) FHD model but with CABC disabled. The fix is available directly from [http://www.dell.com/support/home/uk/en/ukdhs1/Drivers/DriversDetails?driverId=PWD5K&fileId=3505631210&osCode=W764&productCode=xps-13-9350-laptop&languageCode=en&categoryId=AP Dell].<br />
<br />
== BIOS ==<br />
=== USB not found ===<br />
It may happen that the Arch Linux USB won't be recognized. You have to disable secure boot (Secure Boot > Disable) and then enable the legacy (General > Advanced Boot Options > Enable Legacy Option ROMs).<br />
<br />
=== No UEFI system found ===<br />
Sometimes the BIOS UEFI does not respect the efivars. In this case you have manually add your efi file in BIOS boot options by going to General > Boot Sequence > Add Boot Option.<br />
<br />
=== Updates ===<br />
[http://downloads.dell.com/FOLDER04068454M/1/XPS_9350_1.4.12.exe BIOS update 1.4.12] was released on 2016-12-21. Store the update binary on your EFI partition ({{ic|/boot/EFI}}) or on a USB flash drive, reboot, and choose BIOS Update in the F12 boot menu. This might also help if your machine will not resume after suspend.<br />
<br />
=== Firmware Updates ===<br />
Dell provides firmware updates via Linux Vendor Firmware Service (LVFS). Refer to [[Flashing BIOS from Linux#fwupd]] for additional information. A package is readily available at {{aur|fwupd}}.<br />
<br />
== Thunderbolt 3 / USB 3.1 ==<br />
<br />
The USB-C port supports Thunderbolt 3, Displayport-over-USB-C and USB power delivery as well as USB 3.1.<br />
<br />
In the event of devices not working correctly, ensure that you have updated to the latest BIOS (above) and Thunderbolt firmware (below).<br />
<br />
[http://downloads.dell.com/FOLDER03798029M/1/Intel_TBT3_FW_UPDATE_NVM16_A04_2.16.01.003.exe Thunderbolt 3 Firmware Update 2.16.01.003, A04] was released on 2016-08-10. Unlike the BIOS update, this is a graphical application which must be run in a modern Windows environment (MS-DOS will not suffice).<br />
<br />
Hotplug support for this port requires a [https://bugzilla.kernel.org/show_bug.cgi?id=115121 bug fix] which landed in kernel version 4.7. It also requires the kernel to be built with <tt>CONFIG_PCI_HOTPLUG=y</tt>.<br />
<br />
=== External screen ===<br />
<br />
Support for external screens either using an USB-C to HDMI or USB-C to Mini Display ports adapters may not be working properly. Commonly the screen when plugged is reported to either:<br />
<br />
* display an image for a few milliseconds then switch to a black screen;<br />
* have no image at all;<br />
* being flickering after a few minutes to the extent this is basically unusable.<br />
<br />
Refer to the [https://bbs.archlinux.org/viewtopic.php?id=205147 according Arch Forum entry] for an exhaustive discussion about working adapters and the [http://en.community.dell.com/techcenter/os-applications/f/4613/t/19988851 Dell forum entry].<br />
<br />
== SATA controller ==<br />
When the SATA-controller is set to {{ic|RAID On}} in Bios, the hard disk (at least the SSD) is not recognized. Set to {{ic|Off}} or {{ic|AHCI}} ({{ic|AHCI}} is recommended) before attempting to install Arch.<br />
<br />
=== Dual booting Linux and Windows ===<br />
In order to boot into Windows properly without getting an {{ic|INACCESSIBLE_BOOT_DEVICE}} error with disabled {{ic|RAID}} you must configure Windows to use the {{ic|AHCI}}-speaking SATA storage controller, assuming you used {{ic|AHCI}} for installing Linux. The driver is effectively disabled even though it is installed. Either of the following methods were reported to activate the drivers without reinstallation (your mileage may vary):<br />
<br />
* [http://www.tenforums.com/drivers-hardware/15006-attn-ssd-owners-enabling-ahci-mode-after-windows-10-installation.html booting into safe mode and back]<br />
* [https://samnicholls.net/2016/01/14/how-to-switch-sata-raid-to-ahci-windows-10-xps-13/ Selecting {{ic|Microsoft Storage Spaces Controller}} in Windows Device Manager]<br />
* [http://www.tenforums.com/tutorials/22631-ahci-enable-windows-8-windows-10-after-installation.html Modifying registry entries]<br />
* [http://superuser.com/questions/471102/change-from-ide-to-ahci-after-installing-windows-8/471108#471108 Modifying other registry entries]<br />
<br />
Consult the [https://support.microsoft.com/en-us/kb/2795397 microsoft support] page for additional information. Be aware that some manufactures propagate reinstalling Windows to be the only solution, which it is not.<br />
<br />
== NVM Express SSD ==<br />
=== Cannot find root device ===<br />
The location of the {{ic|nvme}} module for [[wikipedia:NVM_Express|"NVM Express"]] SSD has changed between {{Pkg|linux}} kernel version 4.3 and 4.4. If you experience "cannot find root device" on boot, it may be due to the [https://bugs.archlinux.org/task/47761 {{ic|nvme}} module not being present in {{ic|initramfs}}]. In this case, the following may resolve your issue.<br />
<br />
Edit your {{ic|/etc/mkinitcpio.conf}} file:<br />
...<br />
MODULES="... nvme"<br />
...<br />
<br />
Then update the bootloader.<br />
<br />
# mkinitcpio -p linux<br />
<br />
where {{ic|linux}} is the name of the image loaded on boot. If you installed {{AUR|linux-mainline}} then change that to {{ic|linux-mainline}}.<br />
<br />
=== Note on Mount Options ===<br />
<br />
Using the {{ic|discard}} mount option for your filesystem is not recommended, as mentioned in [[Solid_State_Drives#Continuous TRIM|this warning]] and [https://bbs.archlinux.org/viewtopic.php?pid=1593544#p1593544 the forum]. See also [[Solid State Drives/NVMe#Discards]] for further information.<br />
<br />
=== NVME Power Saving Patch ===<br />
<br />
Andy Lutomirski has released version 4 of his patchset which fixes powersaving for NVME devices in linux. Currently, this patch is not merged into mainline yet. Until it lands in mainline kernel use the AUR package below. <br />
{{App|Linux-nvme|Mainline linux kernel patched with Andy's patch for NVME powersaving APST.|https://github.com/damige/linux-nvme|{{AUR|linux-nvme}}}}<br />
<br />
== Wireless ==<br />
<br />
For the non-developer edition, the built-in Broadcom BCM4350 is now supported in the current {{Pkg|linux}} kernel (as of version 4.4.1-1). The wireless module {{ic|brcmfmac}} also needs the firmware {{ic|brcmfmac4350-pcie.bin}} from the related {{Pkg|linux-firmware}} package.<br />
<br />
The Broadcom adapter does not report its regulatory country and so, by default, the global settings for channels and frequencies will be set. See [[Wireless network configuration#Respecting the regulatory domain]] for more information about how this can be changed.<br />
<br />
== Bluetooth ==<br />
<br />
=== Intel WiFi ===<br />
If your WiFi card supports Bluetooth, then the BT interface should be available out-of-the-box, as the required firmware is included in {{pkg|linux-firmware}}.<br />
<br />
=== Broadcom Wifi ===<br />
Bluetooth should work right away. Load the module {{ic|btusb}} and {{ic|bluetooth}} if it was not already and [[start]]/[[enable]] {{ic|bluetooth.service}}. Refer to [[Bluetooth]] for more information and configuration options.<br />
<br />
==== Wireless headset: strange bluetooth behavior ====<br />
<br />
If your Bluetooth behaves unstable, such as connection loss, stuttering sound. being able to connect but not to listen through it, etc. you probably need the proprietary firmware.<br />
<br />
The Broadcom Bluetooth firmware is not available in the kernel (the same as for the 2015 model [http://tech.sybreon.com/2015/03/15/xps13-9343-ubuntu-linux/ source]), therefore you will have to retrieve it from a Windows [http://downloads.dell.com/FOLDER03272920M/1/9350_Network_Driver_XMJK7_WN32_12.0.1.720_A00.EXE .exe]. You need to extract the {{ic|.exe}} file with {{Pkg|p7zip}} and then convert it to a {{ic|.hcd}} file with ''hex2hcd'' from {{Pkg|bluez-utils}}:<br />
<br />
$ 7z x 9350_Network_Driver_XMJK7_WN32_12.0.1.720_A00.EXE<br />
$ cp Win32/BCM4350C5_003.006.007.0095.1703.hex ./<br />
$ hex2hcd BCM4350C5_003.006.007.0095.1703.hex<br />
# mv BCM4350C5_003.006.007.0095.1703.hcd /lib/firmware/brcm/BCM-0a5c-6412.hcd<br />
<br />
Alternatively, you may simply install {{AUR|bcm4350-firmware}}.<br />
<br />
After a reboot, the firmware should be available for your Bluetooth interface.<br />
<br />
== Video ==<br />
The video should work with the {{ic|i915}} driver of the current {{Pkg|linux}} kernel. Consult [[Intel graphics]] for a detailed installation and configuration guide as well as for [[Intel graphics#Troubleshooting|Troubleshooting]].<br />
<br />
=== Blank screen issue after booting ===<br />
If using "late start" [[KMS]] (the default) and the screen goes blank when loading modules, it may help to add {{ic|i915}} and {{ic|intel_agp}} to the initramfs or using a special [[kernel parameter]]. Consult [[Intel graphics#Blank screen during boot, when "Loading modules"]] for more information about the kernel paramter way and have a look at [[Kernel mode setting#Early KMS start]] for a guide on how to setup the modules for the initramfs.<br />
<br />
=== Linux kernel 4.8 or later power savings ===<br />
<br />
{{warning|The following options of the {{ic|i915}} module taint the kernel, use at your own risks!}}<br />
<br />
====RC6====<br />
{{ic|i915.enable_rc6&#61;1}} seems to be stable, setting the value to a higher number will be ignored is therefore confusing, the deeper GPU power states that this option enables (RC6p and RC6pp) do not exist on gen7+ hardware.[https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/i915/i915_drv.h#n2862][https://lists.freedesktop.org/archives/intel-gfx/2012-June/018383.html].<br />
<br />
====Panel Self Refresh====<br />
{{ic|i915.enable_psr&#61;1}} allows for some really nice power savings by leaving the package longer in more efficient C-states. However, users experience freezes for a few seconds with this option fairly often, setting the value to [https://patchwork.kernel.org/patch/8182841/ 2 or 3] may yield to similar power savings but without the freezes.<br />
{{ic|i915.disable_power_well&#61;0}} with {{ic|i915.enable_psr&#61;1 i915.enable_rc6&#61;1}} also seems to be a stable configuration for PSR.<br />
<br />
====Frame Buffer Compression====<br />
{{ic|i915.enable_fbc&#61;1}} is stable but does not seem to yield significant power saving results.<br />
<br />
====GuC====<br />
[https://01.org/linuxgraphics/intel-linux-graphics-firmwares GuC] loading with {{ic|i915.enable_guc_loading&#61;1 i915.enable_guc_submission&#61;1}} seems stable too.<br />
<br />
=== Linux kernel 4.3 or earlier ===<br />
<br />
If you are using an older kernel 4.3 or earlier, you also require the kernel parameter {{ic|i915.preliminary_hw_support&#61;1}}, see [[Intel graphics#Skylake support]]. (For later kernels 4.3+ or {{AUR|linux-bcm4350}} the parameter is unnecessary.)<br />
<br />
=== Linux kernel 4.5 or earlier ===<br />
<br />
If you have the newer i7-6560 CPU with Iris 540 graphics, the GPU hangs every few minutes with kernel versions before 4.6. This is probably due to this bug https://bugs.freedesktop.org/show_bug.cgi?id=94161 and can be countered by either disabling DRI in your Xorg configuration:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-intel.conf|<br />
Section "Device"<br />
Identifier "Intel Graphics"<br />
Driver "intel"<br />
Option "DRI" "false"<br />
EndSection<br />
}}<br />
<br />
or by adding {{ic|1=i915.enable_rc6=0}} to the kernel boot parameters.<br />
<br />
== Touchpad ==<br />
Only key-presses work out of the box. Installing {{pkg|xf86-input-libinput}} is sufficient for proper mouse support plus it also handles the touchscreen - see [[libinput]] for configuration. Features such as tap-to-click are usually adjustable within the [[desktop environment]].<br />
<br />
Alternatively you may want to install {{pkg|xf86-input-synaptics}} as driver but "it is on maintenance mode and {{pkg|xf86-input-libinput}} must be preferred over" (installation note from the package itself). Plus it may lack the ability to be easily adjustable within your [[desktop environment]] (see [[Dell Studio XPS 13]]). Restarting the X server might be required.<br />
<br />
=== Remove psmouse errors from dmesg ===<br />
<br />
If {{ic|<nowiki>dmesg | grep -i psmouse</nowiki>}} returns an error, but your touchpad still works, then it might be a good idea to disable {{ic|psmouse}}. First create a config file:<br />
<br />
# nano /etc/modprobe.d/modprobe.conf<br />
<br />
blacklist psmouse<br />
<br />
Then add this file to {{ic|/etc/mkinitcpio.conf}}:<br />
<br />
...<br />
FILES="/etc/modprobe.d/modprobe.conf"<br />
...<br />
<br />
Rebuild your initial ramdisk image (see [[Mkinitcpio#Image creation and activation]]).<br />
<br />
=== Gestures ===<br />
<br />
Refer to [[libinput#Gestures]] for information about the current development state and available methods.<br />
<br />
== Sound ==<br />
<br />
=== Hissing/Crackling noises when using headphones ===<br />
<br />
Some people reported white hissing/crackling noises when using headphones. To get rid of them you can run {{ic|alsamixer}} from {{Pkg|alsa-utils}}.<br />
Select your soundcard with F6 and set the headset-gain to 22 (3rd lever from the left) or use the {{ic|amixer}} command:<br />
<br />
$ amixer -c 0 cset 'numid=10' 1<br />
numid=10,iface=MIXER,name='Headphone Mic Boost Volume'<br />
; type=INTEGER,access=rw---R--,values=2,min=0,max=3,step=0<br />
: values=1,1<br />
| dBscale-min=0.00dB,step=10.00dB,mute=0<br />
<br />
Unfortunately [[PulseAudio]] will override the above setting every time you log in/out of your environment (or every time the PulseAudio service is restarted), even if the {{ic|alsa-restore.service}} is enabled at [[start]] up.<br />
<br />
To work around this issue, edit {{ic|/usr/share/pulseaudio/alsa-mixer/paths/analog-input-headphone-mic.conf}} and comment out the section {{ic|[Element Headphone Mic Boost]}}:<br />
<br />
---<br />
#[Element Headphone Mic Boost]<br />
#required-any = any<br />
#switch = select<br />
#volume = merge<br />
#override-map.1 = all<br />
#override-map.2 = all-left,all-right<br />
---<br />
<br />
Similarly in {{ic|/usr/share/pulseaudio/alsa-mixer/paths/analog-input-internal-mic.conf}}, comment out the same section:<br />
<br />
---<br />
#[Element Headphone Mic Boost]<br />
#switch = off<br />
#volume = off<br />
---<br />
<br />
This will prevent PulseAudio to fiddle with the gain setting at all.<br />
<br />
{{Note|Unfortunately, you must make the same modifications every time the PulseAudio package is updated. Additionally, this will entirely disable the internal microphone.}}<br />
<br />
== Microphone ==<br />
{{Note| Not all hardware has the "Digital" channel}}<br />
For ALSA, increase "Digital" channel for microphone to work.<br />
<br />
== TPM ==<br />
<br />
As shipped the Trusted Platform Module (TPM) can be configured easily following the steps at [[Trusted Platform Module]] and requires no otherwise special configuration. Handy packages to use with the TPM are {{AUR|tpm-tools}} and {{AUR|trousers}}.<br />
<br />
=== TPM 2.0 ===<br />
<br />
Originally the Dell XPS 13 (9350) shipped with TPM 1.2 - the TPM chip was configured to support the TPM Standard version 1.2. However, on 6 Jan 2017 Dell released a [http://www.dell.com/support/home/uk/en/ukdhs1/Drivers/DriversDetails?driverId=N8P80 firmware update] (internal version 1.3.1.0_V1) for the TPM chip that converts it to support the feature set of TPM Standard version 2.0. Unfortunately, as of this moment the update cannot be applied through Linux or the BIOS direct flashing capabilities. The only way to install it seems to be to apply it through a running Windows OS. The easiest method is to run a temporary Windows installation on a USB drive, boot into it and run the update from there. {{Warning| It should be noted that this update is irreversible once applied. It also requires that the TPM memory and configuration is completely cleared.}}<br />
{{Note| As for BIOS updates, please make sure the laptop is plugged in to a power source and that power source is stable.}}<br />
<br />
To install the update one can follow the instructions on the above mentioned firmware update page to clear and reset the TPM chip and initiate the update. Users intending to later use the device in Linux, can skip the last steps 11 & 12 from section "Disable TPM Auto Provisioning in Windows". Another option is to just clear the TPM following [http://www.dell.com/support/article/uk/en/ukbsdt1/SLN155219/en this guide] and just run the {{ic|.exe}} file from Windows.<br />
<br />
Once the update succeeds, the Linux kernel should automatically recognise the newly configured TPM device and enable it automatically on next boot. To make use of the now TPM 2.0 chip a couple of packages are worth installing - {{AUR|tpm2.0-tss-git}} and {{AUR|tpm2.0-tools-git}}. To make the TSS resource manager work on boot, a handy systemd service is provided and its variants discussed [https://github.com/01org/TPM2.0-TSS/issues/321 here]<br />
<br />
== CPU slowdown after resume from suspend ==<br />
If you are experiencing a very slow computer after resume from suspend, you may be subject to a bug where your CPU frequency is capped to a very low value. Use {{ic|cpupower frequency-info}} to check. If so, please read [https://bbs.archlinux.org/viewtopic.php?pid=1558948#p1558948 this forum thread] for debug information, and a workaround.<br />
<br />
== lspci and lsusb ==<br />
<br />
{{Accuracy|According links unter [[#See also]] should be sufficient. It is therefore not necessary to list the output here.}}<br />
<br />
The <tt>lspci</tt> and <tt>lsusb</tt> below were take from the following system:<br />
<br />
[ 0.000000] DMI: Dell Inc. XPS 13 9350/0PWNCR, BIOS 1.3.3 03/01/2016<br />
<br />
on kernel:<br />
<br />
Linux marv 4.5.4-1-ARCH #1 SMP PREEMPT Wed May 11 22:21:28 CEST 2016 x86_64 GNU/Linux<br />
<br />
=== lspci ===<br />
<br />
00:00.0 Host bridge: Intel Corporation Skylake Host Bridge/DRAM Registers (rev 08)<br />
00:02.0 VGA compatible controller: Intel Corporation Skylake Integrated Graphics (rev 07)<br />
00:04.0 Signal processing controller: Intel Corporation Skylake Processor Thermal Subsystem (rev 08)<br />
00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller (rev 21)<br />
00:14.2 Signal processing controller: Intel Corporation Sunrise Point-LP Thermal subsystem (rev 21)<br />
00:15.0 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #0 (rev 21)<br />
00:15.1 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #1 (rev 21)<br />
00:16.0 Communication controller: Intel Corporation Sunrise Point-LP CSME HECI #1 (rev 21)<br />
00:1c.0 PCI bridge: Intel Corporation Device 9d10 (rev f1)<br />
00:1c.4 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #5 (rev f1)<br />
00:1c.5 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #6 (rev f1)<br />
00:1d.0 PCI bridge: Intel Corporation Device 9d18 (rev f1)<br />
00:1f.0 ISA bridge: Intel Corporation Sunrise Point-LP LPC Controller (rev 21)<br />
00:1f.2 Memory controller: Intel Corporation Sunrise Point-LP PMC (rev 21)<br />
00:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev 21)<br />
00:1f.4 SMBus: Intel Corporation Sunrise Point-LP SMBus (rev 21)<br />
3a:00.0 Network controller: Broadcom Corporation BCM4350 802.11ac Wireless Network Adapter (rev 08)<br />
3b:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS525A PCI Express Card Reader (rev 01)<br />
3c:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller (rev 01)<br />
<br />
[https://gist.github.com/mgalgs/a903e3528f48aa25b5c0b9ae9c09a07f Full output from sudo lspci -v]<br />
<br />
After plugging in a USB-C hub, a number of new PCI devices appear:<br />
<br />
01:00.0 PCI bridge: Intel Corporation Device 1576<br />
02:00.0 PCI bridge: Intel Corporation Device 1576<br />
02:01.0 PCI bridge: Intel Corporation Device 1576<br />
02:02.0 PCI bridge: Intel Corporation Device 1576<br />
39:00.0 USB controller: Intel Corporation Device 15b5<br />
<br />
=== lsusb ===<br />
<br />
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub<br />
Bus 001 Device 004: ID 0c45:670c Microdia <br />
Bus 001 Device 003: ID 04f3:20d0 Elan Microelectronics Corp. <br />
Bus 001 Device 002: ID 0a5c:6412 Broadcom Corp. <br />
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub<br />
<br />
[https://gist.github.com/mgalgs/15fb0d19795f700d60f061f67dddbefc Full output from sudo lsusb -v]<br />
<br />
== See also ==<br />
<br />
* [https://bbs.archlinux.org/viewtopic.php?pid=1579113 Arch Forum thread for XPS 13]<br />
* [http://www.dell.com/support/home/us/en/19/product-support/product/xps-13-9350-laptop/drivers Dell XPS 13 9350 driver and firmware updates]</div>Kgizdovhttps://wiki.archlinux.org/index.php?title=Dell_XPS_13_(9350)&diff=461846Dell XPS 13 (9350)2017-01-07T14:29:45Z<p>Kgizdov: /* TPM 2.0 */ typos, phrasing</p>
<hr />
<div>[[Category:Dell]]<br />
[[ja:Dell XPS 13 (9350)]]<br />
{{Note|This page refers to the early 2016 model of XPS 13. For the late 2016 model see [[Dell XPS 13 (9360)]].}}<br />
{| class="wikitable" style="float: right;"<br />
| '''Device''' || '''Status''' || '''Modules'''<br />
|-<br />
| Video || {{G|Working}} || i915<br />
|-<br />
| External screen || {{Y|Partial or does not work at all}} || ?<br />
|-<br />
| Wireless || {{G|Working}} || brcmfmac<br />
|-<br />
| Bluetooth || {{G|Works after installing firmware}}|| btbcm<br />
|-<br />
| Audio || {{G|Working}} || snd_hda_intel<br />
|-<br />
| Touchpad || {{G|Working}} || ?<br />
|-<br />
| Webcam || {{G|Working}} || uvcvideo<br />
|-<br />
| Card Reader || {{G|Working}} || rtsx_pci<br />
|-<br />
| Wireless switch || {{G|Working}} || intel_hid<br />
|-<br />
| Function/Multimedia Keys || {{G|Working}} || ?<br />
|-<br />
| TPM 1.2/2.0 || {{G|Working}} || tpm<br />
|}<br />
<br />
The Dell XPS 13 2016 (9350) is the third-generation model of the XPS 13 line. The laptop is available in both a standard edition with Windows installed as well as a Developer Edition which only differs in that it comes with Ubuntu installed as well as the Broadcom WiFi card replaced with an Intel WiFi card. Just like the older versions ([[Dell XPS 13 (9333)]] and [[Dell XPS 13 (9343)]]) it can be bought in different hardware configurations.<br />
<br />
The installation process for Arch on the XPS 13 does not differ from any other PC. For installation help, please see the [[Installation guide]] and [[UEFI]]. This page covers the current status of hardware support on Arch, as well as post-installation recommendations.<br />
<br />
As of kernel 4.3, the Intel Skylake architecture is supported.<br />
<br />
== Content adaptive brightness control ==<br />
In the XPS 13 the display panels (both FHD and QHD+) come with adaptive brightness embedded in the panel firmware, this "content adaptive brightness control" (usually referred to as CABC or DBC) will adjust the screen brightness depending on the content displayed on the screen and will generally be found undesirable, especially for Linux users who are likely to be switching between dark and light screen content. Dell has issued a fix for this however it is only available to run in Windows and for the QHD+ model of the laptop so this precaution should be taken before installing Linux, the FHD model of the XPS 13 (9350) cannot be fixed. This is not a problem with the panel but rather a problem with the way the panels are configured for the XPS 13, as the same panel exists in the Dell's Latitude 13 7000 series (e7370) FHD model but with CABC disabled. The fix is available directly from [http://www.dell.com/support/home/uk/en/ukdhs1/Drivers/DriversDetails?driverId=PWD5K&fileId=3505631210&osCode=W764&productCode=xps-13-9350-laptop&languageCode=en&categoryId=AP Dell].<br />
<br />
== BIOS ==<br />
=== USB not found ===<br />
It may happen that the Arch Linux USB won't be recognized. You have to disable secure boot (Secure Boot > Disable) and then enable the legacy (General > Advanced Boot Options > Enable Legacy Option ROMs).<br />
<br />
=== No UEFI system found ===<br />
Sometimes the BIOS UEFI does not respect the efivars. In this case you have manually add your efi file in BIOS boot options by going to General > Boot Sequence > Add Boot Option.<br />
<br />
=== Updates ===<br />
[http://downloads.dell.com/FOLDER04068454M/1/XPS_9350_1.4.12.exe BIOS update 1.4.12] was released on 2016-12-21. Store the update binary on your EFI partition ({{ic|/boot/EFI}}) or on a USB flash drive, reboot, and choose BIOS Update in the F12 boot menu. This might also help if your machine will not resume after suspend.<br />
<br />
=== Firmware Updates ===<br />
Dell provides firmware updates via Linux Vendor Firmware Service (LVFS). Refer to [[Flashing BIOS from Linux#fwupd]] for additional information. A package is readily available at {{aur|fwupd}}.<br />
<br />
== Thunderbolt 3 / USB 3.1 ==<br />
<br />
The USB-C port supports Thunderbolt 3, Displayport-over-USB-C and USB power delivery as well as USB 3.1.<br />
<br />
In the event of devices not working correctly, ensure that you have updated to the latest BIOS (above) and Thunderbolt firmware (below).<br />
<br />
[http://downloads.dell.com/FOLDER03798029M/1/Intel_TBT3_FW_UPDATE_NVM16_A04_2.16.01.003.exe Thunderbolt 3 Firmware Update 2.16.01.003, A04] was released on 2016-08-10. Unlike the BIOS update, this is a graphical application which must be run in a modern Windows environment (MS-DOS will not suffice).<br />
<br />
Hotplug support for this port requires a [https://bugzilla.kernel.org/show_bug.cgi?id=115121 bug fix] which landed in kernel version 4.7. It also requires the kernel to be built with <tt>CONFIG_PCI_HOTPLUG=y</tt>.<br />
<br />
=== External screen ===<br />
<br />
Support for external screens either using an USB-C to HDMI or USB-C to Mini Display ports adapters may not be working properly. Commonly the screen when plugged is reported to either:<br />
<br />
* display an image for a few milliseconds then switch to a black screen;<br />
* have no image at all;<br />
* being flickering after a few minutes to the extent this is basically unusable.<br />
<br />
Refer to the [https://bbs.archlinux.org/viewtopic.php?id=205147 according Arch Forum entry] for an exhaustive discussion about working adapters and the [http://en.community.dell.com/techcenter/os-applications/f/4613/t/19988851 Dell forum entry].<br />
<br />
== SATA controller ==<br />
When the SATA-controller is set to {{ic|RAID On}} in Bios, the hard disk (at least the SSD) is not recognized. Set to {{ic|Off}} or {{ic|AHCI}} ({{ic|AHCI}} is recommended) before attempting to install Arch.<br />
<br />
=== Dual booting Linux and Windows ===<br />
In order to boot into Windows properly without getting an {{ic|INACCESSIBLE_BOOT_DEVICE}} error with disabled {{ic|RAID}} you must configure Windows to use the {{ic|AHCI}}-speaking SATA storage controller, assuming you used {{ic|AHCI}} for installing Linux. The driver is effectively disabled even though it is installed. Either of the following methods were reported to activate the drivers without reinstallation (your mileage may vary):<br />
<br />
* [http://www.tenforums.com/drivers-hardware/15006-attn-ssd-owners-enabling-ahci-mode-after-windows-10-installation.html booting into safe mode and back]<br />
* [https://samnicholls.net/2016/01/14/how-to-switch-sata-raid-to-ahci-windows-10-xps-13/ Selecting {{ic|Microsoft Storage Spaces Controller}} in Windows Device Manager]<br />
* [http://www.tenforums.com/tutorials/22631-ahci-enable-windows-8-windows-10-after-installation.html Modifying registry entries]<br />
* [http://superuser.com/questions/471102/change-from-ide-to-ahci-after-installing-windows-8/471108#471108 Modifying other registry entries]<br />
<br />
Consult the [https://support.microsoft.com/en-us/kb/2795397 microsoft support] page for additional information. Be aware that some manufactures propagate reinstalling Windows to be the only solution, which it is not.<br />
<br />
== NVM Express SSD ==<br />
=== Cannot find root device ===<br />
The location of the {{ic|nvme}} module for [[wikipedia:NVM_Express|"NVM Express"]] SSD has changed between {{Pkg|linux}} kernel version 4.3 and 4.4. If you experience "cannot find root device" on boot, it may be due to the [https://bugs.archlinux.org/task/47761 {{ic|nvme}} module not being present in {{ic|initramfs}}]. In this case, the following may resolve your issue.<br />
<br />
Edit your {{ic|/etc/mkinitcpio.conf}} file:<br />
...<br />
MODULES="... nvme"<br />
...<br />
<br />
Then update the bootloader.<br />
<br />
# mkinitcpio -p linux<br />
<br />
where {{ic|linux}} is the name of the image loaded on boot. If you installed {{AUR|linux-mainline}} then change that to {{ic|linux-mainline}}.<br />
<br />
=== Note on Mount Options ===<br />
<br />
Using the {{ic|discard}} mount option for your filesystem is not recommended, as mentioned in [[Solid_State_Drives#Continuous TRIM|this warning]] and [https://bbs.archlinux.org/viewtopic.php?pid=1593544#p1593544 the forum]. See also [[Solid State Drives/NVMe#Discards]] for further information.<br />
<br />
=== NVME Power Saving Patch ===<br />
<br />
Andy Lutomirski has released version 4 of his patchset which fixes powersaving for NVME devices in linux. Currently, this patch is not merged into mainline yet. Until it lands in mainline kernel use the AUR package below. <br />
{{App|Linux-nvme|Mainline linux kernel patched with Andy's patch for NVME powersaving APST.|https://github.com/damige/linux-nvme|{{AUR|linux-nvme}}}}<br />
<br />
== Wireless ==<br />
<br />
For the non-developer edition, the built-in Broadcom BCM4350 is now supported in the current {{Pkg|linux}} kernel (as of version 4.4.1-1). The wireless module {{ic|brcmfmac}} also needs the firmware {{ic|brcmfmac4350-pcie.bin}} from the related {{Pkg|linux-firmware}} package.<br />
<br />
The Broadcom adapter does not report its regulatory country and so, by default, the global settings for channels and frequencies will be set. See [[Wireless network configuration#Respecting the regulatory domain]] for more information about how this can be changed.<br />
<br />
== Bluetooth ==<br />
<br />
=== Intel WiFi ===<br />
If your WiFi card supports Bluetooth, then the BT interface should be available out-of-the-box, as the required firmware is included in {{pkg|linux-firmware}}.<br />
<br />
=== Broadcom Wifi ===<br />
Bluetooth should work right away. Load the module {{ic|btusb}} and {{ic|bluetooth}} if it was not already and [[start]]/[[enable]] {{ic|bluetooth.service}}. Refer to [[Bluetooth]] for more information and configuration options.<br />
<br />
==== Wireless headset: strange bluetooth behavior ====<br />
<br />
If your Bluetooth behaves unstable, such as connection loss, stuttering sound. being able to connect but not to listen through it, etc. you probably need the proprietary firmware.<br />
<br />
The Broadcom Bluetooth firmware is not available in the kernel (the same as for the 2015 model [http://tech.sybreon.com/2015/03/15/xps13-9343-ubuntu-linux/ source]), therefore you will have to retrieve it from a Windows [http://downloads.dell.com/FOLDER03272920M/1/9350_Network_Driver_XMJK7_WN32_12.0.1.720_A00.EXE .exe]. You need to extract the {{ic|.exe}} file with {{Pkg|p7zip}} and then convert it to a {{ic|.hcd}} file with ''hex2hcd'' from {{Pkg|bluez-utils}}:<br />
<br />
$ 7z x 9350_Network_Driver_XMJK7_WN32_12.0.1.720_A00.EXE<br />
$ cp Win32/BCM4350C5_003.006.007.0095.1703.hex ./<br />
$ hex2hcd BCM4350C5_003.006.007.0095.1703.hex<br />
# mv BCM4350C5_003.006.007.0095.1703.hcd /lib/firmware/brcm/BCM-0a5c-6412.hcd<br />
<br />
Alternatively, you may simply install {{AUR|bcm4350-firmware}}.<br />
<br />
After a reboot, the firmware should be available for your Bluetooth interface.<br />
<br />
== Video ==<br />
The video should work with the {{ic|i915}} driver of the current {{Pkg|linux}} kernel. Consult [[Intel graphics]] for a detailed installation and configuration guide as well as for [[Intel graphics#Troubleshooting|Troubleshooting]].<br />
<br />
=== Blank screen issue after booting ===<br />
If using "late start" [[KMS]] (the default) and the screen goes blank when loading modules, it may help to add {{ic|i915}} and {{ic|intel_agp}} to the initramfs or using a special [[kernel parameter]]. Consult [[Intel graphics#Blank screen during boot, when "Loading modules"]] for more information about the kernel paramter way and have a look at [[Kernel mode setting#Early KMS start]] for a guide on how to setup the modules for the initramfs.<br />
<br />
=== Linux kernel 4.8 or later power savings ===<br />
<br />
{{warning|The following options of the {{ic|i915}} module taint the kernel, use at your own risks!}}<br />
<br />
====RC6====<br />
{{ic|i915.enable_rc6&#61;1}} seems to be stable, setting the value to a higher number will be ignored is therefore confusing, the deeper GPU power states that this option enables (RC6p and RC6pp) do not exist on gen7+ hardware.[https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/i915/i915_drv.h#n2862][https://lists.freedesktop.org/archives/intel-gfx/2012-June/018383.html].<br />
<br />
====Panel Self Refresh====<br />
{{ic|i915.enable_psr&#61;1}} allows for some really nice power savings by leaving the package longer in more efficient C-states. However, users experience freezes for a few seconds with this option fairly often, setting the value to [https://patchwork.kernel.org/patch/8182841/ 2 or 3] may yield to similar power savings but without the freezes.<br />
{{ic|i915.disable_power_well&#61;0}} with {{ic|i915.enable_psr&#61;1 i915.enable_rc6&#61;1}} also seems to be a stable configuration for PSR.<br />
<br />
====Frame Buffer Compression====<br />
{{ic|i915.enable_fbc&#61;1}} is stable but does not seem to yield significant power saving results.<br />
<br />
====GuC====<br />
[https://01.org/linuxgraphics/intel-linux-graphics-firmwares GuC] loading with {{ic|i915.enable_guc_loading&#61;1 i915.enable_guc_submission&#61;1}} seems stable too.<br />
<br />
=== Linux kernel 4.3 or earlier ===<br />
<br />
If you are using an older kernel 4.3 or earlier, you also require the kernel parameter {{ic|i915.preliminary_hw_support&#61;1}}, see [[Intel graphics#Skylake support]]. (For later kernels 4.3+ or {{AUR|linux-bcm4350}} the parameter is unnecessary.)<br />
<br />
=== Linux kernel 4.5 or earlier ===<br />
<br />
If you have the newer i7-6560 CPU with Iris 540 graphics, the GPU hangs every few minutes with kernel versions before 4.6. This is probably due to this bug https://bugs.freedesktop.org/show_bug.cgi?id=94161 and can be countered by either disabling DRI in your Xorg configuration:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-intel.conf|<br />
Section "Device"<br />
Identifier "Intel Graphics"<br />
Driver "intel"<br />
Option "DRI" "false"<br />
EndSection<br />
}}<br />
<br />
or by adding {{ic|1=i915.enable_rc6=0}} to the kernel boot parameters.<br />
<br />
== Touchpad ==<br />
Only key-presses work out of the box. Installing {{pkg|xf86-input-libinput}} is sufficient for proper mouse support plus it also handles the touchscreen - see [[libinput]] for configuration. Features such as tap-to-click are usually adjustable within the [[desktop environment]].<br />
<br />
Alternatively you may want to install {{pkg|xf86-input-synaptics}} as driver but "it is on maintenance mode and {{pkg|xf86-input-libinput}} must be preferred over" (installation note from the package itself). Plus it may lack the ability to be easily adjustable within your [[desktop environment]] (see [[Dell Studio XPS 13]]). Restarting the X server might be required.<br />
<br />
=== Remove psmouse errors from dmesg ===<br />
<br />
If {{ic|<nowiki>dmesg | grep -i psmouse</nowiki>}} returns an error, but your touchpad still works, then it might be a good idea to disable {{ic|psmouse}}. First create a config file:<br />
<br />
# nano /etc/modprobe.d/modprobe.conf<br />
<br />
blacklist psmouse<br />
<br />
Then add this file to {{ic|/etc/mkinitcpio.conf}}:<br />
<br />
...<br />
FILES="/etc/modprobe.d/modprobe.conf"<br />
...<br />
<br />
Rebuild your initial ramdisk image (see [[Mkinitcpio#Image creation and activation]]).<br />
<br />
=== Gestures ===<br />
<br />
Refer to [[libinput#Gestures]] for information about the current development state and available methods.<br />
<br />
== Sound ==<br />
<br />
=== Hissing/Crackling noises when using headphones ===<br />
<br />
Some people reported white hissing/crackling noises when using headphones. To get rid of them you can run {{ic|alsamixer}} from {{Pkg|alsa-utils}}.<br />
Select your soundcard with F6 and set the headset-gain to 22 (3rd lever from the left) or use the {{ic|amixer}} command:<br />
<br />
$ amixer -c 0 cset 'numid=10' 1<br />
numid=10,iface=MIXER,name='Headphone Mic Boost Volume'<br />
; type=INTEGER,access=rw---R--,values=2,min=0,max=3,step=0<br />
: values=1,1<br />
| dBscale-min=0.00dB,step=10.00dB,mute=0<br />
<br />
Unfortunately [[PulseAudio]] will override the above setting every time you log in/out of your environment (or every time the PulseAudio service is restarted), even if the {{ic|alsa-restore.service}} is enabled at [[start]] up.<br />
<br />
To work around this issue, edit {{ic|/usr/share/pulseaudio/alsa-mixer/paths/analog-input-headphone-mic.conf}} and comment out the section {{ic|[Element Headphone Mic Boost]}}:<br />
<br />
---<br />
#[Element Headphone Mic Boost]<br />
#required-any = any<br />
#switch = select<br />
#volume = merge<br />
#override-map.1 = all<br />
#override-map.2 = all-left,all-right<br />
---<br />
<br />
Similarly in {{ic|/usr/share/pulseaudio/alsa-mixer/paths/analog-input-internal-mic.conf}}, comment out the same section:<br />
<br />
---<br />
#[Element Headphone Mic Boost]<br />
#switch = off<br />
#volume = off<br />
---<br />
<br />
This will prevent PulseAudio to fiddle with the gain setting at all.<br />
<br />
{{Note|Unfortunately, you must make the same modifications every time the PulseAudio package is updated. Additionally, this will entirely disable the internal microphone.}}<br />
<br />
== Microphone ==<br />
{{Note| Not all hardware has the "Digital" channel}}<br />
For ALSA, increase "Digital" channel for microphone to work.<br />
<br />
== TPM ==<br />
<br />
As shipped the Trusted Platform Module (TPM) can be configured easily following the steps at [[Trusted Platform Module]] and requires no otherwise special configuration.<br />
<br />
=== TPM 2.0 ===<br />
<br />
Originally the Dell XPS 13 (9350) shipped with TPM 1.2 - the TPM chip was configured to support the TPM Standard version 1.2. However, on 6 Jan 2017 Dell released a [http://www.dell.com/support/home/uk/en/ukdhs1/Drivers/DriversDetails?driverId=N8P80 firmware update] (internal version 1.3.1.0_V1) for the TPM chip that converts it to support the feature set of TPM Standard version 2.0. Unfortunately, as of this moment the update cannot be applied through Linux or the BIOS direct flashing capabilities. The only way to install it seems to be to apply it through a running Windows OS. The easiest method is to run a temporary Windows installation on a USB drive, boot into it and run the update from there. {{Warning| It should be noted that this update is irreversible once applied. It also requires that the TPM memory and configuration is completely cleared.}}<br />
{{Note| As for BIOS updates, please make sure the laptop is plugged in to a power source and that power source is stable.}}<br />
<br />
To install the update one can follow the instructions on the above mentioned firmware update page to clear and reset the TPM chip and initiate the update. Users intending to later use the device in Linux, can skip the last steps 11 & 12 from section "Disable TPM Auto Provisioning in Windows". Another option is to just clear the TPM following [http://www.dell.com/support/article/uk/en/ukbsdt1/SLN155219/en this guide] and just run the {{ic|.exe}} file from Windows.<br />
<br />
Once the update succeeds, the Linux kernel should automatically recognise the newly configured TPM device and enable it automatically on next boot. To make use of the now TPM 2.0 chip a couple of packages are worth installing - {{AUR|tpm2.0-tss-git}} and {{AUR|tpm2.0-tools-git}}. To make the TSS resource manager work on boot, a handy systemd service is provided and its variants discussed [https://github.com/01org/TPM2.0-TSS/issues/321 here]<br />
<br />
== CPU slowdown after resume from suspend ==<br />
If you are experiencing a very slow computer after resume from suspend, you may be subject to a bug where your CPU frequency is capped to a very low value. Use {{ic|cpupower frequency-info}} to check. If so, please read [https://bbs.archlinux.org/viewtopic.php?pid=1558948#p1558948 this forum thread] for debug information, and a workaround.<br />
<br />
== lspci and lsusb ==<br />
<br />
{{Accuracy|According links unter [[#See also]] should be sufficient. It is therefore not necessary to list the output here.}}<br />
<br />
The <tt>lspci</tt> and <tt>lsusb</tt> below were take from the following system:<br />
<br />
[ 0.000000] DMI: Dell Inc. XPS 13 9350/0PWNCR, BIOS 1.3.3 03/01/2016<br />
<br />
on kernel:<br />
<br />
Linux marv 4.5.4-1-ARCH #1 SMP PREEMPT Wed May 11 22:21:28 CEST 2016 x86_64 GNU/Linux<br />
<br />
=== lspci ===<br />
<br />
00:00.0 Host bridge: Intel Corporation Skylake Host Bridge/DRAM Registers (rev 08)<br />
00:02.0 VGA compatible controller: Intel Corporation Skylake Integrated Graphics (rev 07)<br />
00:04.0 Signal processing controller: Intel Corporation Skylake Processor Thermal Subsystem (rev 08)<br />
00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller (rev 21)<br />
00:14.2 Signal processing controller: Intel Corporation Sunrise Point-LP Thermal subsystem (rev 21)<br />
00:15.0 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #0 (rev 21)<br />
00:15.1 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #1 (rev 21)<br />
00:16.0 Communication controller: Intel Corporation Sunrise Point-LP CSME HECI #1 (rev 21)<br />
00:1c.0 PCI bridge: Intel Corporation Device 9d10 (rev f1)<br />
00:1c.4 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #5 (rev f1)<br />
00:1c.5 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #6 (rev f1)<br />
00:1d.0 PCI bridge: Intel Corporation Device 9d18 (rev f1)<br />
00:1f.0 ISA bridge: Intel Corporation Sunrise Point-LP LPC Controller (rev 21)<br />
00:1f.2 Memory controller: Intel Corporation Sunrise Point-LP PMC (rev 21)<br />
00:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev 21)<br />
00:1f.4 SMBus: Intel Corporation Sunrise Point-LP SMBus (rev 21)<br />
3a:00.0 Network controller: Broadcom Corporation BCM4350 802.11ac Wireless Network Adapter (rev 08)<br />
3b:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS525A PCI Express Card Reader (rev 01)<br />
3c:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller (rev 01)<br />
<br />
[https://gist.github.com/mgalgs/a903e3528f48aa25b5c0b9ae9c09a07f Full output from sudo lspci -v]<br />
<br />
After plugging in a USB-C hub, a number of new PCI devices appear:<br />
<br />
01:00.0 PCI bridge: Intel Corporation Device 1576<br />
02:00.0 PCI bridge: Intel Corporation Device 1576<br />
02:01.0 PCI bridge: Intel Corporation Device 1576<br />
02:02.0 PCI bridge: Intel Corporation Device 1576<br />
39:00.0 USB controller: Intel Corporation Device 15b5<br />
<br />
=== lsusb ===<br />
<br />
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub<br />
Bus 001 Device 004: ID 0c45:670c Microdia <br />
Bus 001 Device 003: ID 04f3:20d0 Elan Microelectronics Corp. <br />
Bus 001 Device 002: ID 0a5c:6412 Broadcom Corp. <br />
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub<br />
<br />
[https://gist.github.com/mgalgs/15fb0d19795f700d60f061f67dddbefc Full output from sudo lsusb -v]<br />
<br />
== See also ==<br />
<br />
* [https://bbs.archlinux.org/viewtopic.php?pid=1579113 Arch Forum thread for XPS 13]<br />
* [http://www.dell.com/support/home/us/en/19/product-support/product/xps-13-9350-laptop/drivers Dell XPS 13 9350 driver and firmware updates]</div>Kgizdovhttps://wiki.archlinux.org/index.php?title=Dell_XPS_13_(9350)&diff=461836Dell XPS 13 (9350)2017-01-07T13:48:17Z<p>Kgizdov: Added section for TPM and TPM 2.0 firmware update</p>
<hr />
<div>[[Category:Dell]]<br />
[[ja:Dell XPS 13 (9350)]]<br />
{{Note|This page refers to the early 2016 model of XPS 13. For the late 2016 model see [[Dell XPS 13 (9360)]].}}<br />
{| class="wikitable" style="float: right;"<br />
| '''Device''' || '''Status''' || '''Modules'''<br />
|-<br />
| Video || {{G|Working}} || i915<br />
|-<br />
| External screen || {{Y|Partial or does not work at all}} || ?<br />
|-<br />
| Wireless || {{G|Working}} || brcmfmac<br />
|-<br />
| Bluetooth || {{G|Works after installing firmware}}|| btbcm<br />
|-<br />
| Audio || {{G|Working}} || snd_hda_intel<br />
|-<br />
| Touchpad || {{G|Working}} || ?<br />
|-<br />
| Webcam || {{G|Working}} || uvcvideo<br />
|-<br />
| Card Reader || {{G|Working}} || rtsx_pci<br />
|-<br />
| Wireless switch || {{G|Working}} || intel_hid<br />
|-<br />
| Function/Multimedia Keys || {{G|Working}} || ?<br />
|-<br />
| TPM 1.2/2.0 || {{G|Working}} || tpm<br />
|}<br />
<br />
The Dell XPS 13 2016 (9350) is the third-generation model of the XPS 13 line. The laptop is available in both a standard edition with Windows installed as well as a Developer Edition which only differs in that it comes with Ubuntu installed as well as the Broadcom WiFi card replaced with an Intel WiFi card. Just like the older versions ([[Dell XPS 13 (9333)]] and [[Dell XPS 13 (9343)]]) it can be bought in different hardware configurations.<br />
<br />
The installation process for Arch on the XPS 13 does not differ from any other PC. For installation help, please see the [[Installation guide]] and [[UEFI]]. This page covers the current status of hardware support on Arch, as well as post-installation recommendations.<br />
<br />
As of kernel 4.3, the Intel Skylake architecture is supported.<br />
<br />
== Content adaptive brightness control ==<br />
In the XPS 13 the display panels (both FHD and QHD+) come with adaptive brightness embedded in the panel firmware, this "content adaptive brightness control" (usually referred to as CABC or DBC) will adjust the screen brightness depending on the content displayed on the screen and will generally be found undesirable, especially for Linux users who are likely to be switching between dark and light screen content. Dell has issued a fix for this however it is only available to run in Windows and for the QHD+ model of the laptop so this precaution should be taken before installing Linux, the FHD model of the XPS 13 (9350) cannot be fixed. This is not a problem with the panel but rather a problem with the way the panels are configured for the XPS 13, as the same panel exists in the Dell's Latitude 13 7000 series (e7370) FHD model but with CABC disabled. The fix is available directly from [http://www.dell.com/support/home/uk/en/ukdhs1/Drivers/DriversDetails?driverId=PWD5K&fileId=3505631210&osCode=W764&productCode=xps-13-9350-laptop&languageCode=en&categoryId=AP Dell].<br />
<br />
== BIOS ==<br />
=== USB not found ===<br />
It may happen that the Arch Linux USB won't be recognized. You have to disable secure boot (Secure Boot > Disable) and then enable the legacy (General > Advanced Boot Options > Enable Legacy Option ROMs).<br />
<br />
=== No UEFI system found ===<br />
Sometimes the BIOS UEFI does not respect the efivars. In this case you have manually add your efi file in BIOS boot options by going to General > Boot Sequence > Add Boot Option.<br />
<br />
=== Updates ===<br />
[http://downloads.dell.com/FOLDER04068454M/1/XPS_9350_1.4.12.exe BIOS update 1.4.12] was released on 2016-12-21. Store the update binary on your EFI partition ({{ic|/boot/EFI}}) or on a USB flash drive, reboot, and choose BIOS Update in the F12 boot menu. This might also help if your machine will not resume after suspend.<br />
<br />
=== Firmware Updates ===<br />
Dell provides firmware updates via Linux Vendor Firmware Service (LVFS). Refer to [[Flashing BIOS from Linux#fwupd]] for additional information. A package is readily available at {{aur|fwupd}}.<br />
<br />
== Thunderbolt 3 / USB 3.1 ==<br />
<br />
The USB-C port supports Thunderbolt 3, Displayport-over-USB-C and USB power delivery as well as USB 3.1.<br />
<br />
In the event of devices not working correctly, ensure that you have updated to the latest BIOS (above) and Thunderbolt firmware (below).<br />
<br />
[http://downloads.dell.com/FOLDER03798029M/1/Intel_TBT3_FW_UPDATE_NVM16_A04_2.16.01.003.exe Thunderbolt 3 Firmware Update 2.16.01.003, A04] was released on 2016-08-10. Unlike the BIOS update, this is a graphical application which must be run in a modern Windows environment (MS-DOS will not suffice).<br />
<br />
Hotplug support for this port requires a [https://bugzilla.kernel.org/show_bug.cgi?id=115121 bug fix] which landed in kernel version 4.7. It also requires the kernel to be built with <tt>CONFIG_PCI_HOTPLUG=y</tt>.<br />
<br />
=== External screen ===<br />
<br />
Support for external screens either using an USB-C to HDMI or USB-C to Mini Display ports adapters may not be working properly. Commonly the screen when plugged is reported to either:<br />
<br />
* display an image for a few milliseconds then switch to a black screen;<br />
* have no image at all;<br />
* being flickering after a few minutes to the extent this is basically unusable.<br />
<br />
Refer to the [https://bbs.archlinux.org/viewtopic.php?id=205147 according Arch Forum entry] for an exhaustive discussion about working adapters and the [http://en.community.dell.com/techcenter/os-applications/f/4613/t/19988851 Dell forum entry].<br />
<br />
== SATA controller ==<br />
When the SATA-controller is set to {{ic|RAID On}} in Bios, the hard disk (at least the SSD) is not recognized. Set to {{ic|Off}} or {{ic|AHCI}} ({{ic|AHCI}} is recommended) before attempting to install Arch.<br />
<br />
=== Dual booting Linux and Windows ===<br />
In order to boot into Windows properly without getting an {{ic|INACCESSIBLE_BOOT_DEVICE}} error with disabled {{ic|RAID}} you must configure Windows to use the {{ic|AHCI}}-speaking SATA storage controller, assuming you used {{ic|AHCI}} for installing Linux. The driver is effectively disabled even though it is installed. Either of the following methods were reported to activate the drivers without reinstallation (your mileage may vary):<br />
<br />
* [http://www.tenforums.com/drivers-hardware/15006-attn-ssd-owners-enabling-ahci-mode-after-windows-10-installation.html booting into safe mode and back]<br />
* [https://samnicholls.net/2016/01/14/how-to-switch-sata-raid-to-ahci-windows-10-xps-13/ Selecting {{ic|Microsoft Storage Spaces Controller}} in Windows Device Manager]<br />
* [http://www.tenforums.com/tutorials/22631-ahci-enable-windows-8-windows-10-after-installation.html Modifying registry entries]<br />
* [http://superuser.com/questions/471102/change-from-ide-to-ahci-after-installing-windows-8/471108#471108 Modifying other registry entries]<br />
<br />
Consult the [https://support.microsoft.com/en-us/kb/2795397 microsoft support] page for additional information. Be aware that some manufactures propagate reinstalling Windows to be the only solution, which it is not.<br />
<br />
== NVM Express SSD ==<br />
=== Cannot find root device ===<br />
The location of the {{ic|nvme}} module for [[wikipedia:NVM_Express|"NVM Express"]] SSD has changed between {{Pkg|linux}} kernel version 4.3 and 4.4. If you experience "cannot find root device" on boot, it may be due to the [https://bugs.archlinux.org/task/47761 {{ic|nvme}} module not being present in {{ic|initramfs}}]. In this case, the following may resolve your issue.<br />
<br />
Edit your {{ic|/etc/mkinitcpio.conf}} file:<br />
...<br />
MODULES="... nvme"<br />
...<br />
<br />
Then update the bootloader.<br />
<br />
# mkinitcpio -p linux<br />
<br />
where {{ic|linux}} is the name of the image loaded on boot. If you installed {{AUR|linux-mainline}} then change that to {{ic|linux-mainline}}.<br />
<br />
=== Note on Mount Options ===<br />
<br />
Using the {{ic|discard}} mount option for your filesystem is not recommended, as mentioned in [[Solid_State_Drives#Continuous TRIM|this warning]] and [https://bbs.archlinux.org/viewtopic.php?pid=1593544#p1593544 the forum]. See also [[Solid State Drives/NVMe#Discards]] for further information.<br />
<br />
=== NVME Power Saving Patch ===<br />
<br />
Andy Lutomirski has released version 4 of his patchset which fixes powersaving for NVME devices in linux. Currently, this patch is not merged into mainline yet. Until it lands in mainline kernel use the AUR package below. <br />
{{App|Linux-nvme|Mainline linux kernel patched with Andy's patch for NVME powersaving APST.|https://github.com/damige/linux-nvme|{{AUR|linux-nvme}}}}<br />
<br />
== Wireless ==<br />
<br />
For the non-developer edition, the built-in Broadcom BCM4350 is now supported in the current {{Pkg|linux}} kernel (as of version 4.4.1-1). The wireless module {{ic|brcmfmac}} also needs the firmware {{ic|brcmfmac4350-pcie.bin}} from the related {{Pkg|linux-firmware}} package.<br />
<br />
The Broadcom adapter does not report its regulatory country and so, by default, the global settings for channels and frequencies will be set. See [[Wireless network configuration#Respecting the regulatory domain]] for more information about how this can be changed.<br />
<br />
== Bluetooth ==<br />
<br />
=== Intel WiFi ===<br />
If your WiFi card supports Bluetooth, then the BT interface should be available out-of-the-box, as the required firmware is included in {{pkg|linux-firmware}}.<br />
<br />
=== Broadcom Wifi ===<br />
Bluetooth should work right away. Load the module {{ic|btusb}} and {{ic|bluetooth}} if it was not already and [[start]]/[[enable]] {{ic|bluetooth.service}}. Refer to [[Bluetooth]] for more information and configuration options.<br />
<br />
==== Wireless headset: strange bluetooth behavior ====<br />
<br />
If your Bluetooth behaves unstable, such as connection loss, stuttering sound. being able to connect but not to listen through it, etc. you probably need the proprietary firmware.<br />
<br />
The Broadcom Bluetooth firmware is not available in the kernel (the same as for the 2015 model [http://tech.sybreon.com/2015/03/15/xps13-9343-ubuntu-linux/ source]), therefore you will have to retrieve it from a Windows [http://downloads.dell.com/FOLDER03272920M/1/9350_Network_Driver_XMJK7_WN32_12.0.1.720_A00.EXE .exe]. You need to extract the {{ic|.exe}} file with {{Pkg|p7zip}} and then convert it to a {{ic|.hcd}} file with ''hex2hcd'' from {{Pkg|bluez-utils}}:<br />
<br />
$ 7z x 9350_Network_Driver_XMJK7_WN32_12.0.1.720_A00.EXE<br />
$ cp Win32/BCM4350C5_003.006.007.0095.1703.hex ./<br />
$ hex2hcd BCM4350C5_003.006.007.0095.1703.hex<br />
# mv BCM4350C5_003.006.007.0095.1703.hcd /lib/firmware/brcm/BCM-0a5c-6412.hcd<br />
<br />
Alternatively, you may simply install {{AUR|bcm4350-firmware}}.<br />
<br />
After a reboot, the firmware should be available for your Bluetooth interface.<br />
<br />
== Video ==<br />
The video should work with the {{ic|i915}} driver of the current {{Pkg|linux}} kernel. Consult [[Intel graphics]] for a detailed installation and configuration guide as well as for [[Intel graphics#Troubleshooting|Troubleshooting]].<br />
<br />
=== Blank screen issue after booting ===<br />
If using "late start" [[KMS]] (the default) and the screen goes blank when loading modules, it may help to add {{ic|i915}} and {{ic|intel_agp}} to the initramfs or using a special [[kernel parameter]]. Consult [[Intel graphics#Blank screen during boot, when "Loading modules"]] for more information about the kernel paramter way and have a look at [[Kernel mode setting#Early KMS start]] for a guide on how to setup the modules for the initramfs.<br />
<br />
=== Linux kernel 4.8 or later power savings ===<br />
<br />
{{warning|The following options of the {{ic|i915}} module taint the kernel, use at your own risks!}}<br />
<br />
====RC6====<br />
{{ic|i915.enable_rc6&#61;1}} seems to be stable, setting the value to a higher number will be ignored is therefore confusing, the deeper GPU power states that this option enables (RC6p and RC6pp) do not exist on gen7+ hardware.[https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/i915/i915_drv.h#n2862][https://lists.freedesktop.org/archives/intel-gfx/2012-June/018383.html].<br />
<br />
====Panel Self Refresh====<br />
{{ic|i915.enable_psr&#61;1}} allows for some really nice power savings by leaving the package longer in more efficient C-states. However, users experience freezes for a few seconds with this option fairly often, setting the value to [https://patchwork.kernel.org/patch/8182841/ 2 or 3] may yield to similar power savings but without the freezes.<br />
{{ic|i915.disable_power_well&#61;0}} with {{ic|i915.enable_psr&#61;1 i915.enable_rc6&#61;1}} also seems to be a stable configuration for PSR.<br />
<br />
====Frame Buffer Compression====<br />
{{ic|i915.enable_fbc&#61;1}} is stable but does not seem to yield significant power saving results.<br />
<br />
====GuC====<br />
[https://01.org/linuxgraphics/intel-linux-graphics-firmwares GuC] loading with {{ic|i915.enable_guc_loading&#61;1 i915.enable_guc_submission&#61;1}} seems stable too.<br />
<br />
=== Linux kernel 4.3 or earlier ===<br />
<br />
If you are using an older kernel 4.3 or earlier, you also require the kernel parameter {{ic|i915.preliminary_hw_support&#61;1}}, see [[Intel graphics#Skylake support]]. (For later kernels 4.3+ or {{AUR|linux-bcm4350}} the parameter is unnecessary.)<br />
<br />
=== Linux kernel 4.5 or earlier ===<br />
<br />
If you have the newer i7-6560 CPU with Iris 540 graphics, the GPU hangs every few minutes with kernel versions before 4.6. This is probably due to this bug https://bugs.freedesktop.org/show_bug.cgi?id=94161 and can be countered by either disabling DRI in your Xorg configuration:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-intel.conf|<br />
Section "Device"<br />
Identifier "Intel Graphics"<br />
Driver "intel"<br />
Option "DRI" "false"<br />
EndSection<br />
}}<br />
<br />
or by adding {{ic|1=i915.enable_rc6=0}} to the kernel boot parameters.<br />
<br />
== Touchpad ==<br />
Only key-presses work out of the box. Installing {{pkg|xf86-input-libinput}} is sufficient for proper mouse support plus it also handles the touchscreen - see [[libinput]] for configuration. Features such as tap-to-click are usually adjustable within the [[desktop environment]].<br />
<br />
Alternatively you may want to install {{pkg|xf86-input-synaptics}} as driver but "it is on maintenance mode and {{pkg|xf86-input-libinput}} must be preferred over" (installation note from the package itself). Plus it may lack the ability to be easily adjustable within your [[desktop environment]] (see [[Dell Studio XPS 13]]). Restarting the X server might be required.<br />
<br />
=== Remove psmouse errors from dmesg ===<br />
<br />
If {{ic|<nowiki>dmesg | grep -i psmouse</nowiki>}} returns an error, but your touchpad still works, then it might be a good idea to disable {{ic|psmouse}}. First create a config file:<br />
<br />
# nano /etc/modprobe.d/modprobe.conf<br />
<br />
blacklist psmouse<br />
<br />
Then add this file to {{ic|/etc/mkinitcpio.conf}}:<br />
<br />
...<br />
FILES="/etc/modprobe.d/modprobe.conf"<br />
...<br />
<br />
Rebuild your initial ramdisk image (see [[Mkinitcpio#Image creation and activation]]).<br />
<br />
=== Gestures ===<br />
<br />
Refer to [[libinput#Gestures]] for information about the current development state and available methods.<br />
<br />
== Sound ==<br />
<br />
=== Hissing/Crackling noises when using headphones ===<br />
<br />
Some people reported white hissing/crackling noises when using headphones. To get rid of them you can run {{ic|alsamixer}} from {{Pkg|alsa-utils}}.<br />
Select your soundcard with F6 and set the headset-gain to 22 (3rd lever from the left) or use the {{ic|amixer}} command:<br />
<br />
$ amixer -c 0 cset 'numid=10' 1<br />
numid=10,iface=MIXER,name='Headphone Mic Boost Volume'<br />
; type=INTEGER,access=rw---R--,values=2,min=0,max=3,step=0<br />
: values=1,1<br />
| dBscale-min=0.00dB,step=10.00dB,mute=0<br />
<br />
Unfortunately [[PulseAudio]] will override the above setting every time you log in/out of your environment (or every time the PulseAudio service is restarted), even if the {{ic|alsa-restore.service}} is enabled at [[start]] up.<br />
<br />
To work around this issue, edit {{ic|/usr/share/pulseaudio/alsa-mixer/paths/analog-input-headphone-mic.conf}} and comment out the section {{ic|[Element Headphone Mic Boost]}}:<br />
<br />
---<br />
#[Element Headphone Mic Boost]<br />
#required-any = any<br />
#switch = select<br />
#volume = merge<br />
#override-map.1 = all<br />
#override-map.2 = all-left,all-right<br />
---<br />
<br />
Similarly in {{ic|/usr/share/pulseaudio/alsa-mixer/paths/analog-input-internal-mic.conf}}, comment out the same section:<br />
<br />
---<br />
#[Element Headphone Mic Boost]<br />
#switch = off<br />
#volume = off<br />
---<br />
<br />
This will prevent PulseAudio to fiddle with the gain setting at all.<br />
<br />
{{Note|Unfortunately, you must make the same modifications every time the PulseAudio package is updated. Additionally, this will entirely disable the internal microphone.}}<br />
<br />
== Microphone ==<br />
{{Note| Not all hardware has the "Digital" channel}}<br />
For ALSA, increase "Digital" channel for microphone to work.<br />
<br />
== TPM ==<br />
<br />
As shipped the Trusted Platform Module (TPM) can be configured easily following the steps at [[Trusted Platform Module]] and requires no otherwise special configuration.<br />
<br />
=== TPM 2.0 ===<br />
<br />
Originally the Dell XPS 13 (9350) shipped with TPM 1.2 - the TPM chip was configured to support the TPM Standard version 1.2. However, on 6 Jan 2017 Dell released a [http://www.dell.com/support/home/uk/en/ukdhs1/Drivers/DriversDetails?driverId=N8P80 firmware update] (internal version 1.3.1.0_V1) for the TPM chip that converts it to support the feature set of TPM Standard version 2.0. Unfortunately, as of this moment the update cannot be applied through Linux or the BIOS direct flashing capabilities. The only way to install it seems to be to apply it through a running Windows OS. The easiest method is to run a temporary Windows installation on a USB drive, boot into it and run the update from there. {{Warning| It should be noted that this update is irreversible once applied. It also requires that the TPM memory and configuration is completely cleared.}}<br />
{{Note| As for BIOS updates, please make sure the laptop is plugged in to a power source and that power source is stable.}}<br />
<br />
To install the update one can follow the instructions on the above mentioned firmware update page to clear and reset the TPM chip and initiate the update. Users intending to later use the device in Linux, can skip the last steps 11 & 12 from section "Disable TPM Auto Provisioning in Windows". Another option is to just clear the TPM following [http://www.dell.com/support/article/uk/en/ukbsdt1/SLN155219/en this guide] and just run the {{ic|.exe}} file from Windows.<br />
<br />
Once the update succeeds, the Linux kernel should automatically recognise the newly configured TPM device and enable is automatically on next boot. To make use of the now TPM 2.0 chip a couple are worth installing - {{AUR|tpm2.0-tss-git}} and {{AUR|tpm2.0-tools-git}}. To make the TSS resource manager work on boot, a handy systemd service is provided and its variants discussed [https://github.com/01org/TPM2.0-TSS/issues/321 here]<br />
<br />
== CPU slowdown after resume from suspend ==<br />
If you are experiencing a very slow computer after resume from suspend, you may be subject to a bug where your CPU frequency is capped to a very low value. Use {{ic|cpupower frequency-info}} to check. If so, please read [https://bbs.archlinux.org/viewtopic.php?pid=1558948#p1558948 this forum thread] for debug information, and a workaround.<br />
<br />
== lspci and lsusb ==<br />
<br />
{{Accuracy|According links unter [[#See also]] should be sufficient. It is therefore not necessary to list the output here.}}<br />
<br />
The <tt>lspci</tt> and <tt>lsusb</tt> below were take from the following system:<br />
<br />
[ 0.000000] DMI: Dell Inc. XPS 13 9350/0PWNCR, BIOS 1.3.3 03/01/2016<br />
<br />
on kernel:<br />
<br />
Linux marv 4.5.4-1-ARCH #1 SMP PREEMPT Wed May 11 22:21:28 CEST 2016 x86_64 GNU/Linux<br />
<br />
=== lspci ===<br />
<br />
00:00.0 Host bridge: Intel Corporation Skylake Host Bridge/DRAM Registers (rev 08)<br />
00:02.0 VGA compatible controller: Intel Corporation Skylake Integrated Graphics (rev 07)<br />
00:04.0 Signal processing controller: Intel Corporation Skylake Processor Thermal Subsystem (rev 08)<br />
00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller (rev 21)<br />
00:14.2 Signal processing controller: Intel Corporation Sunrise Point-LP Thermal subsystem (rev 21)<br />
00:15.0 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #0 (rev 21)<br />
00:15.1 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #1 (rev 21)<br />
00:16.0 Communication controller: Intel Corporation Sunrise Point-LP CSME HECI #1 (rev 21)<br />
00:1c.0 PCI bridge: Intel Corporation Device 9d10 (rev f1)<br />
00:1c.4 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #5 (rev f1)<br />
00:1c.5 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #6 (rev f1)<br />
00:1d.0 PCI bridge: Intel Corporation Device 9d18 (rev f1)<br />
00:1f.0 ISA bridge: Intel Corporation Sunrise Point-LP LPC Controller (rev 21)<br />
00:1f.2 Memory controller: Intel Corporation Sunrise Point-LP PMC (rev 21)<br />
00:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev 21)<br />
00:1f.4 SMBus: Intel Corporation Sunrise Point-LP SMBus (rev 21)<br />
3a:00.0 Network controller: Broadcom Corporation BCM4350 802.11ac Wireless Network Adapter (rev 08)<br />
3b:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS525A PCI Express Card Reader (rev 01)<br />
3c:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller (rev 01)<br />
<br />
[https://gist.github.com/mgalgs/a903e3528f48aa25b5c0b9ae9c09a07f Full output from sudo lspci -v]<br />
<br />
After plugging in a USB-C hub, a number of new PCI devices appear:<br />
<br />
01:00.0 PCI bridge: Intel Corporation Device 1576<br />
02:00.0 PCI bridge: Intel Corporation Device 1576<br />
02:01.0 PCI bridge: Intel Corporation Device 1576<br />
02:02.0 PCI bridge: Intel Corporation Device 1576<br />
39:00.0 USB controller: Intel Corporation Device 15b5<br />
<br />
=== lsusb ===<br />
<br />
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub<br />
Bus 001 Device 004: ID 0c45:670c Microdia <br />
Bus 001 Device 003: ID 04f3:20d0 Elan Microelectronics Corp. <br />
Bus 001 Device 002: ID 0a5c:6412 Broadcom Corp. <br />
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub<br />
<br />
[https://gist.github.com/mgalgs/15fb0d19795f700d60f061f67dddbefc Full output from sudo lsusb -v]<br />
<br />
== See also ==<br />
<br />
* [https://bbs.archlinux.org/viewtopic.php?pid=1579113 Arch Forum thread for XPS 13]<br />
* [http://www.dell.com/support/home/us/en/19/product-support/product/xps-13-9350-laptop/drivers Dell XPS 13 9350 driver and firmware updates]</div>Kgizdovhttps://wiki.archlinux.org/index.php?title=Pacman/Package_signing&diff=455630Pacman/Package signing2016-10-31T20:11:46Z<p>Kgizdov: /* Cannot import keys */ make a note to address some more persistent issues with key servers; I believe this should be part of the #Setup as it happends on all newly installed machines and neither pacman-key nor gpg detect it</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Package management]]<br />
[[es:Pacman/Package signing]]<br />
[[fr:pacman-key]]<br />
[[it:Pacman/Package signing]]<br />
[[ja:Pacman-key]]<br />
[[ru:Pacman/Package signing]]<br />
[[tr:pacman paket imzaları]]<br />
[[zh-cn:Pacman/Package signing]]<br />
{{Related articles start}}<br />
{{Related|GnuPG}}<br />
{{Related|DeveloperWiki:Package signing}}<br />
{{Related articles end}}<br />
To determine if packages are authentic, ''pacman'' uses [http://www.gnupg.org/ GnuPG keys] in a [http://www.gnupg.org/gph/en/manual.html#AEN385 web of trust] model. There are currently five [https://www.archlinux.org/master-keys/ Master Signing Keys]. At least three of these Master Signing Keys are used to sign each of the Developer's and Trusted User's own keys which then in turn are used to sign their packages. The user also has a unique PGP key which is generated when you set up ''pacman-key''. So the web of trust links the user's key to the five Master Keys.<br />
<br />
Examples of webs of trust:<br />
<br />
* '''Custom packages''': You made the package yourself and signed it with your own key.<br />
* '''Unofficial packages''': A developer made the package and signed it. You used your key to sign that developer's key.<br />
* '''Official packages''': A developer made the package and signed it. The developer's key was signed by the Arch Linux master keys. You used your key to sign the master keys, and you trust them to vouch for developers.<br />
<br />
{{Note|The HKP protocol uses 11371/tcp for communication. In order to get the signed keys from the servers (using ''pacman-key''), this port is required for communication.}}<br />
<br />
== Setup ==<br />
<br />
=== Configuring pacman ===<br />
<br />
The {{ic|SigLevel}} option in {{ic|/etc/pacman.conf}} determines how much trust is required to install a package. For a detailed explanation of {{ic|SigLevel}} see the [https://www.archlinux.org/pacman/pacman.conf.5.html#_package_and_database_signature_checking pacman.conf man page] and the comments in the file itself. Signature checking may be set globally or per repository. If {{ic|SigLevel}} is set globally in the {{ic|[options]}} section to require all packages to be signed, then packages you build will also need to be signed using ''makepkg''.<br />
<br />
{{Note|Although all official packages are now signed, as of June 2012 signing of the databases is a work in progress. If {{ic|Required}} is set then {{ic|DatabaseOptional}} should also be set.}}<br />
<br />
A default configuration can be used to only install packages that are signed by trusted keys:<br />
<br />
{{hc|1=/etc/pacman.conf|<br />
output=SigLevel = Required DatabaseOptional<br />
}}<br />
<br />
This is because {{ic|TrustedOnly}} is a default compiled-in ''pacman'' parameter. So above leads to the same result as a global option of:<br />
<br />
SigLevel = Required DatabaseOptional TrustedOnly<br />
<br />
The above can be achieved too on a repository level further below in the configuration, e.g.:<br />
<br />
[core]<br />
SigLevel = PackageRequired<br />
Include = /etc/pacman.d/mirrorlist<br />
<br />
explicitly adds signature checking for the packages of the repository, but does not require the database to be signed. {{ic|Optional}} here would turn off a global {{ic|Required}} for this repository<br />
<br />
{{warning|The SigLevel {{ic|TrustAll}} option exists for debugging purposes and makes it very easy to trust keys that have not been verified. You should use {{ic|TrustedOnly}} for all official repositories.}}<br />
<br />
=== Initializing the keyring ===<br />
<br />
To set up the ''pacman'' keyring use:<br />
<br />
# pacman-key --init<br />
<br />
For this initialization, [[Wikipedia:Entropy_(computing)|entropy]] is required. Moving your mouse around, pressing random characters at the keyboard or running some disk-based activity (for example in another console running {{ic|ls -R /}} or {{ic|find / -name foo}} or {{ic|1=dd if=/dev/sda8 of=/dev/tty7}}) should generate entropy. If your system does not already have sufficient entropy, this step may take hours; if you actively generate entropy, it will complete much more quickly.<br />
<br />
The randomness created is used to set up a keyring ({{ic|/etc/pacman.d/gnupg}}) and the GPG signing key of your system.<br />
<br />
{{Note|If you need to run {{ic|pacman-key --init}} on computer that does not generate much entropy (e.g. a headless server), key generation may take a very long time. To generate pseudo-entropy, install either [[haveged]] or [[rng-tools]] on the target machine and start the corresponding service before running {{ic|pacman-key --init}}.}}<br />
<br />
== Managing the keyring ==<br />
<br />
=== Verifying the five master keys ===<br />
<br />
The initial setup of keys is achieved using:<br />
# pacman-key --populate archlinux<br />
Take time to verify the [https://www.archlinux.org/master-keys/ Master Signing Keys] when prompted as these are used to co-sign (and therefore trust) all other packager's keys.<br />
<br />
PGP keys are too large (2048 bits or more) for humans to work with, so they are usually hashed to create a 40-hex-digit fingerprint which can be used to check by hand that two keys are the same. The last eight digits of the fingerprint serve as a name for the key known as the '(short) key ID' (the last ''sixteen'' digits of the fingerprint would be the 'long key ID').<br />
<br />
=== Adding developer keys ===<br />
<br />
The official developer and TU keys are signed by the master keys, so you do not need to use ''pacman-key'' to sign them yourself. Whenever ''pacman'' encounters a key it does not recognize, it will prompt to download it from a {{ic|keyserver}} configured in {{ic|/etc/pacman.d/gnupg/gpg.conf}} (or by using the {{ic|--keyserver}} option on the command line). Wikipedia maintains a [[wikipedia:Key server (cryptographic)|list of keyservers]].<br />
<br />
Once you have downloaded a developer key, you will not have to download it again, and it can be used to verify any other packages signed by that developer.<br />
<br />
{{Note|The {{Pkg|archlinux-keyring}} package, which is a dependency of {{Pkg|pacman}}, contains the latest keys. However keys can also be updated manually using {{ic|pacman-key --refresh-keys}} (as root). While doing {{ic|--refresh-keys}}, your local key will also be looked up on the remote keyserver, and you will receive a message about it being not found. This is nothing to be concerned about.}}<br />
<br />
=== Adding unofficial keys ===<br />
<br />
You can use this method, for example, to add your own key to the ''pacman'' keyring, or when enabling a signed [[Unofficial user repositories|unofficial repository]].<br />
<br />
First get the key ID ({{ic|''keyid''}}) from the owner of the key. Then you need to add the key to the keyring:<br />
<br />
* If the key is found on a keyserver, import it with: {{bc|# pacman-key -r ''keyid''}}<br />
<br />
* If otherwise a link to a keyfile is provided, download it and then run: {{bc|# pacman-key --add ''/path/to/downloaded/keyfile''}}<br />
<br />
Always be sure to verify the fingerprint, as you would with a master key, or any other key which you are going to sign.<br />
$ pacman-key -f ''keyid''<br />
<br />
Finally, you need to locally sign the imported key:<br />
# pacman-key --lsign-key ''keyid''<br />
<br />
You now trust this key to sign packages.<br />
<br />
=== Debugging with gpg ===<br />
<br />
For debugging purposes, you can access ''pacman'''s keyring directly with ''gpg'', e.g.:<br />
<br />
# gpg --homedir /etc/pacman.d/gnupg --list-keys<br />
<br />
== Troubleshooting ==<br />
<br />
{{Style|Instructions could be clearer}}<br />
<br />
{{Warning|''pacman-key'' depends on [[time]]. If your system clock is wrong, you'll get:<br />
error: PackageName: signature from "User <email@archlinux.org>" is invalid<br />
error: failed to commit transaction (invalid or corrupted package (PGP signature))<br />
Errors occured, no packages were upgraded.<br />
}}<br />
<br />
=== Cannot import keys ===<br />
<br />
There are multiple possible sources of this problem:<br />
<br />
* An outdated {{Pkg|archlinux-keyring}} package.<br />
* Incorrect date.<br />
* Your ISP blocked the port used to import PGP keys.<br />
* Your ''pacman'' cache contains copy of unsigned packages from previous attempts.<br />
* {{ic|dirmngr}} is not correctly configured<br />
<br />
You might be stuck because of outdated {{Pkg|archlinux-keyring}} package when doing an upgrade synchronization. Try if [[Pacman#Upgrading_packages|upgrading the system]] can fix it first.<br />
<br />
If you are still having issues, make sure the following file exists {{ic|/root/.gnupg/dirmngr_ldapservers.conf}} and that you can successfully run {{ic|# dirmngr}}. Create an empty file if it doesn't and run {{ic|# dirmngr}} again.<br />
<br />
If it does not help and your date is correct, you could try to switch to the MIT keyserver, which provides an alternate port. To do this, edit {{ic|/etc/pacman.d/gnupg/gpg.conf}} and change the {{ic|keyserver}} line to:<br />
<br />
keyserver hkp://pgp.mit.edu:11371<br />
<br />
If this does not help either, change the keyserver to the kjsl keyserver, which provides this service through port 80 (the HTTP port), which should always remain unblocked:<br />
<br />
keyserver hkp://keyserver.kjsl.com:80<br />
<br />
If you have IPv6 disabled, ''gpg'' will fail when it found some IPv6 address. In this case try with an IPv4-only keyserver like:<br />
<br />
keyserver hkp://ipv4.pool.sks-keyservers.net:11371<br />
<br />
If you happen to forget to run {{ic|pacman-key --populate archlinux}} you might get some errors while importing keys.<br />
<br />
If none of this helps, your ''pacman'' cache, located at {{ic|/var/cache/pacman/pkg/}} might contain unsigned packages from previous attempts. Try cleaning the cache manually or run:<br />
<br />
# pacman -Sc<br />
<br />
which removes all cached packages that have not been installed.<br />
<br />
=== Disabling signature checking ===<br />
<br />
{{Warning|Use with caution. Disabling package signing will allow ''pacman'' to install untrusted packages automatically.}}<br />
<br />
If you are not concerned about package signing, you can disable PGP signature checking completely. Edit {{ic|/etc/pacman.conf}} and uncomment the following line under {{ic|[options]}}:<br />
<br />
SigLevel = Never<br />
<br />
You need to comment out any repository-specific SigLevel settings too because they override the global settings. This will result in no signature checking, which was the behavior before pacman 4. If you decide to do this, you do not need to set up a keyring with ''pacman-key''. You can change this option later if you decide to enable package verification.<br />
<br />
=== Resetting all the keys ===<br />
<br />
If you want to remove or reset all the keys installed in your system, you can remove {{ic|/etc/pacman.d/gnupg}} folder as root and rerun {{ic|pacman-key --init}} and following that add the keys as preferred.<br />
<br />
=== Removing stale packages ===<br />
<br />
If the same packages keep failing and you are sure you did all the ''pacman-key'' stuff right, try removing them like so {{ic|rm /var/cache/pacman/pkg/''badpackage''*}} so that they are freshly downloaded.<br />
<br />
This might actually be the solution if you get a message like {{ic|error: linux: signature from "Some Person <Some.Person@example.com>" is invalid}} or similar when upgrading (i.e. you might not be the victim of a MITM attack after all, your downloaded file was simply corrupt).<br />
<br />
=== Updating keys via proxy ===<br />
<br />
In order to use a proxy when updating keys the {{ic|honor-http-proxy}} option must be set in both {{ic|/etc/gnupg/dirmngr.conf}} and {{ic|/etc/pacman.d/gnupg/dirmngr.conf}}. See [[GnuPG#Use a keyserver]] for more information.<br />
<br />
{{Note|If ''pacman-key'' is used without the {{ic|honor-http-proxy}} option and fails, a reboot may solve the issue.}}<br />
<br />
== See also ==<br />
<br />
* [[DeveloperWiki:Package Signing Proposal for Pacman]]<br />
* [http://allanmcrae.com/2011/08/pacman-package-signing-1-makepkg-and-repo-add/ Pacman Package Signing – 1: Makepkg and Repo-add]<br />
* [http://allanmcrae.com/2011/08/pacman-package-signing-2-pacman-key/ Pacman Package Signing – 2: Pacman-key]<br />
* [http://allanmcrae.com/2011/08/pacman-package-signing-3-pacman/ Pacman Package Signing – 3: Pacman]<br />
* [http://allanmcrae.com/2011/12/pacman-package-signing-4-arch-linux/ Pacman Package Signing – 4: Arch Linux]</div>Kgizdovhttps://wiki.archlinux.org/index.php?title=Pacman/Package_signing&diff=455619Pacman/Package signing2016-10-31T18:49:52Z<p>Kgizdov: /* Initializing the keyring */ make a note to address some more persistent issues with key servers</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Package management]]<br />
[[es:Pacman/Package signing]]<br />
[[fr:pacman-key]]<br />
[[it:Pacman/Package signing]]<br />
[[ja:Pacman-key]]<br />
[[ru:Pacman/Package signing]]<br />
[[tr:pacman paket imzaları]]<br />
[[zh-cn:Pacman/Package signing]]<br />
{{Related articles start}}<br />
{{Related|GnuPG}}<br />
{{Related|DeveloperWiki:Package signing}}<br />
{{Related articles end}}<br />
To determine if packages are authentic, ''pacman'' uses [http://www.gnupg.org/ GnuPG keys] in a [http://www.gnupg.org/gph/en/manual.html#AEN385 web of trust] model. There are currently five [https://www.archlinux.org/master-keys/ Master Signing Keys]. At least three of these Master Signing Keys are used to sign each of the Developer's and Trusted User's own keys which then in turn are used to sign their packages. The user also has a unique PGP key which is generated when you set up ''pacman-key''. So the web of trust links the user's key to the five Master Keys.<br />
<br />
Examples of webs of trust:<br />
<br />
* '''Custom packages''': You made the package yourself and signed it with your own key.<br />
* '''Unofficial packages''': A developer made the package and signed it. You used your key to sign that developer's key.<br />
* '''Official packages''': A developer made the package and signed it. The developer's key was signed by the Arch Linux master keys. You used your key to sign the master keys, and you trust them to vouch for developers.<br />
<br />
{{Note|The HKP protocol uses 11371/tcp for communication. In order to get the signed keys from the servers (using ''pacman-key''), this port is required for communication.}}<br />
<br />
== Setup ==<br />
<br />
=== Configuring pacman ===<br />
<br />
The {{ic|SigLevel}} option in {{ic|/etc/pacman.conf}} determines how much trust is required to install a package. For a detailed explanation of {{ic|SigLevel}} see the [https://www.archlinux.org/pacman/pacman.conf.5.html#_package_and_database_signature_checking pacman.conf man page] and the comments in the file itself. Signature checking may be set globally or per repository. If {{ic|SigLevel}} is set globally in the {{ic|[options]}} section to require all packages to be signed, then packages you build will also need to be signed using ''makepkg''.<br />
<br />
{{Note|Although all official packages are now signed, as of June 2012 signing of the databases is a work in progress. If {{ic|Required}} is set then {{ic|DatabaseOptional}} should also be set.}}<br />
<br />
A default configuration can be used to only install packages that are signed by trusted keys:<br />
<br />
{{hc|1=/etc/pacman.conf|<br />
output=SigLevel = Required DatabaseOptional<br />
}}<br />
<br />
This is because {{ic|TrustedOnly}} is a default compiled-in ''pacman'' parameter. So above leads to the same result as a global option of:<br />
<br />
SigLevel = Required DatabaseOptional TrustedOnly<br />
<br />
The above can be achieved too on a repository level further below in the configuration, e.g.:<br />
<br />
[core]<br />
SigLevel = PackageRequired<br />
Include = /etc/pacman.d/mirrorlist<br />
<br />
explicitly adds signature checking for the packages of the repository, but does not require the database to be signed. {{ic|Optional}} here would turn off a global {{ic|Required}} for this repository<br />
<br />
{{warning|The SigLevel {{ic|TrustAll}} option exists for debugging purposes and makes it very easy to trust keys that have not been verified. You should use {{ic|TrustedOnly}} for all official repositories.}}<br />
<br />
=== Initializing the keyring ===<br />
<br />
To set up the ''pacman'' keyring use:<br />
<br />
# pacman-key --init<br />
<br />
For this initialization, [[Wikipedia:Entropy_(computing)|entropy]] is required. Moving your mouse around, pressing random characters at the keyboard or running some disk-based activity (for example in another console running {{ic|ls -R /}} or {{ic|find / -name foo}} or {{ic|1=dd if=/dev/sda8 of=/dev/tty7}}) should generate entropy. If your system does not already have sufficient entropy, this step may take hours; if you actively generate entropy, it will complete much more quickly.<br />
<br />
The randomness created is used to set up a keyring ({{ic|/etc/pacman.d/gnupg}}) and the GPG signing key of your system.<br />
<br />
{{Note|If you need to run {{ic|pacman-key --init}} on computer that does not generate much entropy (e.g. a headless server), key generation may take a very long time. To generate pseudo-entropy, install either [[haveged]] or [[rng-tools]] on the target machine and start the corresponding service before running {{ic|pacman-key --init}}.}}<br />
<br />
{{Note|If you are still having issues, make sure the following file exists {{ic|/root/.gnupg/dirmngr_ldapservers.conf}} and that you can successfully run {{ic|# dirmngr}}. Create an empty file if it doesn't and run {{ic|#dirmngr}} again.}}<br />
<br />
== Managing the keyring ==<br />
<br />
=== Verifying the five master keys ===<br />
<br />
The initial setup of keys is achieved using:<br />
# pacman-key --populate archlinux<br />
Take time to verify the [https://www.archlinux.org/master-keys/ Master Signing Keys] when prompted as these are used to co-sign (and therefore trust) all other packager's keys.<br />
<br />
PGP keys are too large (2048 bits or more) for humans to work with, so they are usually hashed to create a 40-hex-digit fingerprint which can be used to check by hand that two keys are the same. The last eight digits of the fingerprint serve as a name for the key known as the '(short) key ID' (the last ''sixteen'' digits of the fingerprint would be the 'long key ID').<br />
<br />
=== Adding developer keys ===<br />
<br />
The official developer and TU keys are signed by the master keys, so you do not need to use ''pacman-key'' to sign them yourself. Whenever ''pacman'' encounters a key it does not recognize, it will prompt to download it from a {{ic|keyserver}} configured in {{ic|/etc/pacman.d/gnupg/gpg.conf}} (or by using the {{ic|--keyserver}} option on the command line). Wikipedia maintains a [[wikipedia:Key server (cryptographic)|list of keyservers]].<br />
<br />
Once you have downloaded a developer key, you will not have to download it again, and it can be used to verify any other packages signed by that developer.<br />
<br />
{{Note|The {{Pkg|archlinux-keyring}} package, which is a dependency of {{Pkg|pacman}}, contains the latest keys. However keys can also be updated manually using {{ic|pacman-key --refresh-keys}} (as root). While doing {{ic|--refresh-keys}}, your local key will also be looked up on the remote keyserver, and you will receive a message about it being not found. This is nothing to be concerned about.}}<br />
<br />
=== Adding unofficial keys ===<br />
<br />
You can use this method, for example, to add your own key to the ''pacman'' keyring, or when enabling a signed [[Unofficial user repositories|unofficial repository]].<br />
<br />
First get the key ID ({{ic|''keyid''}}) from the owner of the key. Then you need to add the key to the keyring:<br />
<br />
* If the key is found on a keyserver, import it with: {{bc|# pacman-key -r ''keyid''}}<br />
<br />
* If otherwise a link to a keyfile is provided, download it and then run: {{bc|# pacman-key --add ''/path/to/downloaded/keyfile''}}<br />
<br />
Always be sure to verify the fingerprint, as you would with a master key, or any other key which you are going to sign.<br />
$ pacman-key -f ''keyid''<br />
<br />
Finally, you need to locally sign the imported key:<br />
# pacman-key --lsign-key ''keyid''<br />
<br />
You now trust this key to sign packages.<br />
<br />
=== Debugging with gpg ===<br />
<br />
For debugging purposes, you can access ''pacman'''s keyring directly with ''gpg'', e.g.:<br />
<br />
# gpg --homedir /etc/pacman.d/gnupg --list-keys<br />
<br />
== Troubleshooting ==<br />
<br />
{{Style|Instructions could be clearer}}<br />
<br />
{{Warning|''pacman-key'' depends on [[time]]. If your system clock is wrong, you'll get:<br />
error: PackageName: signature from "User <email@archlinux.org>" is invalid<br />
error: failed to commit transaction (invalid or corrupted package (PGP signature))<br />
Errors occured, no packages were upgraded.<br />
}}<br />
<br />
=== Cannot import keys ===<br />
<br />
There are multiple possible sources of this problem:<br />
<br />
* An outdated {{Pkg|archlinux-keyring}} package.<br />
* Incorrect date.<br />
* Your ISP blocked the port used to import PGP keys.<br />
* Your ''pacman'' cache contains copy of unsigned packages from previous attempts.<br />
<br />
You might be stuck because of outdated {{Pkg|archlinux-keyring}} package when doing an upgrade synchronization. Try if [[Pacman#Upgrading_packages|upgrading the system]] can fix it first.<br />
<br />
If it does not help and your date is correct, you could try to switch to the MIT keyserver, which provides an alternate port. To do this, edit {{ic|/etc/pacman.d/gnupg/gpg.conf}} and change the {{ic|keyserver}} line to:<br />
<br />
keyserver hkp://pgp.mit.edu:11371<br />
<br />
If this does not help either, change the keyserver to the kjsl keyserver, which provides this service through port 80 (the HTTP port), which should always remain unblocked:<br />
<br />
keyserver hkp://keyserver.kjsl.com:80<br />
<br />
If you have IPv6 disabled, ''gpg'' will fail when it found some IPv6 address. In this case try with an IPv4-only keyserver like:<br />
<br />
keyserver hkp://ipv4.pool.sks-keyservers.net:11371<br />
<br />
If you happen to forget to run {{ic|pacman-key --populate archlinux}} you might get some errors while importing keys.<br />
<br />
If none of this helps, your ''pacman'' cache, located at {{ic|/var/cache/pacman/pkg/}} might contain unsigned packages from previous attempts. Try cleaning the cache manually or run:<br />
<br />
# pacman -Sc<br />
<br />
which removes all cached packages that have not been installed.<br />
<br />
=== Disabling signature checking ===<br />
<br />
{{Warning|Use with caution. Disabling package signing will allow ''pacman'' to install untrusted packages automatically.}}<br />
<br />
If you are not concerned about package signing, you can disable PGP signature checking completely. Edit {{ic|/etc/pacman.conf}} and uncomment the following line under {{ic|[options]}}:<br />
<br />
SigLevel = Never<br />
<br />
You need to comment out any repository-specific SigLevel settings too because they override the global settings. This will result in no signature checking, which was the behavior before pacman 4. If you decide to do this, you do not need to set up a keyring with ''pacman-key''. You can change this option later if you decide to enable package verification.<br />
<br />
=== Resetting all the keys ===<br />
<br />
If you want to remove or reset all the keys installed in your system, you can remove {{ic|/etc/pacman.d/gnupg}} folder as root and rerun {{ic|pacman-key --init}} and following that add the keys as preferred.<br />
<br />
=== Removing stale packages ===<br />
<br />
If the same packages keep failing and you are sure you did all the ''pacman-key'' stuff right, try removing them like so {{ic|rm /var/cache/pacman/pkg/''badpackage''*}} so that they are freshly downloaded.<br />
<br />
This might actually be the solution if you get a message like {{ic|error: linux: signature from "Some Person <Some.Person@example.com>" is invalid}} or similar when upgrading (i.e. you might not be the victim of a MITM attack after all, your downloaded file was simply corrupt).<br />
<br />
=== Updating keys via proxy ===<br />
<br />
In order to use a proxy when updating keys the {{ic|honor-http-proxy}} option must be set in both {{ic|/etc/gnupg/dirmngr.conf}} and {{ic|/etc/pacman.d/gnupg/dirmngr.conf}}. See [[GnuPG#Use a keyserver]] for more information.<br />
<br />
{{Note|If ''pacman-key'' is used without the {{ic|honor-http-proxy}} option and fails, a reboot may solve the issue.}}<br />
<br />
== See also ==<br />
<br />
* [[DeveloperWiki:Package Signing Proposal for Pacman]]<br />
* [http://allanmcrae.com/2011/08/pacman-package-signing-1-makepkg-and-repo-add/ Pacman Package Signing – 1: Makepkg and Repo-add]<br />
* [http://allanmcrae.com/2011/08/pacman-package-signing-2-pacman-key/ Pacman Package Signing – 2: Pacman-key]<br />
* [http://allanmcrae.com/2011/08/pacman-package-signing-3-pacman/ Pacman Package Signing – 3: Pacman]<br />
* [http://allanmcrae.com/2011/12/pacman-package-signing-4-arch-linux/ Pacman Package Signing – 4: Arch Linux]</div>Kgizdovhttps://wiki.archlinux.org/index.php?title=Libvirt&diff=453639Libvirt2016-10-11T22:58:41Z<p>Kgizdov: /* Management */ Remove unneeded/confusing notes</p>
<hr />
<div>{{DISPLAYTITLE:libvirt}}<br />
[[Category:Virtualization]]<br />
[[ja:libvirt]]<br />
[[zh-CN:Libvirt]]<br />
[[zh-TW:Libvirt]]<br />
{{Related articles start}}<br />
{{Related|:Category:Hypervisors}}<br />
{{Related|:PCI passthrough via OVMF}}<br />
{{Related articles end}}<br />
<br />
Libvirt is collection of software that provides a convenient way to manage virtual machines and other virtualization functionality, such as storage and network interface management. These software pieces include a long term stable C API, a daemon (libvirtd), and a command line utility (virsh). A primary goal of libvirt is to provide a single way to manage multiple different virtualization providers/hypervisors, such as the [[QEMU|KVM/QEMU]], [[Xen]], [[LXC]], [http://openvz.org OpenVZ] or [[VirtualBox]] [[:Category:Hypervisors|hypervisors]] ([http://libvirt.org/drivers.html among others]).<br />
<br />
Some of the major libvirt features are:<br />
*'''VM management''': Various domain lifecycle operations such as start, stop, pause, save, restore, and migrate. Hotplug operations for many device types including disk and network interfaces, memory, and cpus.<br />
*'''Remote machine support''': All libvirt functionality is accessible on any machine running the libvirt daemon, including remote machines. A variety of network transports are supported for connecting remotely, with the simplest being SSH, which requires no extra explicit configuration.<br />
*'''Storage management''': Any host running the libvirt daemon can be used to manage various types of storage: create file images of various formats (qcow2, vmdk, raw, ...), mount NFS shares, enumerate existing LVM volume groups, create new LVM volume groups and logical volumes, partition raw disk devices, mount iSCSI shares, and much more.<br />
*'''Network interface management''': Any host running the libvirt daemon can be used to manage physical and logical network interfaces. Enumerate existing interfaces, as well as configure (and create) interfaces, bridges, vlans, and bond devices.<br />
*'''Virtual NAT and Route based networking''': Any host running the libvirt daemon can manage and create virtual networks. Libvirt virtual networks use firewall rules to act as a router, providing VMs transparent access to the host machines network.<br />
<br />
== Installation ==<br />
<br />
Because of its daemon/client architecture, libvirt needs only be installed on the machine which will host the virtualized system. Note that the server and client can be the same physical machine.<br />
<br />
=== Server ===<br />
<br />
[[Install]] the {{pkg|libvirt}} package, as well as at least one hypervisor:<br />
<br />
* The [http://libvirt.org/drvqemu.html libvirt KVM/QEMU driver] is the primary ''libvirt'' driver and if [[QEMU#Enabling_KVM|KVM is enabled]], fully virtualized, hardware accelerated guests will be available. See the [[QEMU]] article for more informations.<br />
<br />
* Other [http://libvirt.org/drivers.html supported hypervisors] include [[LXC]], [[VirtualBox]] and [[Xen]]. See the respective articles for installation instructions. With respect to {{ic|libvirtd}} installation note: <br />
** The [http://libvirt.org/drvlxc.html libvirt LXC driver] has no dependency on the [[LXC]] userspace tools provided by {{Pkg|lxc}}, therefore there is no need to install the package if planning on using the driver.<br />
** [[Xen]] support is available, but not by default. You need to use the [[ABS]] to modify {{Pkg|libvirt}}'s [[PKGBUILD]] and build it without the {{ic|--without-xen}} option. As VirtualBox in turn has no planned stable support for Xen, you might as well replace it with {{ic|--without-vbox}}.<br />
<br />
For network connectivity, install: <br />
<br />
* {{Pkg|ebtables}} '''and''' {{Pkg|dnsmasq}} for the [http://wiki.libvirt.org/page/VirtualNetworking#The_default_configuration default] NAT/DHCP networking.<br />
* {{Pkg|bridge-utils}} for bridged networking.<br />
* {{Pkg|openbsd-netcat}} for remote management over [[SSH]].<br />
<br />
=== Client ===<br />
<br />
The client is the user interface that will be used to manage and access the virtual machines.<br />
<br />
* ''virsh'' is a command line program for managing and configuring domains; it is included in the {{Pkg|libvirt}} package.<br />
* {{Pkg|virt-manager}} is a graphical user interface for managing virtual machines.<br />
* {{Pkg|virtviewer}} is a lightweight interface for interacting with the graphical display of virtualized guest OS.<br />
* {{Pkg|gnome-boxes}} is a simple GNOME 3 application to access remote or virtual systems.<br />
* {{AUR|virt-manager-qt5}}<br />
* {{AUR|libvirt-sandbox}} is an application sandbox toolkit.<br />
<br />
A list of libvirt-compatible software can be found [http://libvirt.org/apps.html here].<br />
<br />
== Configuration ==<br />
<br />
For '''''system'''''-level administration (i.e. global settings and image-''volume'' location), libvirt minimally requires [[#Set up authentication|setting up authorization]], and [[#Daemon|starting the daemon]].<br />
<br />
{{Note|For user-'''''session''''' administration, daemon setup and configuration is ''not'' required; authorization, however, is limited to local abilities; the front-end will launch a local instance of the '''libvirtd''' daemon.}}<br />
<br />
=== Set up authentication ===<br />
<br />
From [http://libvirt.org/auth.html#ACL_server_config libvirt: Connection authentication]:<br />
:The libvirt daemon allows the administrator to choose the authentication mechanisms used for client connections on each network socket independently. This is primarily controlled via the libvirt daemon master config file in {{ic|/etc/libvirt/libvirtd.conf}}. Each of the libvirt sockets can have its authentication mechanism configured independently. There is currently a choice of {{ic|none}}, {{ic|polkit}} and {{ic|sasl}}. <br />
<br />
Because {{Pkg|libvirt}} pulls {{Pkg|polkit}} as a dependency during installation, [[#Using polkit|polkit]] is used as the default value for the {{ic|unix_sock_auth}} parameter ([http://libvirt.org/auth.html#ACL_server_polkit source]). [[#Authenticate with file-based permissions|File-based permissions]] remain nevertheless available.<br />
<br />
==== Using polkit ====<br />
{{Note|A system reboot may be required before authenticating with {{ic|polkit}} works correctly.}}<br />
<br />
The ''libvirt'' daemon provides two [[Polkit#Actions|polkit actions]] in {{ic|/usr/share/polkit-1/actions/org.libvirt.unix.policy}}:<br />
* {{ic|org.libvirt.unix.manage}} for full management access (RW daemon socket), and<br />
* {{ic|org.libvirt.unix.monitor}} for monitoring only access (read-only socket).<br />
<br />
The default policy for the RW daemon socket will require to authenticate as an admin. This is akin to [[sudo]] auth, but does not require that the client application ultimately run as root. Default policy will still allow any application to connect to the RO socket.<br />
<br />
Arch defaults to consider anybody in the {{ic|wheel}} group as an administrator: this is defined in {{ic|/etc/polkit-1/rules.d/50-default.rules}} (see [[Polkit#Administrator identities]]). Therefore there is no need to create a new group and rule file '''if your user is a member of the {{ic|wheel}} group''': upon connection to the RW socket (e.g. via {{Pkg|virt-manager}}) you will be prompted for your user's password.<br />
<br />
{{Note|Prompting for a password relies on the presence of an [[Polkit#Authentication_agents|authentication agent]] on the system. Console users may face an issue with the default {{ic|pkttyagent}} agent which may or may not work properly.}}<br />
<br />
{{Tip|If you want to configure passwordless authentication, see [[Polkit#Bypass password prompt]].}}<br />
<br />
As of libvirt 1.2.16 (commit:[http://libvirt.org/git/?p=libvirt.git;a=commit;h=e94979e901517af9fdde358d7b7c92cc055dd50c]), members of the {{ic|libvirt}} group have passwordless access to the RW daemon socket by default. The easiest way to ensure your user has access is to ensure the libvirt group exists and they are a member of it. If you wish to change the group authorized to access the RW daemon socket to be the kvm group, create the following file:<br />
<br />
{{hc|/etc/polkit-1/rules.d/50-libvirt.rules|<nowiki><br />
/* Allow users in kvm group to manage the libvirt<br />
daemon without authentication */<br />
polkit.addRule(function(action, subject) {<br />
if (action.id == "org.libvirt.unix.manage" &&<br />
subject.isInGroup("kvm")) {<br />
return polkit.Result.YES;<br />
}<br />
});</nowiki><br />
}}<br />
<br />
Then [[Users_and_groups#Other_examples_of_user_management|add yourself]] to the {{ic|kvm}} group and relogin. Replace ''kvm'' with any group of your preference just make sure it exists and that your user is a member of it (see [[Users and groups]] for more information).<br />
<br />
Do not forget to relogin for group changes to take effect.<br />
<br />
==== Authenticate with file-based permissions ====<br />
<br />
To define file-based permissions for users in the ''libvirt'' group to manage virtual machines, uncomment and define:<br />
<br />
{{hc|/etc/libvirt/libvirtd.conf|<nowiki><br />
#unix_sock_group = "libvirt"<br />
#unix_sock_ro_perms = "0777" # set to 0770 to deny non-group libvirt users<br />
#unix_sock_rw_perms = "0770"<br />
#auth_unix_ro = "none"<br />
#auth_unix_rw = "none"<br />
</nowiki>}}<br />
<br />
While some guides mention changed permissions of certain libvirt directories to ease management, keep in mind permissions are lost on package update. To edit these system directories, root user is expected.<br />
<br />
=== Daemon ===<br />
<br />
[[Start]] both {{ic|libvirtd.service}} and {{ic|virtlogd.service}}. Optionally [[enable]] {{ic|libvirtd.service}}. There is no need to enable {{ic|virtlogd.service}}, since {{ic|libvirtd.service}}, when enabled, also enables the {{ic|virtlogd.socket}} and {{ic|virtlockd.socket}} [[Systemd#Using_units|units]].<br />
<br />
=== Unencrypt TCP/IP sockets ===<br />
<br />
{{Warning|This method is used to help remote domain, connection speed for trusted networks. This is the least secure connection method. This should ''only'' be used for testing or use over a secure, private, and trusted network. SASL is not enabled here, so all TCP traffic is ''cleartext''. For real world use ''always'' enable SASL.}}<br />
<br />
Edit {{ic|/etc/libvirt/libvirtd.conf}}:<br />
{{hc|/etc/libvirt/libvirtd.conf|<nowiki><br />
listen_tls = 0<br />
listen_tcp = 1<br />
auth_tcp=none<br />
</nowiki>}}<br />
<br />
It is also necessary to start the server in listening mode by editing {{ic|/etc/conf.d/libvirtd}}:<br />
<br />
{{hc|/etc/conf.d/libvirtd|2=LIBVIRTD_ARGS="--listen"}}<br />
<br />
=== Access virtual machines using their hostnames ===<br />
<br />
For host access to guests on non-isolated, bridged networks, enable the {{ic|libvirt}} NSS module provided by {{Pkg|libvirt}}.<br />
<br />
Edit {{ic|/etc/nsswitch.conf}}:<br />
{{hc|/etc/nsswitch.conf|<nowiki><br />
hosts: files libvirt dns myhostname<br />
</nowiki>}}<br />
<br />
{{Note|While commands such as {{ic|ping}} and {{ic|ssh}} should work with virtual machine hostnames, commands such as {{ic|host}} and {{ic|nslookup}} may fail or produce unexpected results because they rely on DNS. Use {{ic|getent hosts <vm-hostname>}} instead.}}<br />
<br />
== Test ==<br />
<br />
To test if libvirt is working properly on a ''system'' level:<br />
<br />
$ virsh -c qemu:///system<br />
<br />
To test if libvirt is working properly for a user-''session'':<br />
<br />
$ virsh -c qemu:///session<br />
<br />
== Management ==<br />
<br />
Libvirt management is done mostly with three tools: {{Pkg|virt-manager}} (GUI), {{ic|virsh}}, and {{ic|guestfish}} (which is part of {{AUR|libguestfs}}).<br />
<br />
=== virsh ===<br />
<br />
The virsh program is for managing guest ''domains'' (virtual machines) and works well for scripting, virtualization administration. Though most virsh commands require root privileges to run due to the communication channels used to talk to the hypervisor, typical management, creation, and running of domains (like that done with VirtualBox) can be done as a regular user.<br />
<br />
Virsh includes an interactive terminal that can be entered if no commands are passed (options are allowed though): {{ic|virsh}}. The interactive terminal has support for tab completion.<br />
<br />
From the command line:<br />
<br />
$ virsh [option] <command> [argument]...<br />
<br />
From the interactive terminal:<br />
<br />
virsh # <command> [argument]...<br />
<br />
Help is available:<br />
<br />
$ virsh help [option*] or [group-keyword*]<br />
<br />
=== Storage pools ===<br />
<br />
A pool is a location where storage ''volumes'' can be kept. What libvirt defines as ''volumes'' others may define as "virtual disks" or "virtual machine images". Pool locations may be a directory, a network filesystem, or partition (this includes a [[LVM]]). Pools can be toggled active or inactive and allocated for space.<br />
<br />
On the ''system''-level, {{ic|/var/lib/libvirt/images/}} will be activated by default; on a user-''session'', {{ic|virt-manager}} creates {{ic|$HOME/VirtualMachines}}.<br />
<br />
Print active and inactive storage pools:<br />
<br />
$ virsh pool-list --all<br />
<br />
==== Create a new pool using virsh ====<br />
<br />
If wanted to ''add'' a storage pool, here are examples of the command form, adding a directory, and adding a LVM volume:<br />
<br />
$ virsh pool-define-as name type [source-host] [source-path] [source-dev] [source-name] [<target>] [--source-format format]<br />
$ virsh pool-define-as ''poolname'' dir - - - - /home/''username''/.local/libvirt/images<br />
$ virsh pool-define-as ''poolname'' fs - - ''/dev/vg0/images'' - ''mntpoint''<br />
<br />
The above command defines the information for the pool, to build it:<br />
<br />
$ virsh pool-build ''poolname''<br />
$ virsh pool-start ''poolname''<br />
$ virsh pool-autostart ''poolname''<br />
<br />
To remove it:<br />
<br />
$ virsh pool-undefine ''poolname''<br />
<br />
{{Tip|For LVM storage pools:<br />
* It is a good practice to dedicate a volume group to the storage pool only. <br />
* Choose a LVM volume group that differs from the pool name, otherwise when the storage pool is deleted the LVM group will be too.<br />
}}<br />
<br />
==== Create a new pool using virt-manager ====<br />
<br />
First, connect to a hypervisor (e.g. QEMU/KVM ''system'', or user-''session''). Then, right-click on a connection and select ''Details''; select the ''Storage'' tab, push the ''+'' button on the lower-left, and follow the wizard.<br />
<br />
=== Storage volumes ===<br />
<br />
Once the pool has been created, volumes can be created inside the pool. ''If building a new domain (virtual machine), this step can be skipped as a volume can be created in the domain creation process.''<br />
<br />
==== Create a new volume with virsh ====<br />
<br />
Create volume, list volumes, resize, and delete:<br />
$ virsh vol-create-as ''poolname'' ''volumename'' 10GiB --format aw|bochs|raw|qcow|qcow2|vmdk<br />
$ virsh vol-upload --pool ''poolname'' ''volumename'' ''volumepath''<br />
$ virsh vol-list ''poolname''<br />
$ virsh vol-resize --pool ''poolname'' ''volumename'' 12GiB<br />
$ virsh vol-delete --pool ''poolname'' ''volumename''<br />
$ virsh vol-dumpxml --pool ''poolname'' ''volumename'' # for details.<br />
<br />
==== virt-manager backing store type bug ====<br />
<br />
On newer versions of {{ic|virt-manager}} you can now specify a backing store to use when creating a new disk. This is very useful, in that you can have new domains be based on base images saving you both time and disk space when provisioning new virtual systems. There is a bug (https://bugzilla.redhat.com/show_bug.cgi?id=1235406) in the current version of {{ic|virt-manager}} which causes {{ic|virt-manager}} to choose the wrong type of the backing image in the case where the backing image is a {{ic|qcow2}} type. In this case, it will errantly pick the backing type as {{ic|raw}}. This will cause the new image to be unable to read from the backing store, and effectively remove the utility of having a backing store at all.<br />
<br />
There is a workaround for this issue. {{ic|qemu-img}} has long been able to do this operation directly. If you wish to have a backing store for your new domain before this bug is fixed, you may use the following command.<br />
<br />
$ qemu-img create -f qcow2 -o backing_file=<path to backing image>,backing_fmt=qcow2 <disk name> <disk size><br />
<br />
Then you can use this image as the base for your new domain and it will use the backing store as a COW volume saving you time and disk space.<br />
<br />
=== Domains ===<br />
<br />
Virtual machines are called ''domains''. If working from the command line, use {{ic|virsh}} to list, create, pause, shutdown domains, etc. {{ic|virt-viewer}} can be used to view domains started with {{ic|virsh}}. Creation of domains is typically done either graphically with {{ic|virt-manager}} or with {{ic|virt-install}} (a command line program that is part of the {{pkg|virt-manager}} package).<br />
<br />
Creating a new domain typically involves using some installation media, such as an {{ic|.iso}} from the storage pool or an optical drive.<br />
<br />
Print active and inactive domains:<br />
<br />
# virsh list --all<br />
<br />
{{note|[[SELinux]] has a built-in exemption for libvirt that allows volumes in {{ic|/var/lib/libvirt/images/}} to be accessed. If using SELinux and there are issues with the volumes, ensure that volumes are in that directory, or ensure that other storage pools are correctly labeled.}}<br />
<br />
==== Create a new domain using virt-install ====<br />
<br />
For an extremely detailed domain (virtual machine) setup, it is easier to [[#Create a new domain using virt-manager]]. However, basics can easily be done with {{ic|virt-install}} and still run quite well. Minimum specifications are {{ic|--name}}, {{ic|--memory}}, guest storage ({{ic|--disk}}, {{ic|--filesystem}}, or {{ic|--nodisks}}), and an install method (generally an {{ic|.iso}} or CD). See {{ic|man virt-install}} for more details and information about unlisted options.<br />
<br />
Arch Linux install (two GiB, qcow2 format volume create; user-networking):<br />
<br />
$ virt-install \<br />
--name arch-linux_testing \<br />
--memory 1024 \ <br />
--vcpus=2,maxvcpus=4 \<br />
--cpu host \<br />
--cdrom $HOME/Downloads/arch-linux_install.iso \<br />
--disk size=2,format=qcow2 \<br />
--network user \<br />
--virt-type kvm<br />
<br />
Fedora testing (Xen hypervisor, non-default pool, do not originally view):<br />
<br />
$ virt-install \<br />
--connect xen:/// \<br />
--name fedora-testing \<br />
--memory 2048 \<br />
--vcpus=2 \<br />
--cpu=host \<br />
--cdrom /tmp/fedora20_x84-64.iso \<br />
--os-type=linux --os-variant=fedora20 \<br />
--disk pool=testing,size=4 \<br />
--network bridge=br0 \<br />
--graphics=vnc \<br />
--noautoconsole<br />
$ virt-viewer --connect xen:/// fedora-testing<br />
<br />
Windows:<br />
<br />
$ virt-install \<br />
--name=windows7 \<br />
--memory 2048 \<br />
--cdrom /dev/sr0 \<br />
--os-variant=win7 \<br />
--disk /mnt/storage/domains/windows7.qcow2,size=20GiB \<br />
--network network=vm-net \<br />
--graphics spice<br />
<br />
{{Tip|Run {{ic|1=osinfo-query --fields=name,short-id,version os}} to get argument for {{ic|--os-variant}}; this will help define some specifications for the domain. However, {{ic|--memory}} and {{ic|--disk}} will need to be entered; one can look within the appropriate {{ic|/usr/share/libosinfo/db/oses/''os''.xml}} if needing these specifications. After installing, it will likely be preferable to install the [http://www.spice-space.org/download.html Spice Guest Tools] that include the [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization_Host_Configuration_and_Guest_Installation_Guide/form-Virtualization_Host_Configuration_and_Guest_Installation_Guide-Para_virtualized_drivers-Mounting_the_image_with_virt_manager.html VirtIO drivers]. For a Windows VirtIO network driver there is also {{Aur|virtio-win}}. These drivers are referenced by a {{ic|1=<model type='virtio' />}} in the guest's {{ic|.xml}} configuration section for the device. A bit more information can also be found on the [[QEMU#Preparing_a_Windows_guest|QEMU article]].}}<br />
<br />
Import existing volume:<br />
<br />
$ virt-install \<br />
--name demo \<br />
--memory 512 \<br />
--disk /home/user/VMs/mydisk.img \<br />
--import<br />
<br />
==== Create a new domain using virt-manager ====<br />
<br />
First, connect to the hypervisor (e.g. QEMU/KVM ''system'' or user ''session''), right click on a connection and select ''New'', and follow the wizard.<br />
<br />
* On the ''fourth step'', de-selecting ''Allocate entire disk now'' will make setup quicker and can save disk space in the interum; ''however'', it may cause volume fragmentation over time.<br />
* On the ''fifth step'', open ''Advanced options'' and make sure that ''Virt Type'' is set to ''kvm'' (this is usually the preferred method). If additional hardware setup is required, select the ''Customize configuration before install'' option.<br />
<br />
==== Manage a domain ====<br />
<br />
Start a domain:<br />
<br />
$ virsh start ''domain''<br />
$ virt-viewer --connect qemu:///session ''domain''<br />
<br />
Gracefully attempt to shutdown a domain; force off a domain:<br />
<br />
$ virsh shutdown ''domain''<br />
$ virsh destroy ''domain''<br />
<br />
Autostart domain on libvirtd start:<br />
<br />
$ virsh autostart ''domain''<br />
$ virsh autostart ''domain'' --disable<br />
<br />
Shutdown domain on host shutdown:<br />
<br />
: Running domains can be automatically suspended/shutdown at host shutdown using the {{ic|libvirt-guests.service}} systemd service. This same service will resume/startup the suspended/shutdown domain automatically at host startup. Read {{ic|/etc/conf.d/libvirt-guests}} for service options.<br />
<br />
Edit a domain's XML configuration:<br />
<br />
$ virsh edit ''domain''<br />
<br />
{{note|Virtual Machines started directly by QEMU are not managable by libvirt tools.}}<br />
<br />
=== Networks ===<br />
<br />
A [https://jamielinux.com/docs/libvirt-networking-handbook/ decent overview of libvirt networking].<br />
<br />
By default, when the {{ic|libvirtd}} systemd service is started, a NAT bridge is created called ''default'' to allow external network connectivity (warning see: [[#"default" network bug]]{{Broken section link}}). For other network connectivity needs, four network types exist that can be created to connect a domain to:<br />
<br />
* bridge — a virtual device; shares data directly with a physical interface. Use this if the host has ''static'' networking, it does not need to connect other domains, the domain requires full inbound and outbound trafficking, and the domain is running on a ''system''-level. See [[Network bridge]] on how to add a bridge additional to the default one. After creation, it needs to be specified in the respective guest's {{ic|.xml}} configuration file. <br />
* network — a virtual network; has ability to share with other domains. Use a virtual network if the host has ''dynamic'' networking (e.g. NetworkManager), or using wireless.<br />
* macvtap — connect directly to a host physical interface.<br />
* user — local ability networking. Use this only for a user ''session''.<br />
<br />
{{ic|virsh}} has the ability to create networking with numerous options for most users, however, it is easier to create network connectivity with a graphic user interface (like {{ic|virt-manager}}), or to do so on [[#Create a new domain using virt-install|creation with virt-install]].<br />
<br />
{{note|libvirt handles DHCP and DNS with {{pkg|dnsmasq}}, launching a separate instance for every virtual network. It also adds iptables rules for proper routing, and enables the {{ic|ip_forward}} kernel parameter. This also means that having dnsmasq running on the host system is not necessary to support libvirt requirements (and could interfere with libvirt dnsmasq instances).}}<br />
<br />
=== Snapshots ===<br />
<br />
Snapshots take the disk, memory, and device state of a domain at a point-of-time, and save it for future use. They have many uses, from saving a "clean" copy of an OS image to saving a domain's state before a potentially destructive operation. Snapshots are identified with a unique name.<br />
<br />
Snapshots are saved within the volume itself and the volume must be the format: qcow2 or raw. Snapshots use deltas so they have the potentiality to not take much space.<br />
<br />
==== Create a snapshot ====<br />
<br />
{{Out of date|Some of this data appears to be dated.}}<br />
<br />
Once a snapshot is taken it is saved as a new block device and the original snapshot is taken offline. Snapshots can be chosen from and also merged into another (even without shutting down the domain).<br />
<br />
Print a running domain's volumes (running domains can be printed with {{ic|virsh list}}):<br />
<br />
{{hc|# virsh domblklist ''domain''|<nowiki><br />
Target Source<br />
------------------------------------------------<br />
vda /vms/domain.img<br />
</nowiki>}}<br />
<br />
To see a volume's physical properties:<br />
<br />
{{hc|# qemu-img info /vms/domain.img|<nowiki><br />
image: /vms/domain.img<br />
file format: qcow2<br />
virtual size: 50G (53687091200 bytes)<br />
disk size: 2.1G<br />
cluster_size: 65536<br />
</nowiki>}}<br />
<br />
Create a disk-only snapshot (the option {{ic|--atomic}} will prevent the volume from being modified if snapshot creation fails):<br />
<br />
# virsh snapshot-create-as ''domain'' snapshot1 --disk-only --atomic<br />
<br />
List snapshots:<br />
<br />
{{hc|# virsh snapshot-list ''domain''|<nowiki><br />
Name Creation Time State<br />
------------------------------------------------------------<br />
snapshot1 2012-10-21 17:12:57 -0700 disk-snapshot<br />
</nowiki>}}<br />
<br />
One can they copy the original image with {{ic|1=cp --sparse=true}} or {{ic|rsync -S}} and then merge the the original back into snapshot:<br />
<br />
# virsh blockpull --domain ''domain'' --path /vms/''domain''.snapshot1<br />
<br />
{{ic|domain.snapshot1}} becomes a new volume. After this is done the original volume ({{ic|domain.img}} and snapshot metadata can be deleted. The {{ic|virsh blockcommit}} would work opposite to {{ic|blockpull}} but it seems to be currently under development (including {{ic|snapshot-revert feature}}, scheduled to be released sometime next year.<br />
<br />
=== Other management ===<br />
<br />
Connect to non-default hypervisor:<br />
<br />
$ virsh --connect xen:///<br />
virsh # uri<br />
xen:///<br />
<br />
Connect to the QEMU hypervisor over SSH; and the same with logging:<br />
<br />
$ virsh --connect qemu+ssh://''username''@''host''/system<br />
$ LIBVIRT_DEBUG=1 virsh --connect qemu+ssh://''username''@''host''/system<br />
<br />
Connect a graphic console over SSH:<br />
<br />
$ virt-viewer --connect qemu+ssh://''username''@''host''/system ''domain''<br />
$ virt-manager --connect qemu+ssh://''username''@''host''/system ''domain''<br />
<br />
{{Note|If you are having problems connecting to a remote RHEL server (or anything other than Arch, really), try the two workarounds mentioned in {{bug|30748}} and {{bug|22068}}.}}<br />
<br />
Connect to the VirtualBox hypervisor (''VirtualBox support in libvirt is not stable yet and may cause libvirtd to crash''):<br />
<br />
$ virsh --connect vbox:///system<br />
<br />
Network configurations:<br />
<br />
$ virsh -c qemu:///system net-list --all<br />
$ virsh -c qemu:///system net-dumpxml default<br />
<br />
== Python connectivity code ==<br />
<br />
The {{Pkg|libvirt-python}} package provides a {{Pkg|python2}} API in {{ic|/usr/lib/python2.7/site-packages/libvirt.py}}.<br />
<br />
General examples are given in {{ic|/usr/share/doc/libvirt-python-''your_libvirt_version''/examples/}}<br />
<br />
Unofficial example using {{Pkg|qemu}} and {{Pkg|openssh}}:<br />
<br />
#! /usr/bin/env python2<br />
# -*- coding: utf-8 -*-<br />
import socket<br />
import sys<br />
import libvirt<br />
if (__name__ == "__main__"):<br />
<nowiki>conn = libvirt.open("qemu+ssh://xxx/system")</nowiki><br />
print "Trying to find node on xxx"<br />
domains = conn.listDomainsID()<br />
for domainID in domains:<br />
domConnect = conn.lookupByID(domainID)<br />
if domConnect.name() == 'xxx-node':<br />
print "Found shared node on xxx with ID " + str(domainID)<br />
domServ = domConnect<br />
break<br />
<br />
== UEFI Support ==<br />
<br />
Libvirt can suport UEFI virtual machines through QEMU and [https://github.com/tianocore/edk2 OVMF].<br />
<br />
Currently this is possible in Arch Linux through a workaround. [https://bugs.archlinux.org/index.php?do=details&action=details.addvote&task_id=47101 This ovmf packaging bug] needs to be resolved for this to work out of the box or with minimal configuration of {{ic|/etc/libvirt/qemu.conf}}.<br />
<br />
=== OVMF - QEMU workaround ===<br />
<br />
* Build {{Pkg|ovmf}} from the [[ABS]] with {{ic|makepkg}}.<br />
* Copy the {{ic|OVMF_CODE.fd}} and {{ic|OVMF_VARS.fd}} files either for 64 or 32 bit to the default qemu location.<br />
<br />
{{hc|/etc/libvirt/qemu.conf|<nowiki><br />
#nvram = [<br />
# "/usr/share/OVMF/OVMF_CODE.fd:/usr/share/OVMF/OVMF_VARS.fd",<br />
# "/usr/share/OVMF/OVMF_CODE.secboot.fd:/usr/share/OVMF/OVMF_VARS.fd",<br />
# "/usr/share/AAVMF/AAVMF_CODE.fd:/usr/share/AAVMF/AAVMF_VARS.fd"<br />
#]<br />
</nowiki><br />
}}<br />
<br />
# mkdir /usr/share/OVMF<br />
# cp src/edk2/Build/OvmfX64/RELEASE_GCC49/FV/OVMF_CODE.fd src/edk2/Build/OvmfX64/RELEASE_GCC49/FV/OVMF_VARS.fd /usr/share/OVMF/ <br />
<br />
* Restart {{ic|libvirtd}}<br />
<br />
# systemctl stop libvirtd<br />
# systemctl start libvirtd<br />
<br />
Now you are ready to create a uefi virtual machine. Create a new virtual machine through {{Pkg|virt-manager}}. When you get to the final page of the 'New VM' wizard, do the following: <br />
<br />
* Click 'Customize before install', then select 'Finish'<br />
* On the 'Overview' screen, Change the 'Firmware' field to select the 'UEFI x86_64' option.<br />
* Click 'Begin Installation'<br />
* The boot screen you'll see should use linuxefi commands to boot the installer, and you should be able to run efibootmgr inside that system, to verify that you're running an UEFI OS. <br />
<br />
For more information about this, refer to [https://fedoraproject.org/wiki/Using_UEFI_with_QEMU this fedora wiki page].<br />
<br />
== PulseAudio ==<br />
<br />
The PulseAudio daemon normally runs under your regular user account, and will only accept connections from the same user. This can be a problem if QEMU is being run as root through [[libvirt]]. To run QEMU as a regular user, edit {{ic|/etc/libvirt/qemu.conf}} and set the {{ic|user}} option to your username.<br />
<br />
user = "dave"<br />
<br />
You will also need to tell QEMU to use the PulseAudio backend and identify the server to connect to. Add the following section to your domain configuration using {{ic|virsh edit}}.<br />
<br />
<qemu:commandline><br />
<qemu:env name='QEMU_AUDIO_DRV' value='pa'/><br />
<qemu:env name='QEMU_PA_SERVER' value='/run/user/1000/pulse/native'/><br />
</qemu:commandline><br />
<br />
{{ic|1000}} is your user id. Change it if necessary.<br />
<br />
== See also ==<br />
<br />
* [http://libvirt.org/drvqemu.html Official libvirt web site]<br />
* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Virtualization_Deployment_and_Administration_Guide/index.html Red Hat Virtualization Deployment and Administration Guide]<br />
* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Virtualization_Tuning_and_Optimization_Guide/index.html Red Hat Virtualization Tuning and Optimization Guide]<br />
* [http://docs.slackware.com/howtos:general_admin:kvm_libvirt Slackware KVM and libvirt]<br />
* [http://www-01.ibm.com/support/knowledgecenter/linuxonibm/liaat/liaatkvm.htm IBM KVM]<br />
* [https://jamielinux.com/docs/libvirt-networking-handbook/ libvirt Networking Handbook]</div>Kgizdovhttps://wiki.archlinux.org/index.php?title=Libvirt&diff=453050Libvirt2016-10-06T12:23:20Z<p>Kgizdov: /* Management */ convert warnings into more useful notes</p>
<hr />
<div>{{DISPLAYTITLE:libvirt}}<br />
[[Category:Virtualization]]<br />
[[ja:libvirt]]<br />
[[zh-CN:Libvirt]]<br />
[[zh-TW:Libvirt]]<br />
{{Related articles start}}<br />
{{Related|:Category:Hypervisors}}<br />
{{Related|:PCI passthrough via OVMF}}<br />
{{Related articles end}}<br />
<br />
Libvirt is collection of software that provides a convenient way to manage virtual machines and other virtualization functionality, such as storage and network interface management. These software pieces include a long term stable C API, a daemon (libvirtd), and a command line utility (virsh). A primary goal of libvirt is to provide a single way to manage multiple different virtualization providers/hypervisors, such as the [[QEMU|KVM/QEMU]], [[Xen]], [[LXC]], [http://openvz.org OpenVZ] or [[VirtualBox]] [[:Category:Hypervisors|hypervisors]] ([http://libvirt.org/drivers.html among others]).<br />
<br />
Some of the major libvirt features are:<br />
*'''VM management''': Various domain lifecycle operations such as start, stop, pause, save, restore, and migrate. Hotplug operations for many device types including disk and network interfaces, memory, and cpus.<br />
*'''Remote machine support''': All libvirt functionality is accessible on any machine running the libvirt daemon, including remote machines. A variety of network transports are supported for connecting remotely, with the simplest being SSH, which requires no extra explicit configuration.<br />
*'''Storage management''': Any host running the libvirt daemon can be used to manage various types of storage: create file images of various formats (qcow2, vmdk, raw, ...), mount NFS shares, enumerate existing LVM volume groups, create new LVM volume groups and logical volumes, partition raw disk devices, mount iSCSI shares, and much more.<br />
*'''Network interface management''': Any host running the libvirt daemon can be used to manage physical and logical network interfaces. Enumerate existing interfaces, as well as configure (and create) interfaces, bridges, vlans, and bond devices.<br />
*'''Virtual NAT and Route based networking''': Any host running the libvirt daemon can manage and create virtual networks. Libvirt virtual networks use firewall rules to act as a router, providing VMs transparent access to the host machines network.<br />
<br />
== Installation ==<br />
<br />
Because of its daemon/client architecture, libvirt needs only be installed on the machine which will host the virtualized system. Note that the server and client can be the same physical machine.<br />
<br />
=== Server ===<br />
<br />
[[Install]] the {{pkg|libvirt}} package, as well as at least one hypervisor:<br />
<br />
* The [http://libvirt.org/drvqemu.html libvirt KVM/QEMU driver] is the primary ''libvirt'' driver and if [[QEMU#Enabling_KVM|KVM is enabled]], fully virtualized, hardware accelerated guests will be available. See the [[QEMU]] article for more informations.<br />
<br />
* Other [http://libvirt.org/drivers.html supported hypervisors] include [[LXC]], [[VirtualBox]] and [[Xen]]. See the respective articles for installation instructions. With respect to {{ic|libvirtd}} installation note: <br />
** The [http://libvirt.org/drvlxc.html libvirt LXC driver] has no dependency on the [[LXC]] userspace tools provided by {{Pkg|lxc}}, therefore there is no need to install the package if planning on using the driver.<br />
** [[Xen]] support is available, but not by default. You need to use the [[ABS]] to modify {{Pkg|libvirt}}'s [[PKGBUILD]] and build it without the {{ic|--without-xen}} option. As VirtualBox in turn has no planned stable support for Xen, you might as well replace it with {{ic|--without-vbox}}.<br />
<br />
For network connectivity, install: <br />
<br />
* {{Pkg|ebtables}} '''and''' {{Pkg|dnsmasq}} for the [http://wiki.libvirt.org/page/VirtualNetworking#The_default_configuration default] NAT/DHCP networking.<br />
* {{Pkg|bridge-utils}} for bridged networking.<br />
* {{Pkg|openbsd-netcat}} for remote management over [[SSH]].<br />
<br />
=== Client ===<br />
<br />
The client is the user interface that will be used to manage and access the virtual machines.<br />
<br />
* ''virsh'' is a command line program for managing and configuring domains; it is included in the {{Pkg|libvirt}} package.<br />
* {{Pkg|virt-manager}} is a graphical user interface for managing virtual machines.<br />
* {{Pkg|virtviewer}} is a lightweight interface for interacting with the graphical display of virtualized guest OS.<br />
* {{Pkg|gnome-boxes}} is a simple GNOME 3 application to access remote or virtual systems.<br />
* {{AUR|virt-manager-qt5}}<br />
* {{AUR|libvirt-sandbox}} is an application sandbox toolkit.<br />
<br />
A list of libvirt-compatible software can be found [http://libvirt.org/apps.html here].<br />
<br />
== Configuration ==<br />
<br />
For '''''system'''''-level administration (i.e. global settings and image-''volume'' location), libvirt minimally requires [[#Set up authentication|setting up authorization]], and [[#Daemon|starting the daemon]].<br />
<br />
{{Note|For user-'''''session''''' administration, daemon setup and configuration is ''not'' required; authorization, however, is limited to local abilities; the front-end will launch a local instance of the '''libvirtd''' daemon.}}<br />
<br />
=== Set up authentication ===<br />
<br />
From [http://libvirt.org/auth.html#ACL_server_config libvirt: Connection authentication]:<br />
:The libvirt daemon allows the administrator to choose the authentication mechanisms used for client connections on each network socket independently. This is primarily controlled via the libvirt daemon master config file in {{ic|/etc/libvirt/libvirtd.conf}}. Each of the libvirt sockets can have its authentication mechanism configured independently. There is currently a choice of {{ic|none}}, {{ic|polkit}} and {{ic|sasl}}. <br />
<br />
Because {{Pkg|libvirt}} pulls {{Pkg|polkit}} as a dependency during installation, [[#Using polkit|polkit]] is used as the default value for the {{ic|unix_sock_auth}} parameter ([http://libvirt.org/auth.html#ACL_server_polkit source]). [[#Authenticate with file-based permissions|File-based permissions]] remain nevertheless available.<br />
<br />
==== Using polkit ====<br />
{{Note|A system reboot may be required before authenticating with {{ic|polkit}} works correctly.}}<br />
<br />
The ''libvirt'' daemon provides two [[Polkit#Actions|polkit actions]] in {{ic|/usr/share/polkit-1/actions/org.libvirt.unix.policy}}:<br />
* {{ic|org.libvirt.unix.manage}} for full management access (RW daemon socket), and<br />
* {{ic|org.libvirt.unix.monitor}} for monitoring only access (read-only socket).<br />
<br />
The default policy for the RW daemon socket will require to authenticate as an admin. This is akin to [[sudo]] auth, but does not require that the client application ultimately run as root. Default policy will still allow any application to connect to the RO socket.<br />
<br />
Arch defaults to consider anybody in the {{ic|wheel}} group as an administrator: this is defined in {{ic|/etc/polkit-1/rules.d/50-default.rules}} (see [[Polkit#Administrator identities]]). Therefore there is no need to create a new group and rule file '''if your user is a member of the {{ic|wheel}} group''': upon connection to the RW socket (e.g. via {{Pkg|virt-manager}}) you will be prompted for your user's password.<br />
<br />
{{Note|Prompting for a password relies on the presence of an [[Polkit#Authentication_agents|authentication agent]] on the system. Console users may face an issue with the default {{ic|pkttyagent}} agent which may or may not work properly.}}<br />
<br />
{{Tip|If you want to configure passwordless authentication, see [[Polkit#Bypass password prompt]].}}<br />
<br />
As of libvirt 1.2.16 (commit:[http://libvirt.org/git/?p=libvirt.git;a=commit;h=e94979e901517af9fdde358d7b7c92cc055dd50c]), members of the {{ic|libvirt}} group have passwordless access to the RW daemon socket by default. The easiest way to ensure your user has access is to ensure the libvirt group exists and they are a member of it. If you wish to change the group authorized to access the RW daemon socket to be the kvm group, create the following file:<br />
<br />
{{hc|/etc/polkit-1/rules.d/50-libvirt.rules|<nowiki><br />
/* Allow users in kvm group to manage the libvirt<br />
daemon without authentication */<br />
polkit.addRule(function(action, subject) {<br />
if (action.id == "org.libvirt.unix.manage" &&<br />
subject.isInGroup("kvm")) {<br />
return polkit.Result.YES;<br />
}<br />
});</nowiki><br />
}}<br />
<br />
Then [[Users_and_groups#Other_examples_of_user_management|add yourself]] to the {{ic|kvm}} group and relogin. Replace ''kvm'' with any group of your preference just make sure it exists and that your user is a member of it (see [[Users and groups]] for more information).<br />
<br />
Do not forget to relogin for group changes to take effect.<br />
<br />
==== Authenticate with file-based permissions ====<br />
<br />
To define file-based permissions for users in the ''libvirt'' group to manage virtual machines, uncomment and define:<br />
<br />
{{hc|/etc/libvirt/libvirtd.conf|<nowiki><br />
#unix_sock_group = "libvirt"<br />
#unix_sock_ro_perms = "0777" # set to 0770 to deny non-group libvirt users<br />
#unix_sock_rw_perms = "0770"<br />
#auth_unix_ro = "none"<br />
#auth_unix_rw = "none"<br />
</nowiki>}}<br />
<br />
While some guides mention changed permissions of certain libvirt directories to ease management, keep in mind permissions are lost on package update. To edit these system directories, root user is expected.<br />
<br />
=== Daemon ===<br />
<br />
[[Start]] both {{ic|libvirtd.service}} and {{ic|virtlogd.service}}. Optionally [[enable]] {{ic|libvirtd.service}}. There is no need to enable {{ic|virtlogd.service}}, since {{ic|libvirtd.service}}, when enabled, also enables the {{ic|virtlogd.socket}} and {{ic|virtlockd.socket}} [[Systemd#Using_units|units]].<br />
<br />
=== Unencrypt TCP/IP sockets ===<br />
<br />
{{Warning|This method is used to help remote domain, connection speed for trusted networks. This is the least secure connection method. This should ''only'' be used for testing or use over a secure, private, and trusted network. SASL is not enabled here, so all TCP traffic is ''cleartext''. For real world use ''always'' enable SASL.}}<br />
<br />
Edit {{ic|/etc/libvirt/libvirtd.conf}}:<br />
{{hc|/etc/libvirt/libvirtd.conf|<nowiki><br />
listen_tls = 0<br />
listen_tcp = 1<br />
auth_tcp=none<br />
</nowiki>}}<br />
<br />
It is also necessary to start the server in listening mode by editing {{ic|/etc/conf.d/libvirtd}}:<br />
<br />
{{hc|/etc/conf.d/libvirtd|2=LIBVIRTD_ARGS="--listen"}}<br />
<br />
=== Access virtual machines using their hostnames ===<br />
<br />
For host access to guests on non-isolated, bridged networks, enable the {{ic|libvirt}} NSS module provided by {{Pkg|libvirt}}.<br />
<br />
Edit {{ic|/etc/nsswitch.conf}}:<br />
{{hc|/etc/nsswitch.conf|<nowiki><br />
hosts: files libvirt dns myhostname<br />
</nowiki>}}<br />
<br />
{{Note|While commands such as {{ic|ping}} and {{ic|ssh}} should work with virtual machine hostnames, commands such as {{ic|host}} and {{ic|nslookup}} may fail or produce unexpected results because they rely on DNS. Use {{ic|getent hosts <vm-hostname>}} instead.}}<br />
<br />
== Test ==<br />
<br />
To test if libvirt is working properly on a ''system'' level:<br />
<br />
$ virsh -c qemu:///system<br />
<br />
To test if libvirt is working properly for a user-''session'':<br />
<br />
$ virsh -c qemu:///session<br />
<br />
== Management ==<br />
<br />
Libvirt management is done mostly with three tools: {{Pkg|virt-manager}} (GUI), {{ic|virsh}}, and {{ic|guestfish}} (which is part of {{AUR|libguestfs}}).<br />
<br />
{{Note|{{Pkg|virt-manager}} may misbehave if it cannot find the correct version of Python. Try running it with {{ic|PYTHONAPTH<nowiki>=</nowiki>/usr/bin/python2 virt-manager}} if necessary}}<br />
<br />
=== virsh ===<br />
<br />
The virsh program is for managing guest ''domains'' (virtual machines) and works well for scripting, virtualization administration. Though most virsh commands require root privileges to run due to the communication channels used to talk to the hypervisor, typical management, creation, and running of domains (like that done with VirtualBox) can be done as a regular user.<br />
<br />
Virsh includes an interactive terminal that can be entered if no commands are passed (options are allowed though): {{ic|virsh}}. The interactive terminal has support for tab completion.<br />
<br />
From the command line:<br />
<br />
$ virsh [option] <command> [argument]...<br />
<br />
From the interactive terminal:<br />
<br />
virsh # <command> [argument]...<br />
<br />
Help is available:<br />
<br />
$ virsh help [option*] or [group-keyword*]<br />
<br />
=== Storage pools ===<br />
<br />
A pool is a location where storage ''volumes'' can be kept. What libvirt defines as ''volumes'' others may define as "virtual disks" or "virtual machine images". Pool locations may be a directory, a network filesystem, or partition (this includes a [[LVM]]). Pools can be toggled active or inactive and allocated for space.<br />
<br />
On the ''system''-level, {{ic|/var/lib/libvirt/images/}} will be activated by default; on a user-''session'', {{ic|virt-manager}} creates {{ic|$HOME/VirtualMachines}}.<br />
<br />
Print active and inactive storage pools:<br />
<br />
$ virsh pool-list --all<br />
<br />
==== Create a new pool using virsh ====<br />
<br />
If wanted to ''add'' a storage pool, here are examples of the command form, adding a directory, and adding a LVM volume:<br />
<br />
$ virsh pool-define-as name type [source-host] [source-path] [source-dev] [source-name] [<target>] [--source-format format]<br />
$ virsh pool-define-as ''poolname'' dir - - - - /home/''username''/.local/libvirt/images<br />
$ virsh pool-define-as ''poolname'' fs - - ''/dev/vg0/images'' - ''mntpoint''<br />
<br />
The above command defines the information for the pool, to build it:<br />
<br />
$ virsh pool-build ''poolname''<br />
$ virsh pool-start ''poolname''<br />
$ virsh pool-autostart ''poolname''<br />
<br />
To remove it:<br />
<br />
$ virsh pool-undefine ''poolname''<br />
<br />
{{Tip|For LVM storage pools:<br />
* It is a good practice to dedicate a volume group to the storage pool only. <br />
* Choose a LVM volume group that differs from the pool name, otherwise when the storage pool is deleted the LVM group will be too.<br />
}}<br />
<br />
==== Create a new pool using virt-manager ====<br />
<br />
First, connect to a hypervisor (e.g. QEMU/KVM ''system'', or user-''session''). Then, right-click on a connection and select ''Details''; select the ''Storage'' tab, push the ''+'' button on the lower-left, and follow the wizard.<br />
<br />
=== Storage volumes ===<br />
<br />
Once the pool has been created, volumes can be created inside the pool. ''If building a new domain (virtual machine), this step can be skipped as a volume can be created in the domain creation process.''<br />
<br />
==== Create a new volume with virsh ====<br />
<br />
Create volume, list volumes, resize, and delete:<br />
$ virsh vol-create-as ''poolname'' ''volumename'' 10GiB --format aw|bochs|raw|qcow|qcow2|vmdk<br />
$ virsh vol-upload --pool ''poolname'' ''volumename'' ''volumepath''<br />
$ virsh vol-list ''poolname''<br />
$ virsh vol-resize --pool ''poolname'' ''volumename'' 12GiB<br />
$ virsh vol-delete --pool ''poolname'' ''volumename''<br />
$ virsh vol-dumpxml --pool ''poolname'' ''volumename'' # for details.<br />
<br />
==== virt-manager backing store type bug ====<br />
<br />
On newer versions of {{ic|virt-manager}} you can now specify a backing store to use when creating a new disk. This is very useful, in that you can have new domains be based on base images saving you both time and disk space when provisioning new virtual systems. There is a bug (https://bugzilla.redhat.com/show_bug.cgi?id=1235406) in the current version of {{ic|virt-manager}} which causes {{ic|virt-manager}} to choose the wrong type of the backing image in the case where the backing image is a {{ic|qcow2}} type. In this case, it will errantly pick the backing type as {{ic|raw}}. This will cause the new image to be unable to read from the backing store, and effectively remove the utility of having a backing store at all.<br />
<br />
There is a workaround for this issue. {{ic|qemu-img}} has long been able to do this operation directly. If you wish to have a backing store for your new domain before this bug is fixed, you may use the following command.<br />
<br />
$ qemu-img create -f qcow2 -o backing_file=<path to backing image>,backing_fmt=qcow2 <disk name> <disk size><br />
<br />
Then you can use this image as the base for your new domain and it will use the backing store as a COW volume saving you time and disk space.<br />
<br />
=== Domains ===<br />
<br />
Virtual machines are called ''domains''. If working from the command line, use {{ic|virsh}} to list, create, pause, shutdown domains, etc. {{ic|virt-viewer}} can be used to view domains started with {{ic|virsh}}. Creation of domains is typically done either graphically with {{ic|virt-manager}} or with {{ic|virt-install}} (a command line program that is part of the {{pkg|virt-manager}} package).<br />
<br />
{{Note|{{pkg|virt-manager}} and {{Pkg|virt-install}} require to be run with Python 2. If either complains on startup, try to run the with {{ic|$ PYTHONAPTH<nowiki>=</nowiki>/usr/bin/python2 virt-[install, manager]}}}}<br />
<br />
Creating a new domain typically involves using some installation media, such as an {{ic|.iso}} from the storage pool or an optical drive.<br />
<br />
Print active and inactive domains:<br />
<br />
# virsh list --all<br />
<br />
{{note|[[SELinux]] has a built-in exemption for libvirt that allows volumes in {{ic|/var/lib/libvirt/images/}} to be accessed. If using SELinux and there are issues with the volumes, ensure that volumes are in that directory, or ensure that other storage pools are correctly labeled.}}<br />
<br />
==== Create a new domain using virt-install ====<br />
<br />
For an extremely detailed domain (virtual machine) setup, it is easier to [[#Create a new domain using virt-manager]]. However, basics can easily be done with {{ic|virt-install}} and still run quite well. Minimum specifications are {{ic|--name}}, {{ic|--memory}}, guest storage ({{ic|--disk}}, {{ic|--filesystem}}, or {{ic|--nodisks}}), and an install method (generally an {{ic|.iso}} or CD). See {{ic|man virt-install}} for more details and information about unlisted options.<br />
<br />
Arch Linux install (two GiB, qcow2 format volume create; user-networking):<br />
<br />
$ virt-install \<br />
--name arch-linux_testing \<br />
--memory 1024 \ <br />
--vcpus=2,maxvcpus=4 \<br />
--cpu host \<br />
--cdrom $HOME/Downloads/arch-linux_install.iso \<br />
--disk size=2,format=qcow2 \<br />
--network user \<br />
--virt-type kvm<br />
<br />
Fedora testing (Xen hypervisor, non-default pool, do not originally view):<br />
<br />
$ virt-install \<br />
--connect xen:/// \<br />
--name fedora-testing \<br />
--memory 2048 \<br />
--vcpus=2 \<br />
--cpu=host \<br />
--cdrom /tmp/fedora20_x84-64.iso \<br />
--os-type=linux --os-variant=fedora20 \<br />
--disk pool=testing,size=4 \<br />
--network bridge=br0 \<br />
--graphics=vnc \<br />
--noautoconsole<br />
$ virt-viewer --connect xen:/// fedora-testing<br />
<br />
Windows:<br />
<br />
$ virt-install \<br />
--name=windows7 \<br />
--memory 2048 \<br />
--cdrom /dev/sr0 \<br />
--os-variant=win7 \<br />
--disk /mnt/storage/domains/windows7.qcow2,size=20GiB \<br />
--network network=vm-net \<br />
--graphics spice<br />
<br />
{{Tip|Run {{ic|1=osinfo-query --fields=name,short-id,version os}} to get argument for {{ic|--os-variant}}; this will help define some specifications for the domain. However, {{ic|--memory}} and {{ic|--disk}} will need to be entered; one can look within the appropriate {{ic|/usr/share/libosinfo/db/oses/''os''.xml}} if needing these specifications. After installing, it will likely be preferable to install the [http://www.spice-space.org/download.html Spice Guest Tools] that include the [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization_Host_Configuration_and_Guest_Installation_Guide/form-Virtualization_Host_Configuration_and_Guest_Installation_Guide-Para_virtualized_drivers-Mounting_the_image_with_virt_manager.html VirtIO drivers]. For a Windows VirtIO network driver there is also {{Aur|virtio-win}}. These drivers are referenced by a {{ic|1=<model type='virtio' />}} in the guest's {{ic|.xml}} configuration section for the device. A bit more information can also be found on the [[QEMU#Preparing_a_Windows_guest|QEMU article]].}}<br />
<br />
Import existing volume:<br />
<br />
$ virt-install \<br />
--name demo \<br />
--memory 512 \<br />
--disk /home/user/VMs/mydisk.img \<br />
--import<br />
<br />
==== Create a new domain using virt-manager ====<br />
<br />
First, connect to the hypervisor (e.g. QEMU/KVM ''system'' or user ''session''), right click on a connection and select ''New'', and follow the wizard.<br />
<br />
* On the ''fourth step'', de-selecting ''Allocate entire disk now'' will make setup quicker and can save disk space in the interum; ''however'', it may cause volume fragmentation over time.<br />
* On the ''fifth step'', open ''Advanced options'' and make sure that ''Virt Type'' is set to ''kvm'' (this is usually the preferred method). If additional hardware setup is required, select the ''Customize configuration before install'' option.<br />
<br />
==== Manage a domain ====<br />
<br />
Start a domain:<br />
<br />
$ virsh start ''domain''<br />
$ virt-viewer --connect qemu:///session ''domain''<br />
<br />
Gracefully attempt to shutdown a domain; force off a domain:<br />
<br />
$ virsh shutdown ''domain''<br />
$ virsh destroy ''domain''<br />
<br />
Autostart domain on libvirtd start:<br />
<br />
$ virsh autostart ''domain''<br />
$ virsh autostart ''domain'' --disable<br />
<br />
Shutdown domain on host shutdown:<br />
<br />
: Running domains can be automatically suspended/shutdown at host shutdown using the {{ic|libvirt-guests.service}} systemd service. This same service will resume/startup the suspended/shutdown domain automatically at host startup. Read {{ic|/etc/conf.d/libvirt-guests}} for service options.<br />
<br />
Edit a domain's XML configuration:<br />
<br />
$ virsh edit ''domain''<br />
<br />
{{note|Virtual Machines started directly by QEMU are not managable by libvirt tools.}}<br />
<br />
=== Networks ===<br />
<br />
A [https://jamielinux.com/docs/libvirt-networking-handbook/ decent overview of libvirt networking].<br />
<br />
By default, when the {{ic|libvirtd}} systemd service is started, a NAT bridge is created called ''default'' to allow external network connectivity (warning see: [[#"default" network bug]]{{Broken section link}}). For other network connectivity needs, four network types exist that can be created to connect a domain to:<br />
<br />
* bridge — a virtual device; shares data directly with a physical interface. Use this if the host has ''static'' networking, it does not need to connect other domains, the domain requires full inbound and outbound trafficking, and the domain is running on a ''system''-level. See [[Network bridge]] on how to add a bridge additional to the default one. After creation, it needs to be specified in the respective guest's {{ic|.xml}} configuration file. <br />
* network — a virtual network; has ability to share with other domains. Use a virtual network if the host has ''dynamic'' networking (e.g. NetworkManager), or using wireless.<br />
* macvtap — connect directly to a host physical interface.<br />
* user — local ability networking. Use this only for a user ''session''.<br />
<br />
{{ic|virsh}} has the ability to create networking with numerous options for most users, however, it is easier to create network connectivity with a graphic user interface (like {{ic|virt-manager}}), or to do so on [[#Create a new domain using virt-install|creation with virt-install]].<br />
<br />
{{note|libvirt handles DHCP and DNS with {{pkg|dnsmasq}}, launching a separate instance for every virtual network. It also adds iptables rules for proper routing, and enables the {{ic|ip_forward}} kernel parameter. This also means that having dnsmasq running on the host system is not necessary to support libvirt requirements (and could interfere with libvirt dnsmasq instances).}}<br />
<br />
=== Snapshots ===<br />
<br />
Snapshots take the disk, memory, and device state of a domain at a point-of-time, and save it for future use. They have many uses, from saving a "clean" copy of an OS image to saving a domain's state before a potentially destructive operation. Snapshots are identified with a unique name.<br />
<br />
Snapshots are saved within the volume itself and the volume must be the format: qcow2 or raw. Snapshots use deltas so they have the potentiality to not take much space.<br />
<br />
==== Create a snapshot ====<br />
<br />
{{Out of date|Some of this data appears to be dated.}}<br />
<br />
Once a snapshot is taken it is saved as a new block device and the original snapshot is taken offline. Snapshots can be chosen from and also merged into another (even without shutting down the domain).<br />
<br />
Print a running domain's volumes (running domains can be printed with {{ic|virsh list}}):<br />
<br />
{{hc|# virsh domblklist ''domain''|<nowiki><br />
Target Source<br />
------------------------------------------------<br />
vda /vms/domain.img<br />
</nowiki>}}<br />
<br />
To see a volume's physical properties:<br />
<br />
{{hc|# qemu-img info /vms/domain.img|<nowiki><br />
image: /vms/domain.img<br />
file format: qcow2<br />
virtual size: 50G (53687091200 bytes)<br />
disk size: 2.1G<br />
cluster_size: 65536<br />
</nowiki>}}<br />
<br />
Create a disk-only snapshot (the option {{ic|--atomic}} will prevent the volume from being modified if snapshot creation fails):<br />
<br />
# virsh snapshot-create-as ''domain'' snapshot1 --disk-only --atomic<br />
<br />
List snapshots:<br />
<br />
{{hc|# virsh snapshot-list ''domain''|<nowiki><br />
Name Creation Time State<br />
------------------------------------------------------------<br />
snapshot1 2012-10-21 17:12:57 -0700 disk-snapshot<br />
</nowiki>}}<br />
<br />
One can they copy the original image with {{ic|1=cp --sparse=true}} or {{ic|rsync -S}} and then merge the the original back into snapshot:<br />
<br />
# virsh blockpull --domain ''domain'' --path /vms/''domain''.snapshot1<br />
<br />
{{ic|domain.snapshot1}} becomes a new volume. After this is done the original volume ({{ic|domain.img}} and snapshot metadata can be deleted. The {{ic|virsh blockcommit}} would work opposite to {{ic|blockpull}} but it seems to be currently under development (including {{ic|snapshot-revert feature}}, scheduled to be released sometime next year.<br />
<br />
=== Other management ===<br />
<br />
Connect to non-default hypervisor:<br />
<br />
$ virsh --connect xen:///<br />
virsh # uri<br />
xen:///<br />
<br />
Connect to the QEMU hypervisor over SSH; and the same with logging:<br />
<br />
$ virsh --connect qemu+ssh://''username''@''host''/system<br />
$ LIBVIRT_DEBUG=1 virsh --connect qemu+ssh://''username''@''host''/system<br />
<br />
Connect a graphic console over SSH:<br />
<br />
$ virt-viewer --connect qemu+ssh://''username''@''host''/system ''domain''<br />
$ virt-manager --connect qemu+ssh://''username''@''host''/system ''domain''<br />
<br />
{{Note|If you are having problems connecting to a remote RHEL server (or anything other than Arch, really), try the two workarounds mentioned in {{bug|30748}} and {{bug|22068}}.}}<br />
<br />
Connect to the VirtualBox hypervisor (''VirtualBox support in libvirt is not stable yet and may cause libvirtd to crash''):<br />
<br />
$ virsh --connect vbox:///system<br />
<br />
Network configurations:<br />
<br />
$ virsh -c qemu:///system net-list --all<br />
$ virsh -c qemu:///system net-dumpxml default<br />
<br />
== Python connectivity code ==<br />
<br />
The {{Pkg|libvirt-python}} package provides a {{Pkg|python2}} API in {{ic|/usr/lib/python2.7/site-packages/libvirt.py}}.<br />
<br />
General examples are given in {{ic|/usr/share/doc/libvirt-python-''your_libvirt_version''/examples/}}<br />
<br />
Unofficial example using {{Pkg|qemu}} and {{Pkg|openssh}}:<br />
<br />
#! /usr/bin/env python2<br />
# -*- coding: utf-8 -*-<br />
import socket<br />
import sys<br />
import libvirt<br />
if (__name__ == "__main__"):<br />
<nowiki>conn = libvirt.open("qemu+ssh://xxx/system")</nowiki><br />
print "Trying to find node on xxx"<br />
domains = conn.listDomainsID()<br />
for domainID in domains:<br />
domConnect = conn.lookupByID(domainID)<br />
if domConnect.name() == 'xxx-node':<br />
print "Found shared node on xxx with ID " + str(domainID)<br />
domServ = domConnect<br />
break<br />
<br />
== UEFI Support ==<br />
<br />
Libvirt can suport UEFI virtual machines through QEMU and [https://github.com/tianocore/edk2 OVMF].<br />
<br />
Currently this is possible in Arch Linux through a workaround. [https://bugs.archlinux.org/index.php?do=details&action=details.addvote&task_id=47101 This ovmf packaging bug] needs to be resolved for this to work out of the box or with minimal configuration of {{ic|/etc/libvirt/qemu.conf}}.<br />
<br />
=== OVMF - QEMU workaround ===<br />
<br />
* Build {{Pkg|ovmf}} from the [[ABS]] with {{ic|makepkg}}.<br />
* Copy the {{ic|OVMF_CODE.fd}} and {{ic|OVMF_VARS.fd}} files either for 64 or 32 bit to the default qemu location.<br />
<br />
{{hc|/etc/libvirt/qemu.conf|<nowiki><br />
#nvram = [<br />
# "/usr/share/OVMF/OVMF_CODE.fd:/usr/share/OVMF/OVMF_VARS.fd",<br />
# "/usr/share/OVMF/OVMF_CODE.secboot.fd:/usr/share/OVMF/OVMF_VARS.fd",<br />
# "/usr/share/AAVMF/AAVMF_CODE.fd:/usr/share/AAVMF/AAVMF_VARS.fd"<br />
#]<br />
</nowiki><br />
}}<br />
<br />
# mkdir /usr/share/OVMF<br />
# cp src/edk2/Build/OvmfX64/RELEASE_GCC49/FV/OVMF_CODE.fd src/edk2/Build/OvmfX64/RELEASE_GCC49/FV/OVMF_VARS.fd /usr/share/OVMF/ <br />
<br />
* Restart {{ic|libvirtd}}<br />
<br />
# systemctl stop libvirtd<br />
# systemctl start libvirtd<br />
<br />
Now you are ready to create a uefi virtual machine. Create a new virtual machine through {{Pkg|virt-manager}}. When you get to the final page of the 'New VM' wizard, do the following: <br />
<br />
* Click 'Customize before install', then select 'Finish'<br />
* On the 'Overview' screen, Change the 'Firmware' field to select the 'UEFI x86_64' option.<br />
* Click 'Begin Installation'<br />
* The boot screen you'll see should use linuxefi commands to boot the installer, and you should be able to run efibootmgr inside that system, to verify that you're running an UEFI OS. <br />
<br />
For more information about this, refer to [https://fedoraproject.org/wiki/Using_UEFI_with_QEMU this fedora wiki page].<br />
<br />
== PulseAudio ==<br />
<br />
The PulseAudio daemon normally runs under your regular user account, and will only accept connections from the same user. This can be a problem if QEMU is being run as root through [[libvirt]]. To run QEMU as a regular user, edit {{ic|/etc/libvirt/qemu.conf}} and set the {{ic|user}} option to your username.<br />
<br />
user = "dave"<br />
<br />
You will also need to tell QEMU to use the PulseAudio backend and identify the server to connect to. Add the following section to your domain configuration using {{ic|virsh edit}}.<br />
<br />
<qemu:commandline><br />
<qemu:env name='QEMU_AUDIO_DRV' value='pa'/><br />
<qemu:env name='QEMU_PA_SERVER' value='/run/user/1000/pulse/native'/><br />
</qemu:commandline><br />
<br />
{{ic|1000}} is your user id. Change it if necessary.<br />
<br />
== See also ==<br />
<br />
* [http://libvirt.org/drvqemu.html Official libvirt web site]<br />
* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Virtualization_Deployment_and_Administration_Guide/index.html Red Hat Virtualization Deployment and Administration Guide]<br />
* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Virtualization_Tuning_and_Optimization_Guide/index.html Red Hat Virtualization Tuning and Optimization Guide]<br />
* [http://docs.slackware.com/howtos:general_admin:kvm_libvirt Slackware KVM and libvirt]<br />
* [http://www-01.ibm.com/support/knowledgecenter/linuxonibm/liaat/liaatkvm.htm IBM KVM]<br />
* [https://jamielinux.com/docs/libvirt-networking-handbook/ libvirt Networking Handbook]</div>Kgizdovhttps://wiki.archlinux.org/index.php?title=Libvirt&diff=452985Libvirt2016-10-05T18:35:32Z<p>Kgizdov: /* Domains */ add warning for missing dependency</p>
<hr />
<div>{{DISPLAYTITLE:libvirt}}<br />
[[Category:Virtualization]]<br />
[[ja:libvirt]]<br />
[[zh-CN:Libvirt]]<br />
[[zh-TW:Libvirt]]<br />
{{Related articles start}}<br />
{{Related|:Category:Hypervisors}}<br />
{{Related|:PCI passthrough via OVMF}}<br />
{{Related articles end}}<br />
<br />
Libvirt is collection of software that provides a convenient way to manage virtual machines and other virtualization functionality, such as storage and network interface management. These software pieces include a long term stable C API, a daemon (libvirtd), and a command line utility (virsh). A primary goal of libvirt is to provide a single way to manage multiple different virtualization providers/hypervisors, such as the [[QEMU|KVM/QEMU]], [[Xen]], [[LXC]], [http://openvz.org OpenVZ] or [[VirtualBox]] [[:Category:Hypervisors|hypervisors]] ([http://libvirt.org/drivers.html among others]).<br />
<br />
Some of the major libvirt features are:<br />
*'''VM management''': Various domain lifecycle operations such as start, stop, pause, save, restore, and migrate. Hotplug operations for many device types including disk and network interfaces, memory, and cpus.<br />
*'''Remote machine support''': All libvirt functionality is accessible on any machine running the libvirt daemon, including remote machines. A variety of network transports are supported for connecting remotely, with the simplest being SSH, which requires no extra explicit configuration.<br />
*'''Storage management''': Any host running the libvirt daemon can be used to manage various types of storage: create file images of various formats (qcow2, vmdk, raw, ...), mount NFS shares, enumerate existing LVM volume groups, create new LVM volume groups and logical volumes, partition raw disk devices, mount iSCSI shares, and much more.<br />
*'''Network interface management''': Any host running the libvirt daemon can be used to manage physical and logical network interfaces. Enumerate existing interfaces, as well as configure (and create) interfaces, bridges, vlans, and bond devices.<br />
*'''Virtual NAT and Route based networking''': Any host running the libvirt daemon can manage and create virtual networks. Libvirt virtual networks use firewall rules to act as a router, providing VMs transparent access to the host machines network.<br />
<br />
== Installation ==<br />
<br />
Because of its daemon/client architecture, libvirt needs only be installed on the machine which will host the virtualized system. Note that the server and client can be the same physical machine.<br />
<br />
=== Server ===<br />
<br />
[[Install]] the {{pkg|libvirt}} package, as well as at least one hypervisor:<br />
<br />
* The [http://libvirt.org/drvqemu.html libvirt KVM/QEMU driver] is the primary ''libvirt'' driver and if [[QEMU#Enabling_KVM|KVM is enabled]], fully virtualized, hardware accelerated guests will be available. See the [[QEMU]] article for more informations.<br />
<br />
* Other [http://libvirt.org/drivers.html supported hypervisors] include [[LXC]], [[VirtualBox]] and [[Xen]]. See the respective articles for installation instructions. With respect to {{ic|libvirtd}} installation note: <br />
** The [http://libvirt.org/drvlxc.html libvirt LXC driver] has no dependency on the [[LXC]] userspace tools provided by {{Pkg|lxc}}, therefore there is no need to install the package if planning on using the driver.<br />
** [[Xen]] support is available, but not by default. You need to use the [[ABS]] to modify {{Pkg|libvirt}}'s [[PKGBUILD]] and build it without the {{ic|--without-xen}} option. As VirtualBox in turn has no planned stable support for Xen, you might as well replace it with {{ic|--without-vbox}}.<br />
<br />
For network connectivity, install: <br />
<br />
* {{Pkg|ebtables}} '''and''' {{Pkg|dnsmasq}} for the [http://wiki.libvirt.org/page/VirtualNetworking#The_default_configuration default] NAT/DHCP networking.<br />
* {{Pkg|bridge-utils}} for bridged networking.<br />
* {{Pkg|openbsd-netcat}} for remote management over [[SSH]].<br />
<br />
=== Client ===<br />
<br />
The client is the user interface that will be used to manage and access the virtual machines.<br />
<br />
* ''virsh'' is a command line program for managing and configuring domains; it is included in the {{Pkg|libvirt}} package.<br />
* {{Pkg|virt-manager}} is a graphical user interface for managing virtual machines.<br />
* {{Pkg|virtviewer}} is a lightweight interface for interacting with the graphical display of virtualized guest OS.<br />
* {{Pkg|gnome-boxes}} is a simple GNOME 3 application to access remote or virtual systems.<br />
* {{AUR|virt-manager-qt5}}<br />
* {{AUR|libvirt-sandbox}} is an application sandbox toolkit.<br />
<br />
A list of libvirt-compatible software can be found [http://libvirt.org/apps.html here].<br />
<br />
== Configuration ==<br />
<br />
For '''''system'''''-level administration (i.e. global settings and image-''volume'' location), libvirt minimally requires [[#Set up authentication|setting up authorization]], and [[#Daemon|starting the daemon]].<br />
<br />
{{Note|For user-'''''session''''' administration, daemon setup and configuration is ''not'' required; authorization, however, is limited to local abilities; the front-end will launch a local instance of the '''libvirtd''' daemon.}}<br />
<br />
=== Set up authentication ===<br />
<br />
From [http://libvirt.org/auth.html#ACL_server_config libvirt: Connection authentication]:<br />
:The libvirt daemon allows the administrator to choose the authentication mechanisms used for client connections on each network socket independently. This is primarily controlled via the libvirt daemon master config file in {{ic|/etc/libvirt/libvirtd.conf}}. Each of the libvirt sockets can have its authentication mechanism configured independently. There is currently a choice of {{ic|none}}, {{ic|polkit}} and {{ic|sasl}}. <br />
<br />
Because {{Pkg|libvirt}} pulls {{Pkg|polkit}} as a dependency during installation, [[#Using polkit|polkit]] is used as the default value for the {{ic|unix_sock_auth}} parameter ([http://libvirt.org/auth.html#ACL_server_polkit source]). [[#Authenticate with file-based permissions|File-based permissions]] remain nevertheless available.<br />
<br />
==== Using polkit ====<br />
{{Note|A system reboot may be required before authenticating with {{ic|polkit}} works correctly.}}<br />
<br />
The ''libvirt'' daemon provides two [[Polkit#Actions|polkit actions]] in {{ic|/usr/share/polkit-1/actions/org.libvirt.unix.policy}}:<br />
* {{ic|org.libvirt.unix.manage}} for full management access (RW daemon socket), and<br />
* {{ic|org.libvirt.unix.monitor}} for monitoring only access (read-only socket).<br />
<br />
The default policy for the RW daemon socket will require to authenticate as an admin. This is akin to [[sudo]] auth, but does not require that the client application ultimately run as root. Default policy will still allow any application to connect to the RO socket.<br />
<br />
Arch defaults to consider anybody in the {{ic|wheel}} group as an administrator: this is defined in {{ic|/etc/polkit-1/rules.d/50-default.rules}} (see [[Polkit#Administrator identities]]). Therefore there is no need to create a new group and rule file '''if your user is a member of the {{ic|wheel}} group''': upon connection to the RW socket (e.g. via {{Pkg|virt-manager}}) you will be prompted for your user's password.<br />
<br />
{{Note|Prompting for a password relies on the presence of an [[Polkit#Authentication_agents|authentication agent]] on the system. Console users may face an issue with the default {{ic|pkttyagent}} agent which may or may not work properly.}}<br />
<br />
{{Tip|If you want to configure passwordless authentication, see [[Polkit#Bypass password prompt]].}}<br />
<br />
As of libvirt 1.2.16 (commit:[http://libvirt.org/git/?p=libvirt.git;a=commit;h=e94979e901517af9fdde358d7b7c92cc055dd50c]), members of the {{ic|libvirt}} group have passwordless access to the RW daemon socket by default. The easiest way to ensure your user has access is to ensure the libvirt group exists and they are a member of it. If you wish to change the group authorized to access the RW daemon socket to be the kvm group, create the following file:<br />
<br />
{{hc|/etc/polkit-1/rules.d/50-libvirt.rules|<nowiki><br />
/* Allow users in kvm group to manage the libvirt<br />
daemon without authentication */<br />
polkit.addRule(function(action, subject) {<br />
if (action.id == "org.libvirt.unix.manage" &&<br />
subject.isInGroup("kvm")) {<br />
return polkit.Result.YES;<br />
}<br />
});</nowiki><br />
}}<br />
<br />
Then [[Users_and_groups#Other_examples_of_user_management|add yourself]] to the {{ic|kvm}} group and relogin. Replace ''kvm'' with any group of your preference just make sure it exists and that your user is a member of it (see [[Users and groups]] for more information).<br />
<br />
Do not forget to relogin for group changes to take effect.<br />
<br />
==== Authenticate with file-based permissions ====<br />
<br />
To define file-based permissions for users in the ''libvirt'' group to manage virtual machines, uncomment and define:<br />
<br />
{{hc|/etc/libvirt/libvirtd.conf|<nowiki><br />
#unix_sock_group = "libvirt"<br />
#unix_sock_ro_perms = "0777" # set to 0770 to deny non-group libvirt users<br />
#unix_sock_rw_perms = "0770"<br />
#auth_unix_ro = "none"<br />
#auth_unix_rw = "none"<br />
</nowiki>}}<br />
<br />
While some guides mention changed permissions of certain libvirt directories to ease management, keep in mind permissions are lost on package update. To edit these system directories, root user is expected.<br />
<br />
=== Daemon ===<br />
<br />
[[Start]] both {{ic|libvirtd.service}} and {{ic|virtlogd.service}}. Optionally [[enable]] {{ic|libvirtd.service}}. There is no need to enable {{ic|virtlogd.service}}, since {{ic|libvirtd.service}}, when enabled, also enables the {{ic|virtlogd.socket}} and {{ic|virtlockd.socket}} [[Systemd#Using_units|units]].<br />
<br />
=== Unencrypt TCP/IP sockets ===<br />
<br />
{{Warning|This method is used to help remote domain, connection speed for trusted networks. This is the least secure connection method. This should ''only'' be used for testing or use over a secure, private, and trusted network. SASL is not enabled here, so all TCP traffic is ''cleartext''. For real world use ''always'' enable SASL.}}<br />
<br />
Edit {{ic|/etc/libvirt/libvirtd.conf}}:<br />
{{hc|/etc/libvirt/libvirtd.conf|<nowiki><br />
listen_tls = 0<br />
listen_tcp = 1<br />
auth_tcp=none<br />
</nowiki>}}<br />
<br />
It is also necessary to start the server in listening mode by editing {{ic|/etc/conf.d/libvirtd}}:<br />
<br />
{{hc|/etc/conf.d/libvirtd|2=LIBVIRTD_ARGS="--listen"}}<br />
<br />
=== Access virtual machines using their hostnames ===<br />
<br />
For host access to guests on non-isolated, bridged networks, enable the {{ic|libvirt}} NSS module provided by {{Pkg|libvirt}}.<br />
<br />
Edit {{ic|/etc/nsswitch.conf}}:<br />
{{hc|/etc/nsswitch.conf|<nowiki><br />
hosts: files libvirt dns myhostname<br />
</nowiki>}}<br />
<br />
{{Note|While commands such as {{ic|ping}} and {{ic|ssh}} should work with virtual machine hostnames, commands such as {{ic|host}} and {{ic|nslookup}} may fail or produce unexpected results because they rely on DNS. Use {{ic|getent hosts <vm-hostname>}} instead.}}<br />
<br />
== Test ==<br />
<br />
To test if libvirt is working properly on a ''system'' level:<br />
<br />
$ virsh -c qemu:///system<br />
<br />
To test if libvirt is working properly for a user-''session'':<br />
<br />
$ virsh -c qemu:///session<br />
<br />
== Management ==<br />
<br />
Libvirt management is done mostly with three tools: {{Pkg|virt-manager}} (GUI), {{ic|virsh}}, and {{ic|guestfish}} (which is part of {{AUR|libguestfs}}).<br />
<br />
{{Warning|{{Pkg|virt-manager}} requires {{Pkg|libvirt-python3}} which isn't a listed dependency as of writing this note and needs to be installed manually}}<br />
<br />
=== virsh ===<br />
<br />
The virsh program is for managing guest ''domains'' (virtual machines) and works well for scripting, virtualization administration. Though most virsh commands require root privileges to run due to the communication channels used to talk to the hypervisor, typical management, creation, and running of domains (like that done with VirtualBox) can be done as a regular user.<br />
<br />
Virsh includes an interactive terminal that can be entered if no commands are passed (options are allowed though): {{ic|virsh}}. The interactive terminal has support for tab completion.<br />
<br />
From the command line:<br />
<br />
$ virsh [option] <command> [argument]...<br />
<br />
From the interactive terminal:<br />
<br />
virsh # <command> [argument]...<br />
<br />
Help is available:<br />
<br />
$ virsh help [option*] or [group-keyword*]<br />
<br />
=== Storage pools ===<br />
<br />
A pool is a location where storage ''volumes'' can be kept. What libvirt defines as ''volumes'' others may define as "virtual disks" or "virtual machine images". Pool locations may be a directory, a network filesystem, or partition (this includes a [[LVM]]). Pools can be toggled active or inactive and allocated for space.<br />
<br />
On the ''system''-level, {{ic|/var/lib/libvirt/images/}} will be activated by default; on a user-''session'', {{ic|virt-manager}} creates {{ic|$HOME/VirtualMachines}}.<br />
<br />
Print active and inactive storage pools:<br />
<br />
$ virsh pool-list --all<br />
<br />
==== Create a new pool using virsh ====<br />
<br />
If wanted to ''add'' a storage pool, here are examples of the command form, adding a directory, and adding a LVM volume:<br />
<br />
$ virsh pool-define-as name type [source-host] [source-path] [source-dev] [source-name] [<target>] [--source-format format]<br />
$ virsh pool-define-as ''poolname'' dir - - - - /home/''username''/.local/libvirt/images<br />
$ virsh pool-define-as ''poolname'' fs - - ''/dev/vg0/images'' - ''mntpoint''<br />
<br />
The above command defines the information for the pool, to build it:<br />
<br />
$ virsh pool-build ''poolname''<br />
$ virsh pool-start ''poolname''<br />
$ virsh pool-autostart ''poolname''<br />
<br />
To remove it:<br />
<br />
$ virsh pool-undefine ''poolname''<br />
<br />
{{Tip|For LVM storage pools:<br />
* It is a good practice to dedicate a volume group to the storage pool only. <br />
* Choose a LVM volume group that differs from the pool name, otherwise when the storage pool is deleted the LVM group will be too.<br />
}}<br />
<br />
==== Create a new pool using virt-manager ====<br />
<br />
First, connect to a hypervisor (e.g. QEMU/KVM ''system'', or user-''session''). Then, right-click on a connection and select ''Details''; select the ''Storage'' tab, push the ''+'' button on the lower-left, and follow the wizard.<br />
<br />
=== Storage volumes ===<br />
<br />
Once the pool has been created, volumes can be created inside the pool. ''If building a new domain (virtual machine), this step can be skipped as a volume can be created in the domain creation process.''<br />
<br />
==== Create a new volume with virsh ====<br />
<br />
Create volume, list volumes, resize, and delete:<br />
$ virsh vol-create-as ''poolname'' ''volumename'' 10GiB --format aw|bochs|raw|qcow|qcow2|vmdk<br />
$ virsh vol-upload --pool ''poolname'' ''volumename'' ''volumepath''<br />
$ virsh vol-list ''poolname''<br />
$ virsh vol-resize --pool ''poolname'' ''volumename'' 12GiB<br />
$ virsh vol-delete --pool ''poolname'' ''volumename''<br />
$ virsh vol-dumpxml --pool ''poolname'' ''volumename'' # for details.<br />
<br />
==== virt-manager backing store type bug ====<br />
<br />
On newer versions of {{ic|virt-manager}} you can now specify a backing store to use when creating a new disk. This is very useful, in that you can have new domains be based on base images saving you both time and disk space when provisioning new virtual systems. There is a bug (https://bugzilla.redhat.com/show_bug.cgi?id=1235406) in the current version of {{ic|virt-manager}} which causes {{ic|virt-manager}} to choose the wrong type of the backing image in the case where the backing image is a {{ic|qcow2}} type. In this case, it will errantly pick the backing type as {{ic|raw}}. This will cause the new image to be unable to read from the backing store, and effectively remove the utility of having a backing store at all.<br />
<br />
There is a workaround for this issue. {{ic|qemu-img}} has long been able to do this operation directly. If you wish to have a backing store for your new domain before this bug is fixed, you may use the following command.<br />
<br />
$ qemu-img create -f qcow2 -o backing_file=<path to backing image>,backing_fmt=qcow2 <disk name> <disk size><br />
<br />
Then you can use this image as the base for your new domain and it will use the backing store as a COW volume saving you time and disk space.<br />
<br />
=== Domains ===<br />
<br />
Virtual machines are called ''domains''. If working from the command line, use {{ic|virsh}} to list, create, pause, shutdown domains, etc. {{ic|virt-viewer}} can be used to view domains started with {{ic|virsh}}. Creation of domains is typically done either graphically with {{ic|virt-manager}} or with {{ic|virt-install}} (a command line program that is part of the {{pkg|virt-manager}} package).<br />
<br />
{{Warning|{{pkg|virt-manager}} and {{Pkg|virt-install}} require {{Pkg|libvirt-python3}} which isn't a listed dependency as of writing this note and needs to be installed manually}}<br />
<br />
Creating a new domain typically involves using some installation media, such as an {{ic|.iso}} from the storage pool or an optical drive.<br />
<br />
Print active and inactive domains:<br />
<br />
# virsh list --all<br />
<br />
{{note|[[SELinux]] has a built-in exemption for libvirt that allows volumes in {{ic|/var/lib/libvirt/images/}} to be accessed. If using SELinux and there are issues with the volumes, ensure that volumes are in that directory, or ensure that other storage pools are correctly labeled.}}<br />
<br />
==== Create a new domain using virt-install ====<br />
<br />
For an extremely detailed domain (virtual machine) setup, it is easier to [[#Create a new domain using virt-manager]]. However, basics can easily be done with {{ic|virt-install}} and still run quite well. Minimum specifications are {{ic|--name}}, {{ic|--memory}}, guest storage ({{ic|--disk}}, {{ic|--filesystem}}, or {{ic|--nodisks}}), and an install method (generally an {{ic|.iso}} or CD). See {{ic|man virt-install}} for more details and information about unlisted options.<br />
<br />
Arch Linux install (two GiB, qcow2 format volume create; user-networking):<br />
<br />
$ virt-install \<br />
--name arch-linux_testing \<br />
--memory 1024 \ <br />
--vcpus=2,maxvcpus=4 \<br />
--cpu host \<br />
--cdrom $HOME/Downloads/arch-linux_install.iso \<br />
--disk size=2,format=qcow2 \<br />
--network user \<br />
--virt-type kvm<br />
<br />
Fedora testing (Xen hypervisor, non-default pool, do not originally view):<br />
<br />
$ virt-install \<br />
--connect xen:/// \<br />
--name fedora-testing \<br />
--memory 2048 \<br />
--vcpus=2 \<br />
--cpu=host \<br />
--cdrom /tmp/fedora20_x84-64.iso \<br />
--os-type=linux --os-variant=fedora20 \<br />
--disk pool=testing,size=4 \<br />
--network bridge=br0 \<br />
--graphics=vnc \<br />
--noautoconsole<br />
$ virt-viewer --connect xen:/// fedora-testing<br />
<br />
Windows:<br />
<br />
$ virt-install \<br />
--name=windows7 \<br />
--memory 2048 \<br />
--cdrom /dev/sr0 \<br />
--os-variant=win7 \<br />
--disk /mnt/storage/domains/windows7.qcow2,size=20GiB \<br />
--network network=vm-net \<br />
--graphics spice<br />
<br />
{{Tip|Run {{ic|1=osinfo-query --fields=name,short-id,version os}} to get argument for {{ic|--os-variant}}; this will help define some specifications for the domain. However, {{ic|--memory}} and {{ic|--disk}} will need to be entered; one can look within the appropriate {{ic|/usr/share/libosinfo/db/oses/''os''.xml}} if needing these specifications. After installing, it will likely be preferable to install the [http://www.spice-space.org/download.html Spice Guest Tools] that include the [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization_Host_Configuration_and_Guest_Installation_Guide/form-Virtualization_Host_Configuration_and_Guest_Installation_Guide-Para_virtualized_drivers-Mounting_the_image_with_virt_manager.html VirtIO drivers]. For a Windows VirtIO network driver there is also {{Aur|virtio-win}}. These drivers are referenced by a {{ic|1=<model type='virtio' />}} in the guest's {{ic|.xml}} configuration section for the device. A bit more information can also be found on the [[QEMU#Preparing_a_Windows_guest|QEMU article]].}}<br />
<br />
Import existing volume:<br />
<br />
$ virt-install \<br />
--name demo \<br />
--memory 512 \<br />
--disk /home/user/VMs/mydisk.img \<br />
--import<br />
<br />
==== Create a new domain using virt-manager ====<br />
<br />
First, connect to the hypervisor (e.g. QEMU/KVM ''system'' or user ''session''), right click on a connection and select ''New'', and follow the wizard.<br />
<br />
* On the ''fourth step'', de-selecting ''Allocate entire disk now'' will make setup quicker and can save disk space in the interum; ''however'', it may cause volume fragmentation over time.<br />
* On the ''fifth step'', open ''Advanced options'' and make sure that ''Virt Type'' is set to ''kvm'' (this is usually the preferred method). If additional hardware setup is required, select the ''Customize configuration before install'' option.<br />
<br />
==== Manage a domain ====<br />
<br />
Start a domain:<br />
<br />
$ virsh start ''domain''<br />
$ virt-viewer --connect qemu:///session ''domain''<br />
<br />
Gracefully attempt to shutdown a domain; force off a domain:<br />
<br />
$ virsh shutdown ''domain''<br />
$ virsh destroy ''domain''<br />
<br />
Autostart domain on libvirtd start:<br />
<br />
$ virsh autostart ''domain''<br />
$ virsh autostart ''domain'' --disable<br />
<br />
Shutdown domain on host shutdown:<br />
<br />
: Running domains can be automatically suspended/shutdown at host shutdown using the {{ic|libvirt-guests.service}} systemd service. This same service will resume/startup the suspended/shutdown domain automatically at host startup. Read {{ic|/etc/conf.d/libvirt-guests}} for service options.<br />
<br />
Edit a domain's XML configuration:<br />
<br />
$ virsh edit ''domain''<br />
<br />
{{note|Virtual Machines started directly by QEMU are not managable by libvirt tools.}}<br />
<br />
=== Networks ===<br />
<br />
A [https://jamielinux.com/docs/libvirt-networking-handbook/ decent overview of libvirt networking].<br />
<br />
By default, when the {{ic|libvirtd}} systemd service is started, a NAT bridge is created called ''default'' to allow external network connectivity (warning see: [[#"default" network bug]]{{Broken section link}}). For other network connectivity needs, four network types exist that can be created to connect a domain to:<br />
<br />
* bridge — a virtual device; shares data directly with a physical interface. Use this if the host has ''static'' networking, it does not need to connect other domains, the domain requires full inbound and outbound trafficking, and the domain is running on a ''system''-level. See [[Network bridge]] on how to add a bridge additional to the default one. After creation, it needs to be specified in the respective guest's {{ic|.xml}} configuration file. <br />
* network — a virtual network; has ability to share with other domains. Use a virtual network if the host has ''dynamic'' networking (e.g. NetworkManager), or using wireless.<br />
* macvtap — connect directly to a host physical interface.<br />
* user — local ability networking. Use this only for a user ''session''.<br />
<br />
{{ic|virsh}} has the ability to create networking with numerous options for most users, however, it is easier to create network connectivity with a graphic user interface (like {{ic|virt-manager}}), or to do so on [[#Create a new domain using virt-install|creation with virt-install]].<br />
<br />
{{note|libvirt handles DHCP and DNS with {{pkg|dnsmasq}}, launching a separate instance for every virtual network. It also adds iptables rules for proper routing, and enables the {{ic|ip_forward}} kernel parameter. This also means that having dnsmasq running on the host system is not necessary to support libvirt requirements (and could interfere with libvirt dnsmasq instances).}}<br />
<br />
=== Snapshots ===<br />
<br />
Snapshots take the disk, memory, and device state of a domain at a point-of-time, and save it for future use. They have many uses, from saving a "clean" copy of an OS image to saving a domain's state before a potentially destructive operation. Snapshots are identified with a unique name.<br />
<br />
Snapshots are saved within the volume itself and the volume must be the format: qcow2 or raw. Snapshots use deltas so they have the potentiality to not take much space.<br />
<br />
==== Create a snapshot ====<br />
<br />
{{Out of date|Some of this data appears to be dated.}}<br />
<br />
Once a snapshot is taken it is saved as a new block device and the original snapshot is taken offline. Snapshots can be chosen from and also merged into another (even without shutting down the domain).<br />
<br />
Print a running domain's volumes (running domains can be printed with {{ic|virsh list}}):<br />
<br />
{{hc|# virsh domblklist ''domain''|<nowiki><br />
Target Source<br />
------------------------------------------------<br />
vda /vms/domain.img<br />
</nowiki>}}<br />
<br />
To see a volume's physical properties:<br />
<br />
{{hc|# qemu-img info /vms/domain.img|<nowiki><br />
image: /vms/domain.img<br />
file format: qcow2<br />
virtual size: 50G (53687091200 bytes)<br />
disk size: 2.1G<br />
cluster_size: 65536<br />
</nowiki>}}<br />
<br />
Create a disk-only snapshot (the option {{ic|--atomic}} will prevent the volume from being modified if snapshot creation fails):<br />
<br />
# virsh snapshot-create-as ''domain'' snapshot1 --disk-only --atomic<br />
<br />
List snapshots:<br />
<br />
{{hc|# virsh snapshot-list ''domain''|<nowiki><br />
Name Creation Time State<br />
------------------------------------------------------------<br />
snapshot1 2012-10-21 17:12:57 -0700 disk-snapshot<br />
</nowiki>}}<br />
<br />
One can they copy the original image with {{ic|1=cp --sparse=true}} or {{ic|rsync -S}} and then merge the the original back into snapshot:<br />
<br />
# virsh blockpull --domain ''domain'' --path /vms/''domain''.snapshot1<br />
<br />
{{ic|domain.snapshot1}} becomes a new volume. After this is done the original volume ({{ic|domain.img}} and snapshot metadata can be deleted. The {{ic|virsh blockcommit}} would work opposite to {{ic|blockpull}} but it seems to be currently under development (including {{ic|snapshot-revert feature}}, scheduled to be released sometime next year.<br />
<br />
=== Other management ===<br />
<br />
Connect to non-default hypervisor:<br />
<br />
$ virsh --connect xen:///<br />
virsh # uri<br />
xen:///<br />
<br />
Connect to the QEMU hypervisor over SSH; and the same with logging:<br />
<br />
$ virsh --connect qemu+ssh://''username''@''host''/system<br />
$ LIBVIRT_DEBUG=1 virsh --connect qemu+ssh://''username''@''host''/system<br />
<br />
Connect a graphic console over SSH:<br />
<br />
$ virt-viewer --connect qemu+ssh://''username''@''host''/system ''domain''<br />
$ virt-manager --connect qemu+ssh://''username''@''host''/system ''domain''<br />
<br />
{{Note|If you are having problems connecting to a remote RHEL server (or anything other than Arch, really), try the two workarounds mentioned in {{bug|30748}} and {{bug|22068}}.}}<br />
<br />
Connect to the VirtualBox hypervisor (''VirtualBox support in libvirt is not stable yet and may cause libvirtd to crash''):<br />
<br />
$ virsh --connect vbox:///system<br />
<br />
Network configurations:<br />
<br />
$ virsh -c qemu:///system net-list --all<br />
$ virsh -c qemu:///system net-dumpxml default<br />
<br />
== Python connectivity code ==<br />
<br />
The {{Pkg|libvirt-python}} package provides a {{Pkg|python2}} API in {{ic|/usr/lib/python2.7/site-packages/libvirt.py}}.<br />
<br />
General examples are given in {{ic|/usr/share/doc/libvirt-python-''your_libvirt_version''/examples/}}<br />
<br />
Unofficial example using {{Pkg|qemu}} and {{Pkg|openssh}}:<br />
<br />
#! /usr/bin/env python2<br />
# -*- coding: utf-8 -*-<br />
import socket<br />
import sys<br />
import libvirt<br />
if (__name__ == "__main__"):<br />
<nowiki>conn = libvirt.open("qemu+ssh://xxx/system")</nowiki><br />
print "Trying to find node on xxx"<br />
domains = conn.listDomainsID()<br />
for domainID in domains:<br />
domConnect = conn.lookupByID(domainID)<br />
if domConnect.name() == 'xxx-node':<br />
print "Found shared node on xxx with ID " + str(domainID)<br />
domServ = domConnect<br />
break<br />
<br />
== UEFI Support ==<br />
<br />
Libvirt can suport UEFI virtual machines through QEMU and [https://github.com/tianocore/edk2 OVMF].<br />
<br />
Currently this is possible in Arch Linux through a workaround. [https://bugs.archlinux.org/index.php?do=details&action=details.addvote&task_id=47101 This ovmf packaging bug] needs to be resolved for this to work out of the box or with minimal configuration of {{ic|/etc/libvirt/qemu.conf}}.<br />
<br />
=== OVMF - QEMU workaround ===<br />
<br />
* Build {{Pkg|ovmf}} from the [[ABS]] with {{ic|makepkg}}.<br />
* Copy the {{ic|OVMF_CODE.fd}} and {{ic|OVMF_VARS.fd}} files either for 64 or 32 bit to the default qemu location.<br />
<br />
{{hc|/etc/libvirt/qemu.conf|<nowiki><br />
#nvram = [<br />
# "/usr/share/OVMF/OVMF_CODE.fd:/usr/share/OVMF/OVMF_VARS.fd",<br />
# "/usr/share/OVMF/OVMF_CODE.secboot.fd:/usr/share/OVMF/OVMF_VARS.fd",<br />
# "/usr/share/AAVMF/AAVMF_CODE.fd:/usr/share/AAVMF/AAVMF_VARS.fd"<br />
#]<br />
</nowiki><br />
}}<br />
<br />
# mkdir /usr/share/OVMF<br />
# cp src/edk2/Build/OvmfX64/RELEASE_GCC49/FV/OVMF_CODE.fd src/edk2/Build/OvmfX64/RELEASE_GCC49/FV/OVMF_VARS.fd /usr/share/OVMF/ <br />
<br />
* Restart {{ic|libvirtd}}<br />
<br />
# systemctl stop libvirtd<br />
# systemctl start libvirtd<br />
<br />
Now you are ready to create a uefi virtual machine. Create a new virtual machine through {{Pkg|virt-manager}}. When you get to the final page of the 'New VM' wizard, do the following: <br />
<br />
* Click 'Customize before install', then select 'Finish'<br />
* On the 'Overview' screen, Change the 'Firmware' field to select the 'UEFI x86_64' option.<br />
* Click 'Begin Installation'<br />
* The boot screen you'll see should use linuxefi commands to boot the installer, and you should be able to run efibootmgr inside that system, to verify that you're running an UEFI OS. <br />
<br />
For more information about this, refer to [https://fedoraproject.org/wiki/Using_UEFI_with_QEMU this fedora wiki page].<br />
<br />
== PulseAudio ==<br />
<br />
The PulseAudio daemon normally runs under your regular user account, and will only accept connections from the same user. This can be a problem if QEMU is being run as root through [[libvirt]]. To run QEMU as a regular user, edit {{ic|/etc/libvirt/qemu.conf}} and set the {{ic|user}} option to your username.<br />
<br />
user = "dave"<br />
<br />
You will also need to tell QEMU to use the PulseAudio backend and identify the server to connect to. Add the following section to your domain configuration using {{ic|virsh edit}}.<br />
<br />
<qemu:commandline><br />
<qemu:env name='QEMU_AUDIO_DRV' value='pa'/><br />
<qemu:env name='QEMU_PA_SERVER' value='/run/user/1000/pulse/native'/><br />
</qemu:commandline><br />
<br />
{{ic|1000}} is your user id. Change it if necessary.<br />
<br />
== See also ==<br />
<br />
* [http://libvirt.org/drvqemu.html Official libvirt web site]<br />
* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Virtualization_Deployment_and_Administration_Guide/index.html Red Hat Virtualization Deployment and Administration Guide]<br />
* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Virtualization_Tuning_and_Optimization_Guide/index.html Red Hat Virtualization Tuning and Optimization Guide]<br />
* [http://docs.slackware.com/howtos:general_admin:kvm_libvirt Slackware KVM and libvirt]<br />
* [http://www-01.ibm.com/support/knowledgecenter/linuxonibm/liaat/liaatkvm.htm IBM KVM]<br />
* [https://jamielinux.com/docs/libvirt-networking-handbook/ libvirt Networking Handbook]</div>Kgizdovhttps://wiki.archlinux.org/index.php?title=Libvirt&diff=452984Libvirt2016-10-05T18:34:03Z<p>Kgizdov: /* Management */ add warning for missing dependency</p>
<hr />
<div>{{DISPLAYTITLE:libvirt}}<br />
[[Category:Virtualization]]<br />
[[ja:libvirt]]<br />
[[zh-CN:Libvirt]]<br />
[[zh-TW:Libvirt]]<br />
{{Related articles start}}<br />
{{Related|:Category:Hypervisors}}<br />
{{Related|:PCI passthrough via OVMF}}<br />
{{Related articles end}}<br />
<br />
Libvirt is collection of software that provides a convenient way to manage virtual machines and other virtualization functionality, such as storage and network interface management. These software pieces include a long term stable C API, a daemon (libvirtd), and a command line utility (virsh). A primary goal of libvirt is to provide a single way to manage multiple different virtualization providers/hypervisors, such as the [[QEMU|KVM/QEMU]], [[Xen]], [[LXC]], [http://openvz.org OpenVZ] or [[VirtualBox]] [[:Category:Hypervisors|hypervisors]] ([http://libvirt.org/drivers.html among others]).<br />
<br />
Some of the major libvirt features are:<br />
*'''VM management''': Various domain lifecycle operations such as start, stop, pause, save, restore, and migrate. Hotplug operations for many device types including disk and network interfaces, memory, and cpus.<br />
*'''Remote machine support''': All libvirt functionality is accessible on any machine running the libvirt daemon, including remote machines. A variety of network transports are supported for connecting remotely, with the simplest being SSH, which requires no extra explicit configuration.<br />
*'''Storage management''': Any host running the libvirt daemon can be used to manage various types of storage: create file images of various formats (qcow2, vmdk, raw, ...), mount NFS shares, enumerate existing LVM volume groups, create new LVM volume groups and logical volumes, partition raw disk devices, mount iSCSI shares, and much more.<br />
*'''Network interface management''': Any host running the libvirt daemon can be used to manage physical and logical network interfaces. Enumerate existing interfaces, as well as configure (and create) interfaces, bridges, vlans, and bond devices.<br />
*'''Virtual NAT and Route based networking''': Any host running the libvirt daemon can manage and create virtual networks. Libvirt virtual networks use firewall rules to act as a router, providing VMs transparent access to the host machines network.<br />
<br />
== Installation ==<br />
<br />
Because of its daemon/client architecture, libvirt needs only be installed on the machine which will host the virtualized system. Note that the server and client can be the same physical machine.<br />
<br />
=== Server ===<br />
<br />
[[Install]] the {{pkg|libvirt}} package, as well as at least one hypervisor:<br />
<br />
* The [http://libvirt.org/drvqemu.html libvirt KVM/QEMU driver] is the primary ''libvirt'' driver and if [[QEMU#Enabling_KVM|KVM is enabled]], fully virtualized, hardware accelerated guests will be available. See the [[QEMU]] article for more informations.<br />
<br />
* Other [http://libvirt.org/drivers.html supported hypervisors] include [[LXC]], [[VirtualBox]] and [[Xen]]. See the respective articles for installation instructions. With respect to {{ic|libvirtd}} installation note: <br />
** The [http://libvirt.org/drvlxc.html libvirt LXC driver] has no dependency on the [[LXC]] userspace tools provided by {{Pkg|lxc}}, therefore there is no need to install the package if planning on using the driver.<br />
** [[Xen]] support is available, but not by default. You need to use the [[ABS]] to modify {{Pkg|libvirt}}'s [[PKGBUILD]] and build it without the {{ic|--without-xen}} option. As VirtualBox in turn has no planned stable support for Xen, you might as well replace it with {{ic|--without-vbox}}.<br />
<br />
For network connectivity, install: <br />
<br />
* {{Pkg|ebtables}} '''and''' {{Pkg|dnsmasq}} for the [http://wiki.libvirt.org/page/VirtualNetworking#The_default_configuration default] NAT/DHCP networking.<br />
* {{Pkg|bridge-utils}} for bridged networking.<br />
* {{Pkg|openbsd-netcat}} for remote management over [[SSH]].<br />
<br />
=== Client ===<br />
<br />
The client is the user interface that will be used to manage and access the virtual machines.<br />
<br />
* ''virsh'' is a command line program for managing and configuring domains; it is included in the {{Pkg|libvirt}} package.<br />
* {{Pkg|virt-manager}} is a graphical user interface for managing virtual machines.<br />
* {{Pkg|virtviewer}} is a lightweight interface for interacting with the graphical display of virtualized guest OS.<br />
* {{Pkg|gnome-boxes}} is a simple GNOME 3 application to access remote or virtual systems.<br />
* {{AUR|virt-manager-qt5}}<br />
* {{AUR|libvirt-sandbox}} is an application sandbox toolkit.<br />
<br />
A list of libvirt-compatible software can be found [http://libvirt.org/apps.html here].<br />
<br />
== Configuration ==<br />
<br />
For '''''system'''''-level administration (i.e. global settings and image-''volume'' location), libvirt minimally requires [[#Set up authentication|setting up authorization]], and [[#Daemon|starting the daemon]].<br />
<br />
{{Note|For user-'''''session''''' administration, daemon setup and configuration is ''not'' required; authorization, however, is limited to local abilities; the front-end will launch a local instance of the '''libvirtd''' daemon.}}<br />
<br />
=== Set up authentication ===<br />
<br />
From [http://libvirt.org/auth.html#ACL_server_config libvirt: Connection authentication]:<br />
:The libvirt daemon allows the administrator to choose the authentication mechanisms used for client connections on each network socket independently. This is primarily controlled via the libvirt daemon master config file in {{ic|/etc/libvirt/libvirtd.conf}}. Each of the libvirt sockets can have its authentication mechanism configured independently. There is currently a choice of {{ic|none}}, {{ic|polkit}} and {{ic|sasl}}. <br />
<br />
Because {{Pkg|libvirt}} pulls {{Pkg|polkit}} as a dependency during installation, [[#Using polkit|polkit]] is used as the default value for the {{ic|unix_sock_auth}} parameter ([http://libvirt.org/auth.html#ACL_server_polkit source]). [[#Authenticate with file-based permissions|File-based permissions]] remain nevertheless available.<br />
<br />
==== Using polkit ====<br />
{{Note|A system reboot may be required before authenticating with {{ic|polkit}} works correctly.}}<br />
<br />
The ''libvirt'' daemon provides two [[Polkit#Actions|polkit actions]] in {{ic|/usr/share/polkit-1/actions/org.libvirt.unix.policy}}:<br />
* {{ic|org.libvirt.unix.manage}} for full management access (RW daemon socket), and<br />
* {{ic|org.libvirt.unix.monitor}} for monitoring only access (read-only socket).<br />
<br />
The default policy for the RW daemon socket will require to authenticate as an admin. This is akin to [[sudo]] auth, but does not require that the client application ultimately run as root. Default policy will still allow any application to connect to the RO socket.<br />
<br />
Arch defaults to consider anybody in the {{ic|wheel}} group as an administrator: this is defined in {{ic|/etc/polkit-1/rules.d/50-default.rules}} (see [[Polkit#Administrator identities]]). Therefore there is no need to create a new group and rule file '''if your user is a member of the {{ic|wheel}} group''': upon connection to the RW socket (e.g. via {{Pkg|virt-manager}}) you will be prompted for your user's password.<br />
<br />
{{Note|Prompting for a password relies on the presence of an [[Polkit#Authentication_agents|authentication agent]] on the system. Console users may face an issue with the default {{ic|pkttyagent}} agent which may or may not work properly.}}<br />
<br />
{{Tip|If you want to configure passwordless authentication, see [[Polkit#Bypass password prompt]].}}<br />
<br />
As of libvirt 1.2.16 (commit:[http://libvirt.org/git/?p=libvirt.git;a=commit;h=e94979e901517af9fdde358d7b7c92cc055dd50c]), members of the {{ic|libvirt}} group have passwordless access to the RW daemon socket by default. The easiest way to ensure your user has access is to ensure the libvirt group exists and they are a member of it. If you wish to change the group authorized to access the RW daemon socket to be the kvm group, create the following file:<br />
<br />
{{hc|/etc/polkit-1/rules.d/50-libvirt.rules|<nowiki><br />
/* Allow users in kvm group to manage the libvirt<br />
daemon without authentication */<br />
polkit.addRule(function(action, subject) {<br />
if (action.id == "org.libvirt.unix.manage" &&<br />
subject.isInGroup("kvm")) {<br />
return polkit.Result.YES;<br />
}<br />
});</nowiki><br />
}}<br />
<br />
Then [[Users_and_groups#Other_examples_of_user_management|add yourself]] to the {{ic|kvm}} group and relogin. Replace ''kvm'' with any group of your preference just make sure it exists and that your user is a member of it (see [[Users and groups]] for more information).<br />
<br />
Do not forget to relogin for group changes to take effect.<br />
<br />
==== Authenticate with file-based permissions ====<br />
<br />
To define file-based permissions for users in the ''libvirt'' group to manage virtual machines, uncomment and define:<br />
<br />
{{hc|/etc/libvirt/libvirtd.conf|<nowiki><br />
#unix_sock_group = "libvirt"<br />
#unix_sock_ro_perms = "0777" # set to 0770 to deny non-group libvirt users<br />
#unix_sock_rw_perms = "0770"<br />
#auth_unix_ro = "none"<br />
#auth_unix_rw = "none"<br />
</nowiki>}}<br />
<br />
While some guides mention changed permissions of certain libvirt directories to ease management, keep in mind permissions are lost on package update. To edit these system directories, root user is expected.<br />
<br />
=== Daemon ===<br />
<br />
[[Start]] both {{ic|libvirtd.service}} and {{ic|virtlogd.service}}. Optionally [[enable]] {{ic|libvirtd.service}}. There is no need to enable {{ic|virtlogd.service}}, since {{ic|libvirtd.service}}, when enabled, also enables the {{ic|virtlogd.socket}} and {{ic|virtlockd.socket}} [[Systemd#Using_units|units]].<br />
<br />
=== Unencrypt TCP/IP sockets ===<br />
<br />
{{Warning|This method is used to help remote domain, connection speed for trusted networks. This is the least secure connection method. This should ''only'' be used for testing or use over a secure, private, and trusted network. SASL is not enabled here, so all TCP traffic is ''cleartext''. For real world use ''always'' enable SASL.}}<br />
<br />
Edit {{ic|/etc/libvirt/libvirtd.conf}}:<br />
{{hc|/etc/libvirt/libvirtd.conf|<nowiki><br />
listen_tls = 0<br />
listen_tcp = 1<br />
auth_tcp=none<br />
</nowiki>}}<br />
<br />
It is also necessary to start the server in listening mode by editing {{ic|/etc/conf.d/libvirtd}}:<br />
<br />
{{hc|/etc/conf.d/libvirtd|2=LIBVIRTD_ARGS="--listen"}}<br />
<br />
=== Access virtual machines using their hostnames ===<br />
<br />
For host access to guests on non-isolated, bridged networks, enable the {{ic|libvirt}} NSS module provided by {{Pkg|libvirt}}.<br />
<br />
Edit {{ic|/etc/nsswitch.conf}}:<br />
{{hc|/etc/nsswitch.conf|<nowiki><br />
hosts: files libvirt dns myhostname<br />
</nowiki>}}<br />
<br />
{{Note|While commands such as {{ic|ping}} and {{ic|ssh}} should work with virtual machine hostnames, commands such as {{ic|host}} and {{ic|nslookup}} may fail or produce unexpected results because they rely on DNS. Use {{ic|getent hosts <vm-hostname>}} instead.}}<br />
<br />
== Test ==<br />
<br />
To test if libvirt is working properly on a ''system'' level:<br />
<br />
$ virsh -c qemu:///system<br />
<br />
To test if libvirt is working properly for a user-''session'':<br />
<br />
$ virsh -c qemu:///session<br />
<br />
== Management ==<br />
<br />
Libvirt management is done mostly with three tools: {{Pkg|virt-manager}} (GUI), {{ic|virsh}}, and {{ic|guestfish}} (which is part of {{AUR|libguestfs}}).<br />
<br />
{{Warning|{{Pkg|virt-manager}} requires {{Pkg|libvirt-python3}} which isn't a listed dependency as of writing this note and needs to be installed manually}}<br />
<br />
=== virsh ===<br />
<br />
The virsh program is for managing guest ''domains'' (virtual machines) and works well for scripting, virtualization administration. Though most virsh commands require root privileges to run due to the communication channels used to talk to the hypervisor, typical management, creation, and running of domains (like that done with VirtualBox) can be done as a regular user.<br />
<br />
Virsh includes an interactive terminal that can be entered if no commands are passed (options are allowed though): {{ic|virsh}}. The interactive terminal has support for tab completion.<br />
<br />
From the command line:<br />
<br />
$ virsh [option] <command> [argument]...<br />
<br />
From the interactive terminal:<br />
<br />
virsh # <command> [argument]...<br />
<br />
Help is available:<br />
<br />
$ virsh help [option*] or [group-keyword*]<br />
<br />
=== Storage pools ===<br />
<br />
A pool is a location where storage ''volumes'' can be kept. What libvirt defines as ''volumes'' others may define as "virtual disks" or "virtual machine images". Pool locations may be a directory, a network filesystem, or partition (this includes a [[LVM]]). Pools can be toggled active or inactive and allocated for space.<br />
<br />
On the ''system''-level, {{ic|/var/lib/libvirt/images/}} will be activated by default; on a user-''session'', {{ic|virt-manager}} creates {{ic|$HOME/VirtualMachines}}.<br />
<br />
Print active and inactive storage pools:<br />
<br />
$ virsh pool-list --all<br />
<br />
==== Create a new pool using virsh ====<br />
<br />
If wanted to ''add'' a storage pool, here are examples of the command form, adding a directory, and adding a LVM volume:<br />
<br />
$ virsh pool-define-as name type [source-host] [source-path] [source-dev] [source-name] [<target>] [--source-format format]<br />
$ virsh pool-define-as ''poolname'' dir - - - - /home/''username''/.local/libvirt/images<br />
$ virsh pool-define-as ''poolname'' fs - - ''/dev/vg0/images'' - ''mntpoint''<br />
<br />
The above command defines the information for the pool, to build it:<br />
<br />
$ virsh pool-build ''poolname''<br />
$ virsh pool-start ''poolname''<br />
$ virsh pool-autostart ''poolname''<br />
<br />
To remove it:<br />
<br />
$ virsh pool-undefine ''poolname''<br />
<br />
{{Tip|For LVM storage pools:<br />
* It is a good practice to dedicate a volume group to the storage pool only. <br />
* Choose a LVM volume group that differs from the pool name, otherwise when the storage pool is deleted the LVM group will be too.<br />
}}<br />
<br />
==== Create a new pool using virt-manager ====<br />
<br />
First, connect to a hypervisor (e.g. QEMU/KVM ''system'', or user-''session''). Then, right-click on a connection and select ''Details''; select the ''Storage'' tab, push the ''+'' button on the lower-left, and follow the wizard.<br />
<br />
=== Storage volumes ===<br />
<br />
Once the pool has been created, volumes can be created inside the pool. ''If building a new domain (virtual machine), this step can be skipped as a volume can be created in the domain creation process.''<br />
<br />
==== Create a new volume with virsh ====<br />
<br />
Create volume, list volumes, resize, and delete:<br />
$ virsh vol-create-as ''poolname'' ''volumename'' 10GiB --format aw|bochs|raw|qcow|qcow2|vmdk<br />
$ virsh vol-upload --pool ''poolname'' ''volumename'' ''volumepath''<br />
$ virsh vol-list ''poolname''<br />
$ virsh vol-resize --pool ''poolname'' ''volumename'' 12GiB<br />
$ virsh vol-delete --pool ''poolname'' ''volumename''<br />
$ virsh vol-dumpxml --pool ''poolname'' ''volumename'' # for details.<br />
<br />
==== virt-manager backing store type bug ====<br />
<br />
On newer versions of {{ic|virt-manager}} you can now specify a backing store to use when creating a new disk. This is very useful, in that you can have new domains be based on base images saving you both time and disk space when provisioning new virtual systems. There is a bug (https://bugzilla.redhat.com/show_bug.cgi?id=1235406) in the current version of {{ic|virt-manager}} which causes {{ic|virt-manager}} to choose the wrong type of the backing image in the case where the backing image is a {{ic|qcow2}} type. In this case, it will errantly pick the backing type as {{ic|raw}}. This will cause the new image to be unable to read from the backing store, and effectively remove the utility of having a backing store at all.<br />
<br />
There is a workaround for this issue. {{ic|qemu-img}} has long been able to do this operation directly. If you wish to have a backing store for your new domain before this bug is fixed, you may use the following command.<br />
<br />
$ qemu-img create -f qcow2 -o backing_file=<path to backing image>,backing_fmt=qcow2 <disk name> <disk size><br />
<br />
Then you can use this image as the base for your new domain and it will use the backing store as a COW volume saving you time and disk space.<br />
<br />
=== Domains ===<br />
<br />
Virtual machines are called ''domains''. If working from the command line, use {{ic|virsh}} to list, create, pause, shutdown domains, etc. {{ic|virt-viewer}} can be used to view domains started with {{ic|virsh}}. Creation of domains is typically done either graphically with {{ic|virt-manager}} or with {{ic|virt-install}} (a command line program that is part of the {{pkg|virt-manager}} package).<br />
<br />
Creating a new domain typically involves using some installation media, such as an {{ic|.iso}} from the storage pool or an optical drive.<br />
<br />
Print active and inactive domains:<br />
<br />
# virsh list --all<br />
<br />
{{note|[[SELinux]] has a built-in exemption for libvirt that allows volumes in {{ic|/var/lib/libvirt/images/}} to be accessed. If using SELinux and there are issues with the volumes, ensure that volumes are in that directory, or ensure that other storage pools are correctly labeled.}}<br />
<br />
==== Create a new domain using virt-install ====<br />
<br />
For an extremely detailed domain (virtual machine) setup, it is easier to [[#Create a new domain using virt-manager]]. However, basics can easily be done with {{ic|virt-install}} and still run quite well. Minimum specifications are {{ic|--name}}, {{ic|--memory}}, guest storage ({{ic|--disk}}, {{ic|--filesystem}}, or {{ic|--nodisks}}), and an install method (generally an {{ic|.iso}} or CD). See {{ic|man virt-install}} for more details and information about unlisted options.<br />
<br />
Arch Linux install (two GiB, qcow2 format volume create; user-networking):<br />
<br />
$ virt-install \<br />
--name arch-linux_testing \<br />
--memory 1024 \ <br />
--vcpus=2,maxvcpus=4 \<br />
--cpu host \<br />
--cdrom $HOME/Downloads/arch-linux_install.iso \<br />
--disk size=2,format=qcow2 \<br />
--network user \<br />
--virt-type kvm<br />
<br />
Fedora testing (Xen hypervisor, non-default pool, do not originally view):<br />
<br />
$ virt-install \<br />
--connect xen:/// \<br />
--name fedora-testing \<br />
--memory 2048 \<br />
--vcpus=2 \<br />
--cpu=host \<br />
--cdrom /tmp/fedora20_x84-64.iso \<br />
--os-type=linux --os-variant=fedora20 \<br />
--disk pool=testing,size=4 \<br />
--network bridge=br0 \<br />
--graphics=vnc \<br />
--noautoconsole<br />
$ virt-viewer --connect xen:/// fedora-testing<br />
<br />
Windows:<br />
<br />
$ virt-install \<br />
--name=windows7 \<br />
--memory 2048 \<br />
--cdrom /dev/sr0 \<br />
--os-variant=win7 \<br />
--disk /mnt/storage/domains/windows7.qcow2,size=20GiB \<br />
--network network=vm-net \<br />
--graphics spice<br />
<br />
{{Tip|Run {{ic|1=osinfo-query --fields=name,short-id,version os}} to get argument for {{ic|--os-variant}}; this will help define some specifications for the domain. However, {{ic|--memory}} and {{ic|--disk}} will need to be entered; one can look within the appropriate {{ic|/usr/share/libosinfo/db/oses/''os''.xml}} if needing these specifications. After installing, it will likely be preferable to install the [http://www.spice-space.org/download.html Spice Guest Tools] that include the [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization_Host_Configuration_and_Guest_Installation_Guide/form-Virtualization_Host_Configuration_and_Guest_Installation_Guide-Para_virtualized_drivers-Mounting_the_image_with_virt_manager.html VirtIO drivers]. For a Windows VirtIO network driver there is also {{Aur|virtio-win}}. These drivers are referenced by a {{ic|1=<model type='virtio' />}} in the guest's {{ic|.xml}} configuration section for the device. A bit more information can also be found on the [[QEMU#Preparing_a_Windows_guest|QEMU article]].}}<br />
<br />
Import existing volume:<br />
<br />
$ virt-install \<br />
--name demo \<br />
--memory 512 \<br />
--disk /home/user/VMs/mydisk.img \<br />
--import<br />
<br />
==== Create a new domain using virt-manager ====<br />
<br />
First, connect to the hypervisor (e.g. QEMU/KVM ''system'' or user ''session''), right click on a connection and select ''New'', and follow the wizard.<br />
<br />
* On the ''fourth step'', de-selecting ''Allocate entire disk now'' will make setup quicker and can save disk space in the interum; ''however'', it may cause volume fragmentation over time.<br />
* On the ''fifth step'', open ''Advanced options'' and make sure that ''Virt Type'' is set to ''kvm'' (this is usually the preferred method). If additional hardware setup is required, select the ''Customize configuration before install'' option.<br />
<br />
==== Manage a domain ====<br />
<br />
Start a domain:<br />
<br />
$ virsh start ''domain''<br />
$ virt-viewer --connect qemu:///session ''domain''<br />
<br />
Gracefully attempt to shutdown a domain; force off a domain:<br />
<br />
$ virsh shutdown ''domain''<br />
$ virsh destroy ''domain''<br />
<br />
Autostart domain on libvirtd start:<br />
<br />
$ virsh autostart ''domain''<br />
$ virsh autostart ''domain'' --disable<br />
<br />
Shutdown domain on host shutdown:<br />
<br />
: Running domains can be automatically suspended/shutdown at host shutdown using the {{ic|libvirt-guests.service}} systemd service. This same service will resume/startup the suspended/shutdown domain automatically at host startup. Read {{ic|/etc/conf.d/libvirt-guests}} for service options.<br />
<br />
Edit a domain's XML configuration:<br />
<br />
$ virsh edit ''domain''<br />
<br />
{{note|Virtual Machines started directly by QEMU are not managable by libvirt tools.}}<br />
<br />
=== Networks ===<br />
<br />
A [https://jamielinux.com/docs/libvirt-networking-handbook/ decent overview of libvirt networking].<br />
<br />
By default, when the {{ic|libvirtd}} systemd service is started, a NAT bridge is created called ''default'' to allow external network connectivity (warning see: [[#"default" network bug]]{{Broken section link}}). For other network connectivity needs, four network types exist that can be created to connect a domain to:<br />
<br />
* bridge — a virtual device; shares data directly with a physical interface. Use this if the host has ''static'' networking, it does not need to connect other domains, the domain requires full inbound and outbound trafficking, and the domain is running on a ''system''-level. See [[Network bridge]] on how to add a bridge additional to the default one. After creation, it needs to be specified in the respective guest's {{ic|.xml}} configuration file. <br />
* network — a virtual network; has ability to share with other domains. Use a virtual network if the host has ''dynamic'' networking (e.g. NetworkManager), or using wireless.<br />
* macvtap — connect directly to a host physical interface.<br />
* user — local ability networking. Use this only for a user ''session''.<br />
<br />
{{ic|virsh}} has the ability to create networking with numerous options for most users, however, it is easier to create network connectivity with a graphic user interface (like {{ic|virt-manager}}), or to do so on [[#Create a new domain using virt-install|creation with virt-install]].<br />
<br />
{{note|libvirt handles DHCP and DNS with {{pkg|dnsmasq}}, launching a separate instance for every virtual network. It also adds iptables rules for proper routing, and enables the {{ic|ip_forward}} kernel parameter. This also means that having dnsmasq running on the host system is not necessary to support libvirt requirements (and could interfere with libvirt dnsmasq instances).}}<br />
<br />
=== Snapshots ===<br />
<br />
Snapshots take the disk, memory, and device state of a domain at a point-of-time, and save it for future use. They have many uses, from saving a "clean" copy of an OS image to saving a domain's state before a potentially destructive operation. Snapshots are identified with a unique name.<br />
<br />
Snapshots are saved within the volume itself and the volume must be the format: qcow2 or raw. Snapshots use deltas so they have the potentiality to not take much space.<br />
<br />
==== Create a snapshot ====<br />
<br />
{{Out of date|Some of this data appears to be dated.}}<br />
<br />
Once a snapshot is taken it is saved as a new block device and the original snapshot is taken offline. Snapshots can be chosen from and also merged into another (even without shutting down the domain).<br />
<br />
Print a running domain's volumes (running domains can be printed with {{ic|virsh list}}):<br />
<br />
{{hc|# virsh domblklist ''domain''|<nowiki><br />
Target Source<br />
------------------------------------------------<br />
vda /vms/domain.img<br />
</nowiki>}}<br />
<br />
To see a volume's physical properties:<br />
<br />
{{hc|# qemu-img info /vms/domain.img|<nowiki><br />
image: /vms/domain.img<br />
file format: qcow2<br />
virtual size: 50G (53687091200 bytes)<br />
disk size: 2.1G<br />
cluster_size: 65536<br />
</nowiki>}}<br />
<br />
Create a disk-only snapshot (the option {{ic|--atomic}} will prevent the volume from being modified if snapshot creation fails):<br />
<br />
# virsh snapshot-create-as ''domain'' snapshot1 --disk-only --atomic<br />
<br />
List snapshots:<br />
<br />
{{hc|# virsh snapshot-list ''domain''|<nowiki><br />
Name Creation Time State<br />
------------------------------------------------------------<br />
snapshot1 2012-10-21 17:12:57 -0700 disk-snapshot<br />
</nowiki>}}<br />
<br />
One can they copy the original image with {{ic|1=cp --sparse=true}} or {{ic|rsync -S}} and then merge the the original back into snapshot:<br />
<br />
# virsh blockpull --domain ''domain'' --path /vms/''domain''.snapshot1<br />
<br />
{{ic|domain.snapshot1}} becomes a new volume. After this is done the original volume ({{ic|domain.img}} and snapshot metadata can be deleted. The {{ic|virsh blockcommit}} would work opposite to {{ic|blockpull}} but it seems to be currently under development (including {{ic|snapshot-revert feature}}, scheduled to be released sometime next year.<br />
<br />
=== Other management ===<br />
<br />
Connect to non-default hypervisor:<br />
<br />
$ virsh --connect xen:///<br />
virsh # uri<br />
xen:///<br />
<br />
Connect to the QEMU hypervisor over SSH; and the same with logging:<br />
<br />
$ virsh --connect qemu+ssh://''username''@''host''/system<br />
$ LIBVIRT_DEBUG=1 virsh --connect qemu+ssh://''username''@''host''/system<br />
<br />
Connect a graphic console over SSH:<br />
<br />
$ virt-viewer --connect qemu+ssh://''username''@''host''/system ''domain''<br />
$ virt-manager --connect qemu+ssh://''username''@''host''/system ''domain''<br />
<br />
{{Note|If you are having problems connecting to a remote RHEL server (or anything other than Arch, really), try the two workarounds mentioned in {{bug|30748}} and {{bug|22068}}.}}<br />
<br />
Connect to the VirtualBox hypervisor (''VirtualBox support in libvirt is not stable yet and may cause libvirtd to crash''):<br />
<br />
$ virsh --connect vbox:///system<br />
<br />
Network configurations:<br />
<br />
$ virsh -c qemu:///system net-list --all<br />
$ virsh -c qemu:///system net-dumpxml default<br />
<br />
== Python connectivity code ==<br />
<br />
The {{Pkg|libvirt-python}} package provides a {{Pkg|python2}} API in {{ic|/usr/lib/python2.7/site-packages/libvirt.py}}.<br />
<br />
General examples are given in {{ic|/usr/share/doc/libvirt-python-''your_libvirt_version''/examples/}}<br />
<br />
Unofficial example using {{Pkg|qemu}} and {{Pkg|openssh}}:<br />
<br />
#! /usr/bin/env python2<br />
# -*- coding: utf-8 -*-<br />
import socket<br />
import sys<br />
import libvirt<br />
if (__name__ == "__main__"):<br />
<nowiki>conn = libvirt.open("qemu+ssh://xxx/system")</nowiki><br />
print "Trying to find node on xxx"<br />
domains = conn.listDomainsID()<br />
for domainID in domains:<br />
domConnect = conn.lookupByID(domainID)<br />
if domConnect.name() == 'xxx-node':<br />
print "Found shared node on xxx with ID " + str(domainID)<br />
domServ = domConnect<br />
break<br />
<br />
== UEFI Support ==<br />
<br />
Libvirt can suport UEFI virtual machines through QEMU and [https://github.com/tianocore/edk2 OVMF].<br />
<br />
Currently this is possible in Arch Linux through a workaround. [https://bugs.archlinux.org/index.php?do=details&action=details.addvote&task_id=47101 This ovmf packaging bug] needs to be resolved for this to work out of the box or with minimal configuration of {{ic|/etc/libvirt/qemu.conf}}.<br />
<br />
=== OVMF - QEMU workaround ===<br />
<br />
* Build {{Pkg|ovmf}} from the [[ABS]] with {{ic|makepkg}}.<br />
* Copy the {{ic|OVMF_CODE.fd}} and {{ic|OVMF_VARS.fd}} files either for 64 or 32 bit to the default qemu location.<br />
<br />
{{hc|/etc/libvirt/qemu.conf|<nowiki><br />
#nvram = [<br />
# "/usr/share/OVMF/OVMF_CODE.fd:/usr/share/OVMF/OVMF_VARS.fd",<br />
# "/usr/share/OVMF/OVMF_CODE.secboot.fd:/usr/share/OVMF/OVMF_VARS.fd",<br />
# "/usr/share/AAVMF/AAVMF_CODE.fd:/usr/share/AAVMF/AAVMF_VARS.fd"<br />
#]<br />
</nowiki><br />
}}<br />
<br />
# mkdir /usr/share/OVMF<br />
# cp src/edk2/Build/OvmfX64/RELEASE_GCC49/FV/OVMF_CODE.fd src/edk2/Build/OvmfX64/RELEASE_GCC49/FV/OVMF_VARS.fd /usr/share/OVMF/ <br />
<br />
* Restart {{ic|libvirtd}}<br />
<br />
# systemctl stop libvirtd<br />
# systemctl start libvirtd<br />
<br />
Now you are ready to create a uefi virtual machine. Create a new virtual machine through {{Pkg|virt-manager}}. When you get to the final page of the 'New VM' wizard, do the following: <br />
<br />
* Click 'Customize before install', then select 'Finish'<br />
* On the 'Overview' screen, Change the 'Firmware' field to select the 'UEFI x86_64' option.<br />
* Click 'Begin Installation'<br />
* The boot screen you'll see should use linuxefi commands to boot the installer, and you should be able to run efibootmgr inside that system, to verify that you're running an UEFI OS. <br />
<br />
For more information about this, refer to [https://fedoraproject.org/wiki/Using_UEFI_with_QEMU this fedora wiki page].<br />
<br />
== PulseAudio ==<br />
<br />
The PulseAudio daemon normally runs under your regular user account, and will only accept connections from the same user. This can be a problem if QEMU is being run as root through [[libvirt]]. To run QEMU as a regular user, edit {{ic|/etc/libvirt/qemu.conf}} and set the {{ic|user}} option to your username.<br />
<br />
user = "dave"<br />
<br />
You will also need to tell QEMU to use the PulseAudio backend and identify the server to connect to. Add the following section to your domain configuration using {{ic|virsh edit}}.<br />
<br />
<qemu:commandline><br />
<qemu:env name='QEMU_AUDIO_DRV' value='pa'/><br />
<qemu:env name='QEMU_PA_SERVER' value='/run/user/1000/pulse/native'/><br />
</qemu:commandline><br />
<br />
{{ic|1000}} is your user id. Change it if necessary.<br />
<br />
== See also ==<br />
<br />
* [http://libvirt.org/drvqemu.html Official libvirt web site]<br />
* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Virtualization_Deployment_and_Administration_Guide/index.html Red Hat Virtualization Deployment and Administration Guide]<br />
* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Virtualization_Tuning_and_Optimization_Guide/index.html Red Hat Virtualization Tuning and Optimization Guide]<br />
* [http://docs.slackware.com/howtos:general_admin:kvm_libvirt Slackware KVM and libvirt]<br />
* [http://www-01.ibm.com/support/knowledgecenter/linuxonibm/liaat/liaatkvm.htm IBM KVM]<br />
* [https://jamielinux.com/docs/libvirt-networking-handbook/ libvirt Networking Handbook]</div>Kgizdovhttps://wiki.archlinux.org/index.php?title=Dell_XPS_13_(9350)&diff=425120Dell XPS 13 (9350)2016-03-11T14:05:39Z<p>Kgizdov: /* Wireless */</p>
<hr />
<div>[[Category:Dell]]<br />
{{Expansion|This page is a work in progress; you're warmly invited to contribute!}}<br />
{| class="wikitable" style="float: right;"<br />
| '''Device''' || '''Status''' || '''Modules'''<br />
|-<br />
| Video || {{G|Works after configuration}} || i915<br />
|-<br />
| Wireless || {{G|Works after configuration}} || brcmfmac<br />
|-<br />
| Bluetooth || {{G|Works after installing firmware}}|| btbcm<br />
|-<br />
| Audio || {{G|Working}} || snd_hda_intel<br />
|-<br />
| Touchpad || {{G|Works after configuration}} || ?<br />
|-<br />
| Webcam || {{G|Working}} || uvcvideo<br />
|-<br />
| Card Reader || {{G|Working}} || rtsx_pci<br />
|-<br />
| Wireless switch || {{R|Not supported yet}} || ?<br />
|-<br />
| Function/Multimedia Keys || {{G|Working}} || ?<br />
|}<br />
<br />
The Dell XPS 13 2016 (9350) is the third-generation model of the XPS 13 line. Unlike its predecessor, it has no official Linux support yet. Just like the older versions ([[Dell XPS 13]] and [[Dell XPS 13 (2015)]]) it can be bought in different hardware configurations.<br />
<br />
The installation process for Arch on the XPS 13 does not differ from any other PC. For installation help, please see the [[Installation guide]], [[Beginners' guide]] and [[UEFI]]. This page covers the current status of hardware support on Arch, as well as post-installation recommendations.<br />
<br />
As of kernel 4.3, the Intel Skylake architecture is supported.<br />
<br />
== BIOS updates ==<br />
[http://www.dell.com/support/home/us/en/04/Drivers/DriversDetails?driverId=T0R1K BIOS update 1.2.3] was released on 2016-01-29. Store the update binary on your EFI partition ({{ic|/boot/EFI}}) or on a USB flash drive, reboot, and choose BIOS Update in the F12 boot menu.<br />
<br />
== SATA controller ==<br />
When the SATA-controller is set to "RAID On" in Bios, the hard disk (at least the SSD) is not recognized. Set to "Off" or "AHCI" before attempting to install Arch. If dual boot to Windows is intended, follow [https://support.microsoft.com/en-us/kb/2795397] to work around the "INACCESSIBLE_BOOT_DEVICE" error.<br />
<br />
== NVM Express SSD ==<br />
=== Cannot find root device ===<br />
The location of the {{ic|nvme}} module for [[wikipedia:NVM_Express|"NVM Express"]] SSD has changed between {{Pkg|linux}} kernel version 4.3 and 4.4. If you experience "cannot find root device" on boot, it may be due to the [https://bugs.archlinux.org/task/47761 {{ic|nvme}} module not being present in {{ic|initramfs}}]. In this case, the following may resolve your issue.<br />
<br />
Edit your {{ic|/etc/mkinitcpio.conf}} file:<br />
...<br />
MODULES="... nvme"<br />
...<br />
<br />
Then update the bootloader.<br />
<br />
# mkinitcpio -p linux<br />
<br />
where {{ic|linux}} is the name of the image loaded on boot. If you installed {{AUR|linux-mainline}} then change that to {{ic|linux-mainline}}.<br />
<br />
=== Note on Mount Options ===<br />
<br />
As reported by a few users on [https://bbs.archlinux.org/viewtopic.php?pid=1593544#p1593544 the forum] using the {{ic|discard}} mount option for your filesystem is not recommended by Intel in [https://downloadmirror.intel.com/23929/eng/Intel_Linux_NVMe_Driver_Reference_Guide_330602-002.pdf the reference guide of the driver].<br />
<br />
An answer from [https://communities.intel.com/thread/75161?start=0&tstart=0 Intel Communities] suggests that the best option is to use the {{ic|fstrim}} timer which is provided by {{Pkg|util-linux}} and can be enabled simply through:<br />
<br />
# systemctl enable fstrim.timer<br />
<br />
== Wireless ==<br />
<br />
The built-in Broadcom BCM4350 is now supported in the current {{Pkg|linux}} kernel (as of version 4.4.1-1). The wireless module {{ic|brcmfmac}} also needs the firmware {{ic|brcmfmac4350-pcie.bin}} from the related {{Pkg|linux-firmware}} package.<br />
<br />
If you have not already done so, enable the testing repository to retrieve the package in {{ic|/etc/pacman.conf}}:<br />
<br />
# The testing repositories are disabled by default. To enable, uncomment the<br />
# repo name header and Include lines. You can add preferred servers immediately<br />
# after the header, and they will be used before the default mirrors.<br />
<br />
[core]<br />
Include = /etc/pacman.d/mirrorlist<br />
<br />
[testing]<br />
Include = /etc/pacman.d/mirrorlist<br />
<br />
The order matters. If you put the {{ic|[testing]}} repository before {{ic|[core]}} you are setting {{ic|pacman}} to default to the ''testing'' repository for all packages. Otherwise only packages that you install with {{ic|# pacman -S testing/''package-name''}} will be pulled from the ''testing'' repository. This way is preferred if you only need the {{Pkg|linux-firmware}} from ''testing'' and want to keep on ''core'' for others. You might want to install {{ic|testing/linux}} as well, but it is not mandatory if both the core and testing versions are on the same major version.<br />
<br />
== Bluetooth ==<br />
{{Note|'''Intel WiFi users:''' If your WiFi card supports Bluetooth, then the BT interface should be available out-of-the-box, as the required firmware is included in {{pkg|linux-firmware}}.}}<br />
<br />
The Broadcom Bluetooth firmware is not available in the kernel (the same as for 2015 model [http://tech.sybreon.com/2015/03/15/xps13-9343-ubuntu-linux/ source]), so you will have to retrieve it from the [http://downloads.dell.com/FOLDER03272920M/1/9350_Network_Driver_XMJK7_WN32_12.0.1.720_A00.EXE]. You need to extract the {{ic|.exe}} file with {{Pkg|p7zip}} and then convert it to a {{ic|.hcd}} file with ''hex2hcd'' from {{Pkg|bluez-utils}}:<br />
<br />
$ 7z x 9350_Network_Driver_XMJK7_WN32_12.0.1.720_A00.EXE<br />
$ cp Win32/BCM4350C5_003.006.007.0095.1703.hex ./<br />
$ hex2hcd BCM4350C5_003.006.007.0095.1703.hex<br />
# mv BCM4350C5_003.006.007.0095.1703.hcd /lib/firmware/brcm/BCM-0a5c-6412.hcd<br />
<br />
After reboot, the firmware should be available for your Bluetooth interface.<br />
<br />
== Video ==<br />
The video should work with the {{ic|i915}} driver of the current {{Pkg|linux}} kernel. If you experience a blank screen issue after booting, try loading the driver early in the boot process (see [[Intel graphics#Blank screen during boot, when "Loading modules"]]):<br />
<br />
{{hc|/etc/mkinitcpio.conf|2=MODULES="... i915 ..."}}<br />
<br />
{{Note|Some hardware also need {{ic|intel_agp}}. If you do, you should write {{ic|"... intel_agp i915 ..."}} (the order matters).}}<br />
<br />
Then update the bootloader.<br />
<br />
# mkinitcpio -p linux<br />
<br />
Where {{ic|linux}} is the name of the image loaded on boot. If you installed {{AUR|linux-mainline}} then change that to {{ic|linux-mainline}}.<br />
<br />
<br />
If you are using an older kernel 4.3 or earlier, you also require the kernel parameter {{ic|i915.preliminary_hw_support&#61;1}}, see [[Intel graphics#Driver not working for Intel Skylake chips]]. (For later kernels 4.3+ or {{AUR|linux-bcm4350}} the parameter is unnecessary.)<br />
<br />
== Touchpad ==<br />
Only key-presses work out of the box. Installing {{ic|xf86-input-synaptics}} and restarting X fixes the problem (see [[Dell Studio XPS 13]]). {{ic|xf86-input-libinput}} may be a good alternative that also handles touchscreen - see [[libinput]] for configuration.<br />
<br />
If {{ic|<nowiki>dmesg | grep -i psmouse</nowiki>}} returns an error, but your touchpad still works, then it might be a good idea to disable {{ic|psmouse}}. First create a config file:<br />
<br />
# nano /etc/modprobe.d/modprobe.conf<br />
<br />
blacklist psmouse<br />
<br />
Then add this file to {{ic|/etc/mkinitcpio.conf}}:<br />
<br />
...<br />
FILES="/etc/modprobe.d/modprobe.conf"<br />
...<br />
<br />
Then update the bootloader.<br />
<br />
# mkinitcpio -p linux<br />
<br />
where {{ic|linux}} is the name of the image loaded on boot. If you installed {{AUR|linux-mainline}} then change that to {{ic|linux-mainline}}.<br />
<br />
== Sound ==<br />
Some people reported white hissing/crackling noises when using headphones. To get rid of them you can run {{ic|alsamixer}} from {{Pkg|alsa-utils}}.<br />
Select your soundcard with F6 and set the headset-gain to 22 (3rd lever from the left) or use the {{ic|amixer}} command:<br />
<br />
$ amixer -c 0 cset 'numid=10' 1<br />
numid=10,iface=MIXER,name='Headphone Mic Boost Volume'<br />
; type=INTEGER,access=rw---R--,values=2,min=0,max=3,step=0<br />
: values=1,1<br />
| dBscale-min=0.00dB,step=10.00dB,mute=0<br />
<br />
Also people noticed loud popping-noises when sound was not playing.<br />
You can turn off the sound_power_save in {{ic|tlp}} <br />
<br />
# nano /etc/default/tlp<br />
...<br />
SOUND_POWER_SAVE_ON_BAT = 0 <br />
...<br />
=== PulseAudio Workaround ===<br />
PulseAudio will override the above setting every time you log in/out of your environment (or every time the PulseAudio service is restarted), even if the {{ic|alsa-restore.service}} is enabled at [[start]] up.<br />
<br />
To work around this issue, edit {{ic|/usr/share/pulseaudio/alsa-mixer/paths/analog-input-headphone-mic.conf}} and comment out the section {{ic|[Element Headphone Mic Boost]}}:<br />
<br />
---<br />
#[Element Headphone Mic Boost]<br />
#required-any = any<br />
#switch = select<br />
#volume = merge<br />
#override-map.1 = all<br />
#override-map.2 = all-left,all-right<br />
---<br />
<br />
Similarly in {{ic|/usr/share/pulseaudio/alsa-mixer/paths/analog-input-internal-mic.conf}}, comment out the same section:<br />
<br />
---<br />
#[Element Headphone Mic Boost]<br />
#switch = off<br />
#volume = off<br />
---<br />
<br />
This will prevent PulseAudio to fiddle with the gain setting at all. However, you must make the same modifications every time the PulseAudio package is updated.<br />
<br />
== Microphone ==<br />
{{Note| Not all hardware has the "Digital" channel}}<br />
For ALSA, increase "Digital" channel for microphone to work.<br />
<br />
== Links ==<br />
General Discussion Thread on Arch Forum [https://bbs.archlinux.org/viewtopic.php?pid=1579113]</div>Kgizdovhttps://wiki.archlinux.org/index.php?title=Dell_XPS_13_(9350)&diff=414469Dell XPS 13 (9350)2016-01-05T18:50:54Z<p>Kgizdov: /* Touchpad */ instructions to correct psmouse driver issue</p>
<hr />
<div>[[Category:Dell]]<br />
{{Stub|This page is a work in progress; you're warmly invited to contribute!}}<br />
{| class="wikitable" style="float: right;"<br />
| '''Device''' || '''Status''' || '''Modules'''<br />
|-<br />
| Video || {{G|Works after configuration}} || i915<br />
|-<br />
| Wireless || {{G|Works after configuration}} || brcmfmac<br />
|-<br />
| Bluetooth || {{G|Works after installing firmware}}|| btbcm<br />
|-<br />
| Audio || {{G|Working}} || snd_hda_intel<br />
|-<br />
| Touchpad || {{G|Works after configuration}} || ?<br />
|-<br />
| Webcam || {{G|Working}} || uvcvideo<br />
|-<br />
| Card Reader || {{G|Working}} || rtsx_pci<br />
|-<br />
| Wireless switch || {{R|Not supported yet}} || ?<br />
|-<br />
| Function/Multimedia Keys || {{G|Working}} || ?<br />
|}<br />
<br />
The Dell XPS 13 2016 (9350) is the third-generation model of the XPS 13 line. Unlike its predecessor, it has no official Linux support yet. Just like the older versions ([[Dell XPS 13]] and [[Dell XPS 13 (2015)]]) it can be bought in different hardware configurations.<br />
<br />
The installation process for Arch on the XPS 13 does not differ from any other PC. For installation help, please see the [[Installation guide]], [[Beginners' guide]] and [[UEFI]]. This page covers the current status of hardware support on Arch, as well as post-installation recommendations.<br />
<br />
As of kernel 4.3, the Intel Skylake architecture is supported.<br />
<br />
== SATA controller ==<br />
When the SATA-controller is set to "RAID On" in Bios, the hard disk (at least the SSD) is not recognized. Set to "Off" or "AHCI" before attempting to install Arch. If dual boot to Windows is intended, follow [https://support.microsoft.com/en-us/kb/2795397] to work around the "INACCESSIBLE_BOOT_DEVICE" error.<br />
<br />
== Wireless ==<br />
<br />
The built-in Broadcom BCM4350 is not supported in the current kernel(4.2.5) (and not by {{AUR|broadcom-wl}}) yet but marked for inclusion in 4.4 [https://wireless.wiki.kernel.org/en/users/drivers/brcm80211]<br />
<br />
As a workaround, use {{AUR|linux-bcm4350}} which includes the patch applied from 4.4 or get the 4.4 (or latest) kernel from {{AUR|linux-mainline}}. It also need a firmware from the {{Pkg|linux-firmware}} package.<br />
<br />
== Bluetooth ==<br />
{{Note|'''Intel WiFi users:''' If your WiFi card supports Bluetooth, then the BT interface should be available out-of-the-box, as the required firmware is included in {{pkg|linux-firmware}}.}}<br />
<br />
The Broadcom Bluetooth firmware is not available in the kernel (the same as for 2015 model [http://tech.sybreon.com/2015/03/15/xps13-9343-ubuntu-linux/ source]), so you will have to retrieve it from the [http://downloads.dell.com/FOLDER03272920M/1/9350_Network_Driver_XMJK7_WN32_12.0.1.720_A00.EXE]. You need to extract the {{ic|.exe}} file with {{Pkg|p7zip}} and then convert it to a {{ic|.hcd}} file with ''hex2hcd'' from {{Pkg|bluez-utils}}:<br />
<br />
$ 7z x 9350_Network_Driver_XMJK7_WN32_12.0.1.720_A00.EXE<br />
$ cp Win32/BCM4350C5_003.006.007.0095.1703.hex ./<br />
$ hex2hcd BCM4350C5_003.006.007.0095.1703.hex<br />
# mv BCM4350C5_003.006.007.0095.1703.hcd /lib/firmware/brcm/BCM-0a5c-6412.hcd<br />
<br />
After reboot, the firmware should be available for your Bluetooth interface.<br />
<br />
== Video ==<br />
{{Note| some hardware only needs {{ic|i915}}}}<br />
Works with kernel parameter {{ic|i915.preliminary_hw_support&#61;1}} [[Intel graphics#Driver not working for Intel Skylake chips]]. For kernels 4.3+ ({{AUR|linux-bcm4350}}) the parameter is unnecessary, but you may face blank screen problem after booting - adding {{ic|i915}} and {{ic|intel_agp}} to the kernel modules fixes the problem, see [[Intel graphics#Blank screen during boot, when "Loading modules"]]<br />
<br />
# nano /etc/mkinitcpio.conf<br />
...<br />
MODULES="... intel_agp i915"<br />
...<br />
<br />
Then update the bootloader.<br />
<br />
# mkinitcpio -p linux<br />
<br />
where {{ic|linux}} is the name of the image loaded on boot. If you installed {{AUR|linux-mainline}} then change that to {{ic|linux-mainline}}.<br />
<br />
== Touchpad ==<br />
Only key-presses work out of the box. Installing {{ic|xf86-input-synaptics}} and restarting X fixes the problem (see [[Dell Studio XPS 13]]). {{ic|xf86-input-libinput}} may be a good alternative that also handles touchscreen - see [[libinput]] for configuration.<br />
<br />
If {{ic|<nowiki>dmesg | grep -i psmouse</nowiki>}} returns an error, but your touchpad still works, then it might be a good idea to disable {{ic|psmouse}}. First create a config file:<br />
<br />
# nano /etc/modprobe.d/modprobe.conf<br />
<br />
blacklist psmouse<br />
<br />
Then add this file to {{ic|/etc/mkinitcpio.conf}}:<br />
<br />
...<br />
FILES="/etc/modprobe.d/modprobe.conf"<br />
...<br />
<br />
Then update the bootloader.<br />
<br />
# mkinitcpio -p linux<br />
<br />
where {{ic|linux}} is the name of the image loaded on boot. If you installed {{AUR|linux-mainline}} then change that to {{ic|linux-mainline}}.<br />
<br />
== Microphone ==<br />
{{Note| Not all hardware has the "Digital" channel}}<br />
For ALSA, increase "Digital" channel for microphone to work.<br />
<br />
== Kernel specific notes ==<br />
4.3.x requires the broadcom wifi patch for wifi to work.<br />
<br />
4.4.x requires adding "nvme" in modules to detect pcie ssd. The broadcom wifi driver patch is no longer needed.<br />
<br />
# nano /etc/mkinitcpio.conf<br />
...<br />
MODULES="... nvme"<br />
...<br />
<br />
Then update the bootloader.<br />
<br />
# mkinitcpio -p linux<br />
<br />
where {{ic|linux}} is the name of the image loaded on boot. If you installed {{AUR|linux-mainline}} then change that to {{ic|linux-mainline}}.<br />
<br />
== Links ==<br />
General Discussion Thread on Arch Forum [https://bbs.archlinux.org/viewtopic.php?pid=1579113]</div>Kgizdovhttps://wiki.archlinux.org/index.php?title=Dell_XPS_13_(9350)&diff=414468Dell XPS 13 (9350)2016-01-05T18:35:32Z<p>Kgizdov: /* Video */ Detailed mkinitcpio.conf</p>
<hr />
<div>[[Category:Dell]]<br />
{{Stub|This page is a work in progress; you're warmly invited to contribute!}}<br />
{| class="wikitable" style="float: right;"<br />
| '''Device''' || '''Status''' || '''Modules'''<br />
|-<br />
| Video || {{G|Works after configuration}} || i915<br />
|-<br />
| Wireless || {{G|Works after configuration}} || brcmfmac<br />
|-<br />
| Bluetooth || {{G|Works after installing firmware}}|| btbcm<br />
|-<br />
| Audio || {{G|Working}} || snd_hda_intel<br />
|-<br />
| Touchpad || {{G|Works after configuration}} || ?<br />
|-<br />
| Webcam || {{G|Working}} || uvcvideo<br />
|-<br />
| Card Reader || {{G|Working}} || rtsx_pci<br />
|-<br />
| Wireless switch || {{R|Not supported yet}} || ?<br />
|-<br />
| Function/Multimedia Keys || {{G|Working}} || ?<br />
|}<br />
<br />
The Dell XPS 13 2016 (9350) is the third-generation model of the XPS 13 line. Unlike its predecessor, it has no official Linux support yet. Just like the older versions ([[Dell XPS 13]] and [[Dell XPS 13 (2015)]]) it can be bought in different hardware configurations.<br />
<br />
The installation process for Arch on the XPS 13 does not differ from any other PC. For installation help, please see the [[Installation guide]], [[Beginners' guide]] and [[UEFI]]. This page covers the current status of hardware support on Arch, as well as post-installation recommendations.<br />
<br />
As of kernel 4.3, the Intel Skylake architecture is supported.<br />
<br />
== SATA controller ==<br />
When the SATA-controller is set to "RAID On" in Bios, the hard disk (at least the SSD) is not recognized. Set to "Off" or "AHCI" before attempting to install Arch. If dual boot to Windows is intended, follow [https://support.microsoft.com/en-us/kb/2795397] to work around the "INACCESSIBLE_BOOT_DEVICE" error.<br />
<br />
== Wireless ==<br />
<br />
The built-in Broadcom BCM4350 is not supported in the current kernel(4.2.5) (and not by {{AUR|broadcom-wl}}) yet but marked for inclusion in 4.4 [https://wireless.wiki.kernel.org/en/users/drivers/brcm80211]<br />
<br />
As a workaround, use {{AUR|linux-bcm4350}} which includes the patch applied from 4.4 or get the 4.4 (or latest) kernel from {{AUR|linux-mainline}}. It also need a firmware from the {{Pkg|linux-firmware}} package.<br />
<br />
== Bluetooth ==<br />
{{Note|'''Intel WiFi users:''' If your WiFi card supports Bluetooth, then the BT interface should be available out-of-the-box, as the required firmware is included in {{pkg|linux-firmware}}.}}<br />
<br />
The Broadcom Bluetooth firmware is not available in the kernel (the same as for 2015 model [http://tech.sybreon.com/2015/03/15/xps13-9343-ubuntu-linux/ source]), so you will have to retrieve it from the [http://downloads.dell.com/FOLDER03272920M/1/9350_Network_Driver_XMJK7_WN32_12.0.1.720_A00.EXE]. You need to extract the {{ic|.exe}} file with {{Pkg|p7zip}} and then convert it to a {{ic|.hcd}} file with ''hex2hcd'' from {{Pkg|bluez-utils}}:<br />
<br />
$ 7z x 9350_Network_Driver_XMJK7_WN32_12.0.1.720_A00.EXE<br />
$ cp Win32/BCM4350C5_003.006.007.0095.1703.hex ./<br />
$ hex2hcd BCM4350C5_003.006.007.0095.1703.hex<br />
# mv BCM4350C5_003.006.007.0095.1703.hcd /lib/firmware/brcm/BCM-0a5c-6412.hcd<br />
<br />
After reboot, the firmware should be available for your Bluetooth interface.<br />
<br />
== Video ==<br />
{{Note| some hardware only needs {{ic|i915}}}}<br />
Works with kernel parameter {{ic|i915.preliminary_hw_support&#61;1}} [[Intel graphics#Driver not working for Intel Skylake chips]]. For kernels 4.3+ ({{AUR|linux-bcm4350}}) the parameter is unnecessary, but you may face blank screen problem after booting - adding {{ic|i915}} and {{ic|intel_agp}} to the kernel modules fixes the problem, see [[Intel graphics#Blank screen during boot, when "Loading modules"]]<br />
<br />
# nano /etc/mkinitcpio.conf<br />
...<br />
MODULES="... intel_agp i915"<br />
...<br />
<br />
Then update the bootloader.<br />
<br />
# mkinitcpio -p linux<br />
<br />
where {{ic|linux}} is the name of the image loaded on boot. If you installed {{AUR|linux-mainline}} then change that to {{ic|linux-mainline}}.<br />
<br />
== Touchpad ==<br />
Only key-presses work out of the box. Installing {{ic|xf86-input-synaptics}} and restarting X fixes the problem (see [[Dell Studio XPS 13]]). {{ic|xf86-input-libinput}} may be a good alternative that also handles touchscreen - see [[libinput]] for configuration.<br />
<br />
== Microphone ==<br />
{{Note| Not all hardware has the "Digital" channel}}<br />
For ALSA, increase "Digital" channel for microphone to work.<br />
<br />
== Kernel specific notes ==<br />
4.3.x requires the broadcom wifi patch for wifi to work.<br />
<br />
4.4.x requires adding "nvme" in modules to detect pcie ssd. The broadcom wifi driver patch is no longer needed.<br />
<br />
# nano /etc/mkinitcpio.conf<br />
...<br />
MODULES="... nvme"<br />
...<br />
<br />
Then update the bootloader.<br />
<br />
# mkinitcpio -p linux<br />
<br />
where {{ic|linux}} is the name of the image loaded on boot. If you installed {{AUR|linux-mainline}} then change that to {{ic|linux-mainline}}.<br />
<br />
== Links ==<br />
General Discussion Thread on Arch Forum [https://bbs.archlinux.org/viewtopic.php?pid=1579113]</div>Kgizdovhttps://wiki.archlinux.org/index.php?title=Dell_XPS_13_(9350)&diff=414467Dell XPS 13 (9350)2016-01-05T18:33:45Z<p>Kgizdov: /* Video */ Fixed ambiguous statement for kernel modules</p>
<hr />
<div>[[Category:Dell]]<br />
{{Stub|This page is a work in progress; you're warmly invited to contribute!}}<br />
{| class="wikitable" style="float: right;"<br />
| '''Device''' || '''Status''' || '''Modules'''<br />
|-<br />
| Video || {{G|Works after configuration}} || i915<br />
|-<br />
| Wireless || {{G|Works after configuration}} || brcmfmac<br />
|-<br />
| Bluetooth || {{G|Works after installing firmware}}|| btbcm<br />
|-<br />
| Audio || {{G|Working}} || snd_hda_intel<br />
|-<br />
| Touchpad || {{G|Works after configuration}} || ?<br />
|-<br />
| Webcam || {{G|Working}} || uvcvideo<br />
|-<br />
| Card Reader || {{G|Working}} || rtsx_pci<br />
|-<br />
| Wireless switch || {{R|Not supported yet}} || ?<br />
|-<br />
| Function/Multimedia Keys || {{G|Working}} || ?<br />
|}<br />
<br />
The Dell XPS 13 2016 (9350) is the third-generation model of the XPS 13 line. Unlike its predecessor, it has no official Linux support yet. Just like the older versions ([[Dell XPS 13]] and [[Dell XPS 13 (2015)]]) it can be bought in different hardware configurations.<br />
<br />
The installation process for Arch on the XPS 13 does not differ from any other PC. For installation help, please see the [[Installation guide]], [[Beginners' guide]] and [[UEFI]]. This page covers the current status of hardware support on Arch, as well as post-installation recommendations.<br />
<br />
As of kernel 4.3, the Intel Skylake architecture is supported.<br />
<br />
== SATA controller ==<br />
When the SATA-controller is set to "RAID On" in Bios, the hard disk (at least the SSD) is not recognized. Set to "Off" or "AHCI" before attempting to install Arch. If dual boot to Windows is intended, follow [https://support.microsoft.com/en-us/kb/2795397] to work around the "INACCESSIBLE_BOOT_DEVICE" error.<br />
<br />
== Wireless ==<br />
<br />
The built-in Broadcom BCM4350 is not supported in the current kernel(4.2.5) (and not by {{AUR|broadcom-wl}}) yet but marked for inclusion in 4.4 [https://wireless.wiki.kernel.org/en/users/drivers/brcm80211]<br />
<br />
As a workaround, use {{AUR|linux-bcm4350}} which includes the patch applied from 4.4 or get the 4.4 (or latest) kernel from {{AUR|linux-mainline}}. It also need a firmware from the {{Pkg|linux-firmware}} package.<br />
<br />
== Bluetooth ==<br />
{{Note|'''Intel WiFi users:''' If your WiFi card supports Bluetooth, then the BT interface should be available out-of-the-box, as the required firmware is included in {{pkg|linux-firmware}}.}}<br />
<br />
The Broadcom Bluetooth firmware is not available in the kernel (the same as for 2015 model [http://tech.sybreon.com/2015/03/15/xps13-9343-ubuntu-linux/ source]), so you will have to retrieve it from the [http://downloads.dell.com/FOLDER03272920M/1/9350_Network_Driver_XMJK7_WN32_12.0.1.720_A00.EXE]. You need to extract the {{ic|.exe}} file with {{Pkg|p7zip}} and then convert it to a {{ic|.hcd}} file with ''hex2hcd'' from {{Pkg|bluez-utils}}:<br />
<br />
$ 7z x 9350_Network_Driver_XMJK7_WN32_12.0.1.720_A00.EXE<br />
$ cp Win32/BCM4350C5_003.006.007.0095.1703.hex ./<br />
$ hex2hcd BCM4350C5_003.006.007.0095.1703.hex<br />
# mv BCM4350C5_003.006.007.0095.1703.hcd /lib/firmware/brcm/BCM-0a5c-6412.hcd<br />
<br />
After reboot, the firmware should be available for your Bluetooth interface.<br />
<br />
== Video ==<br />
{{Note| some hardware only needs {{ic|i915}}}}<br />
Works with kernel parameter {{ic|i915.preliminary_hw_support&#61;1}} [[Intel graphics#Driver not working for Intel Skylake chips]]. For kernels 4.3+ ({{AUR|linux-bcm4350}}) the parameter is unnecessary, but you may face blank screen problem after booting - adding {{ic|i915}} and {{ic|intel_agp}} to the kernel modules fixes the problem, see [[Intel graphics#Blank screen during boot, when "Loading modules"]]<br />
<br />
== Touchpad ==<br />
Only key-presses work out of the box. Installing {{ic|xf86-input-synaptics}} and restarting X fixes the problem (see [[Dell Studio XPS 13]]). {{ic|xf86-input-libinput}} may be a good alternative that also handles touchscreen - see [[libinput]] for configuration.<br />
<br />
== Microphone ==<br />
{{Note| Not all hardware has the "Digital" channel}}<br />
For ALSA, increase "Digital" channel for microphone to work.<br />
<br />
== Kernel specific notes ==<br />
4.3.x requires the broadcom wifi patch for wifi to work.<br />
<br />
4.4.x requires adding "nvme" in modules to detect pcie ssd. The broadcom wifi driver patch is no longer needed.<br />
<br />
# nano /etc/mkinitcpio.conf<br />
...<br />
MODULES="... nvme"<br />
...<br />
<br />
Then update the bootloader.<br />
<br />
# mkinitcpio -p linux<br />
<br />
where {{ic|linux}} is the name of the image loaded on boot. If you installed {{AUR|linux-mainline}} then change that to {{ic|linux-mainline}}.<br />
<br />
== Links ==<br />
General Discussion Thread on Arch Forum [https://bbs.archlinux.org/viewtopic.php?pid=1579113]</div>Kgizdovhttps://wiki.archlinux.org/index.php?title=Dell_XPS_13_(9350)&diff=414466Dell XPS 13 (9350)2016-01-05T18:31:39Z<p>Kgizdov: /* Kernel specific notes */ Detailed mkinitcpio.conf</p>
<hr />
<div>[[Category:Dell]]<br />
{{Stub|This page is a work in progress; you're warmly invited to contribute!}}<br />
{| class="wikitable" style="float: right;"<br />
| '''Device''' || '''Status''' || '''Modules'''<br />
|-<br />
| Video || {{G|Works after configuration}} || i915<br />
|-<br />
| Wireless || {{G|Works after configuration}} || brcmfmac<br />
|-<br />
| Bluetooth || {{G|Works after installing firmware}}|| btbcm<br />
|-<br />
| Audio || {{G|Working}} || snd_hda_intel<br />
|-<br />
| Touchpad || {{G|Works after configuration}} || ?<br />
|-<br />
| Webcam || {{G|Working}} || uvcvideo<br />
|-<br />
| Card Reader || {{G|Working}} || rtsx_pci<br />
|-<br />
| Wireless switch || {{R|Not supported yet}} || ?<br />
|-<br />
| Function/Multimedia Keys || {{G|Working}} || ?<br />
|}<br />
<br />
The Dell XPS 13 2016 (9350) is the third-generation model of the XPS 13 line. Unlike its predecessor, it has no official Linux support yet. Just like the older versions ([[Dell XPS 13]] and [[Dell XPS 13 (2015)]]) it can be bought in different hardware configurations.<br />
<br />
The installation process for Arch on the XPS 13 does not differ from any other PC. For installation help, please see the [[Installation guide]], [[Beginners' guide]] and [[UEFI]]. This page covers the current status of hardware support on Arch, as well as post-installation recommendations.<br />
<br />
As of kernel 4.3, the Intel Skylake architecture is supported.<br />
<br />
== SATA controller ==<br />
When the SATA-controller is set to "RAID On" in Bios, the hard disk (at least the SSD) is not recognized. Set to "Off" or "AHCI" before attempting to install Arch. If dual boot to Windows is intended, follow [https://support.microsoft.com/en-us/kb/2795397] to work around the "INACCESSIBLE_BOOT_DEVICE" error.<br />
<br />
== Wireless ==<br />
<br />
The built-in Broadcom BCM4350 is not supported in the current kernel(4.2.5) (and not by {{AUR|broadcom-wl}}) yet but marked for inclusion in 4.4 [https://wireless.wiki.kernel.org/en/users/drivers/brcm80211]<br />
<br />
As a workaround, use {{AUR|linux-bcm4350}} which includes the patch applied from 4.4 or get the 4.4 (or latest) kernel from {{AUR|linux-mainline}}. It also need a firmware from the {{Pkg|linux-firmware}} package.<br />
<br />
== Bluetooth ==<br />
{{Note|'''Intel WiFi users:''' If your WiFi card supports Bluetooth, then the BT interface should be available out-of-the-box, as the required firmware is included in {{pkg|linux-firmware}}.}}<br />
<br />
The Broadcom Bluetooth firmware is not available in the kernel (the same as for 2015 model [http://tech.sybreon.com/2015/03/15/xps13-9343-ubuntu-linux/ source]), so you will have to retrieve it from the [http://downloads.dell.com/FOLDER03272920M/1/9350_Network_Driver_XMJK7_WN32_12.0.1.720_A00.EXE]. You need to extract the {{ic|.exe}} file with {{Pkg|p7zip}} and then convert it to a {{ic|.hcd}} file with ''hex2hcd'' from {{Pkg|bluez-utils}}:<br />
<br />
$ 7z x 9350_Network_Driver_XMJK7_WN32_12.0.1.720_A00.EXE<br />
$ cp Win32/BCM4350C5_003.006.007.0095.1703.hex ./<br />
$ hex2hcd BCM4350C5_003.006.007.0095.1703.hex<br />
# mv BCM4350C5_003.006.007.0095.1703.hcd /lib/firmware/brcm/BCM-0a5c-6412.hcd<br />
<br />
After reboot, the firmware should be available for your Bluetooth interface.<br />
<br />
== Video ==<br />
{{Note| some hardware only needs {{ic|i915}}}}<br />
Works with kernel parameter {{ic|i915.preliminary_hw_support&#61;1}} [[Intel graphics#Driver not working for Intel Skylake chips]]. For kernels 4.3+ ({{AUR|linux-bcm4350}}) the parameter is unnecessary, but you may face blank screen problem after booting - adding {{ic|i915}} and {{ic|intel_agp}} to initramfs fixes the problem, see [[Intel graphics#Blank screen during boot, when "Loading modules"]]<br />
<br />
== Touchpad ==<br />
Only key-presses work out of the box. Installing {{ic|xf86-input-synaptics}} and restarting X fixes the problem (see [[Dell Studio XPS 13]]). {{ic|xf86-input-libinput}} may be a good alternative that also handles touchscreen - see [[libinput]] for configuration.<br />
<br />
== Microphone ==<br />
{{Note| Not all hardware has the "Digital" channel}}<br />
For ALSA, increase "Digital" channel for microphone to work.<br />
<br />
== Kernel specific notes ==<br />
4.3.x requires the broadcom wifi patch for wifi to work.<br />
<br />
4.4.x requires adding "nvme" in modules to detect pcie ssd. The broadcom wifi driver patch is no longer needed.<br />
<br />
# nano /etc/mkinitcpio.conf<br />
...<br />
MODULES="... nvme"<br />
...<br />
<br />
Then update the bootloader.<br />
<br />
# mkinitcpio -p linux<br />
<br />
where {{ic|linux}} is the name of the image loaded on boot. If you installed {{AUR|linux-mainline}} then change that to {{ic|linux-mainline}}.<br />
<br />
== Links ==<br />
General Discussion Thread on Arch Forum [https://bbs.archlinux.org/viewtopic.php?pid=1579113]</div>Kgizdovhttps://wiki.archlinux.org/index.php?title=Trusted_Platform_Module&diff=411325Trusted Platform Module2015-12-09T11:20:48Z<p>Kgizdov: /* Basics */ - tpm_selftest is device specific so needs [-l info] flag to confirm operation</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:Other hardware]]<br />
Trusted Platform Module (TPM) is an international standard for a secure cryptoprocessor, which is a dedicated microprocessor designed to secure hardware by integrating cryptographic keys into devices.<br />
<br />
In practice a TPM can be used for various different security applications such as secure boot and key storage.<br />
<br />
TPM is naturally supported only on devices that have TPM hardware support. If your hardware has TPM support but it is not showing up, it might need to be enabled in the BIOS settings.<br />
<br />
==Drivers==<br />
TPM drivers are natively supported in modern kernels, but might need to be loaded:<br />
<br />
# modprobe tpm<br />
<br />
Depending on your chipset, you might also need to load one of the following:<br />
<br />
# modprobe tpm_atmel tpm_bios tpm_infineon tpm_nsc tpm_tis<br />
<br />
== Usage ==<br />
<br />
TPM is managed by {{ic|tcsd}}, a userspace daemon that manages Trusted Computing resources and should be (according to the TSS spec) the only portal to the TPM device driver. {{ic|tcsd}} is part of the {{AUR|trousers}} AUR package, which was created and released by IBM, and can be configured via {{ic|/etc/tcsd.conf}}.<br />
<br />
To start tcsd and watch the output, run:<br />
<br />
# tcsd -f<br />
<br />
or simply start and enable {{ic|tcsd.service}}.<br />
<br />
Once {{ic|tcsd}} is running you might also want to install {{AUR|tpm-tools}} which provides many of the command line tools for managing the TPM.<br />
<br />
Some other tools of interest:<br />
<br />
* {{App|tpmmanager|A Qt front-end to tpm-tools|http://sourceforge.net/projects/tpmmanager|{{AUR|tpmmanager}}}}<br />
* {{App|openssl_tpm_engine|OpenSSL engine which interfaces with the TSS API|http://sourceforge.net/projects/trousers|{{AUR|openssl_tpm_engine}}{{Broken package link|{{aur-mirror|openssl_tpm_engine}}}}}}<br />
* {{App|tpm_keyring2|A key manager for TPM based eCryptfs keys|http://sourceforge.net/projects/trousers|{{AUR|tpm_keyring2}}{{Broken package link|{{aur-mirror|tpm_keyring2}}}}}}<br />
* {{App|opencryptoki|A PKCS#11 implementation for Linux. It includes drivers and libraries to enable IBM cryptographic hardware as well as a software token for testing.|http://sourceforge.net/projects/opencryptoki|{{AUR|opencryptoki}}}}<br />
<br />
=== Basics ===<br />
<br />
Start off by getting basic version info:<br />
<br />
$ tpm_version<br />
<br />
and running a selftest:<br />
<br />
$ tpm_selftest -l info<br />
TPM Test Results: 00000000 ...<br />
tpm_selftest succeeded<br />
<br />
=== Securing SSH Keys ===<br />
<br />
There are several methods to use TPM to secure keys, but here we show a simple method based on {{aur|simple-tpm-pk11-git}}.<br />
<br />
First, create a new directory and generate the key:<br />
<br />
$ mkdir ~/.simple-tpm-pk11<br />
$ stpm-keygen -o ~/.simple-tpm-pk11/my.key<br />
<br />
Point the config to the key:<br />
<br />
{{hc|~/.simple-tpm-pk11/config|<br />
key my.key<br />
}}<br />
<br />
Now configure SSH to use the right PKCS11 provider:<br />
<br />
{{hc|~/.ssh/config|<br />
Host *<br />
PKCS11Provider /usr/lib/libsimple-tpm-pk11.so<br />
}}<br />
<br />
It's now possible to generate keys with the PKCS11 provider:<br />
<br />
$ ssh-keygen -D /usr/lib/libsimple-tpm-pk11.so<br />
<br />
{{Note|This method currently does not allow for multiple keys to be generated and used.}}<br />
<br />
==References==<br />
* [https://en.wikipedia.org/wiki/Trusted_Platform_Module TPM on Wikipedia]<br />
* [http://www.thinkwiki.org/wiki/Embedded_Security_Subsystem Embedded Security Subsystem on Thinkwiki]<br />
* [http://www.cs.unh.edu/~it666/reading_list/Hardware/tpm_fundamentals.pdf TPM Fundamentals (PDF)]</div>Kgizdov