# an encrypted channel.
#
# It is possible to use x509 certificates for authentication too, by
-# issuing a x509 certificate to every client who needs to connect.
+# issuing an x509 certificate to every client who needs to connect.
#
# Enabling this option will reject any client who does not have a
# certificate signed by the CA in /etc/pki/qemu/ca-cert.pem
#
+# The default_tls_x509_cert_dir directory must also contain
+#
+# client-cert.pem - the client certificate signed with the ca-cert.pem
+# client-key.pem - the client private key
+#
#default_tls_x509_verify = 1
#
# an encrypted channel.
#
# It is possible to use x509 certificates for authentication too, by
-# issuing a x509 certificate to every client who needs to connect.
+# issuing an x509 certificate to every client who needs to connect.
#
-# Enabling this option will reject any client who does not have a
-# certificate signed by the CA in /etc/pki/libvirt-vnc/ca-cert.pem
+# Enabling this option will reject any client that does not have a
+# ca-cert.pem certificate signed by the CA in the vnc_tls_x509_cert_dir
+# (or default_tls_x509_cert_dir) as well as the corresponding client-*.pem
+# files described in default_tls_x509_cert_dir.
#
# If this option is not supplied, it will be set to the value of
# "default_tls_x509_verify".
# an encrypted channel.
#
# It is possible to use x509 certificates for authentication too, by
-# issuing a x509 certificate to every client who needs to connect.
+# issuing an x509 certificate to every client who needs to connect.
#
-# Enabling this option will reject any client who does not have a
-# certificate signed by the CA in /etc/pki/libvirt-chardev/ca-cert.pem
+# Enabling this option will reject any client that does not have a
+# ca-cert.pem certificate signed by the CA in the chardev_tls_x509_cert_dir
+# (or default_tls_x509_cert_dir) as well as the corresponding client-*.pem
+# files described in default_tls_x509_cert_dir.
+#
+# If this option is not supplied, it will be set to the value of
+# "default_tls_x509_verify".
#
#chardev_tls_x509_verify = 1
#chardev_tls_x509_secret_uuid = "00000000-0000-0000-0000-000000000000"
+# In order to override the default TLS certificate location for migration
+# certificates, supply a valid path to the certificate directory. If the
+# provided path does not exist then the default_tls_x509_cert_dir path
+# will be used. Once/if a default certificate is enabled/defined, migration
+# will then be able to use the certificate via migration API flags.
+#
+#migrate_tls_x509_cert_dir = "/etc/pki/libvirt-migrate"
+
+
+# The default TLS configuration only uses certificates for the server
+# allowing the client to verify the server's identity and establish
+# an encrypted channel.
+#
+# It is possible to use x509 certificates for authentication too, by
+# issuing an x509 certificate to every client who needs to connect.
+#
+# Enabling this option will reject any client that does not have a
+# ca-cert.pem certificate signed by the CA in the migrate_tls_x509_cert_dir
+# (or default_tls_x509_cert_dir) as well as the corresponding client-*.pem
+# files described in default_tls_x509_cert_dir.
+#
+# If this option is not supplied, it will be set to the value of
+# "default_tls_x509_verify".
+#
+#migrate_tls_x509_verify = 1
+
+
+# Uncomment and use the following option to override the default secret
+# UUID provided in the default_tls_x509_secret_uuid parameter.
+#
+# NB This default all-zeros UUID will not work. Replace it with the
+# output from the UUID for the TLS secret from a 'virsh secret-list'
+# command and then uncomment the entry
+#
+#migrate_tls_x509_secret_uuid = "00000000-0000-0000-0000-000000000000"
+
+
# By default, if no graphical front end is configured, libvirt will disable
# QEMU audio output since directly talking to alsa/pulseaudio may not work
# with various security settings. If you know what you're doing, enable
# "/dev/null", "/dev/full", "/dev/zero",
# "/dev/random", "/dev/urandom",
# "/dev/ptmx", "/dev/kvm", "/dev/kqemu",
-# "/dev/rtc","/dev/hpet", "/dev/vfio/vfio"
+# "/dev/rtc","/dev/hpet"
#]
#
# RDMA migration requires the following extra files to be added to the list:
# "/dev/infiniband/uverbs0"
-# The default format for Qemu/KVM guest save images is raw; that is, the
+# The default format for QEMU/KVM guest save images is raw; that is, the
# memory from the domain is dumped out directly to a file. If you have
# guests with a large amount of memory, however, this can take up quite
# a bit of space. If you would like to compress the images while they
#
#stdio_handler = "logd"
-# Qemu gluster libgfapi log level, debug levels are 0-9, with 9 being the
+# QEMU gluster libgfapi log level, debug levels are 0-9, with 9 being the
# most verbose, and 0 representing no debugging output.
#
# The current logging levels defined in the gluster GFAPI are:
# Defaults to 4
#
#gluster_debug_level = 9
+
+# To enhance security, QEMU driver is capable of creating private namespaces
+# for each domain started. Well, so far only "mount" namespace is supported. If
+# enabled it means qemu process is unable to see all the devices on the system,
+# only those configured for the domain in question. Libvirt then manages
+# devices entries throughout the domain lifetime. This namespace is turned on
+# by default.
+#namespaces = [ "mount" ]
+
+# This directory is used for memoryBacking source if configured as file.
+# NOTE: big files will be stored here
+#memory_backing_dir = "/var/lib/libvirt/qemu/ram"
-# If you want to use the non-TLS socket, then you *must* include
-# the GSSAPI or DIGEST-MD5 mechanisms, because they are the only
-# ones that can offer session encryption as well as authentication.
+# If you want to use the non-TLS socket, then you *must* pick a
+# mechanism which provides session encryption as well as
+# authentication.
#
-# If you're only using TLS, then you can turn on any mechanisms
+# If you are only using TLS, then you can turn on any mechanisms
# you like for authentication, because TLS provides the encryption
#
-# Default to a simple username+password mechanism
-mech_list: digest-md5
+# If you are only using UNIX, sockets then encryption is not
+# required at all.
+#
+# Since SASL is the default for the libvirtd non-TLS socket, we
+# pick a strong mechanism by default.
+#
+# NB, previously DIGEST-MD5 was set as the default mechanism for
+# libvirt. Per RFC 6331 this is vulnerable to many serious security
+# flaws and should no longer be used. Thus GSSAPI is now the default.
+#
+# To use GSSAPI requires that a libvirtd service principal is
+# added to the Kerberos server for each host running libvirtd.
+# This principal needs to be exported to the keytab file listed below
+mech_list: gssapi
+
+# If using a TLS socket or UNIX socket only, it is possible to
+# enable plugins which don't provide session encryption. The
+# 'scram-sha-1' plugin allows plain username/password authentication
+# to be performed
+#
+#mech_list: scram-sha-1
-# Before you can use GSSAPI, you need a service principle on the
-# KDC server for libvirt, and that to be exported to the keytab
-# file listed below
-#mech_list: gssapi
#
# You can also list many mechanisms at once, then the user can choose
# by adding '?auth=sasl.gssapi' to their libvirt URI, eg
# qemu+tcp://hostname/system?auth=sasl.gssapi
-#mech_list: digest-md5 gssapi
+#mech_list: scram-sha-1 gssapi
# Some older builds of MIT kerberos on Linux ignore this option &
# instead need KRB5_KTNAME env var.
# For modern Linux, and other OS, this should be sufficient
#
-# There is no default value here, uncomment if you need this
-#keytab: /etc/libvirt/krb5.tab
+keytab: /etc/libvirt/krb5.tab
-# If using digest-md5 for username/passwds, then this is the file
+# If using scram-sha-1 for username/passwds, then this is the file
# containing the passwds. Use 'saslpasswd2 -a libvirt [username]'
# to add entries, and 'sasldblistusers2 -f [sasldb_path]' to browse it
-sasldb_path: /etc/libvirt/passwd.db
+#sasldb_path: /etc/libvirt/passwd.db