Kata Containers是基于Intel Clear Container + Hyper runV实现的轻量级的虚拟机，能够无缝的集成到容器生态系统中。Kata和Container一样轻量、快速，同时具有传统虚拟化的安全优势，Kata和Docker的OCI规范、K8S的CRI接口兼容。

迁移到容器云需要面临的一个重要挑战就是安全问题。多租户环境下，不安全负载和受信任负载在一起运行。Kata利用基于硬件的隔离，实现容器/Pod的安全边界，解决了传统容器架构共享内核的安全缺陷（提权漏洞）。使用Kata，你可以在单个K8S集群中服务多个租户。

支持工业标准，包括OCI容器格式、K8S的CRI接口。

这是虚拟化的优势，即允许使用任意的客户机操作系统，允许设备穿透访问。

Kata包含Agent、Runtime、Proxy、Shim、Kernel、Hypervisor等组件。

运行在虚拟机内部，负责创建容器环境和进程。

运行在宿主机上，负责协调和Agent的交互。

可选的工具，用于监控容器，去除重复内存，以最大化容器部署密度。

容器管理器调用此组件，该组件提供操控容器的高层接口，提供了CLI。该组件和OCI、CRI-O、Containerd兼容。

运行在宿主机上的进程，为了兼容OCI规范而存在。垫片在宿主机上代表工作负载（运行在虚拟机）处理标准的IO、信号。

使用QEMU 2.11。

QEMU使用Linux内核来启动客户机镜像。 

宿主机必须支持KVM：

apt-get install ubuntu-virt-server

kvm-ok
# INFO: /dev/kvm exists
# KVM acceleration can be used

 如果宿主机本身就是虚拟机，则宿主机的宿主机应当开启嵌套虚拟化：

cat /sys/module/kvm_intel/parameters/nested
# Y 

echo "deb http://download.opensuse.org/repositories/home:/katacontainers:/release/xUbuntu_$(lsb_release -rs)/ /" > /etc/apt/sources.list.d/kata-containers.list
curl -sL http://download.opensuse.org/repositories/home:/katacontainers:/release/xUbuntu_$(lsb_release -rs)/Release.key | sudo apt-key add -
apt update && apt -y install kata-runtime kata-proxy kata-shim

执行下面的命令，检查当前环境是否具备运行Kata的条件：

kata-runtime kata-check

如果一切正常，应当没有错误日志。

创建配置文件：

[Service]
Type=simple
ExecStart=
ExecStart=/usr/bin/dockerd -D --default-runtime runc --add-runtime kata-runtime=/usr/bin/kata-runtime

重启Docker：

systemctl daemon-reload 
systemctl restart docker.service
docker info | grep runtime
# Runtimes: kata-runtime runc

执行下面的命令，以Kata作为Runtime创建容器：

docker run -d --name ubuntu --runtime kata-runtime docker.gmem.cc/ubuntu:16.04 sleep 3600

容器运行起来之后，你可以看到QEMU进程qemu-lite-system-x86_64。 

Kata是OCI兼容的容器运行时，不能直接和K8S的CRI API交互。因此，想集成K8S，先要安装一个支持CRI - OCI适配的CRI实现，可供选择的有 CRI-O、 CRI-containerd。

CRI-O是基于OCI的CRI实现。 

skopeo是一个命令行工具，支持对容器镜像、仓库进行各种操作。skopeo支持OCI镜像以及Docker v2镜像格式。skopeo可以和支持API v2的镜像仓库进行交互。

和Docker不同，skopeo不需要运行守护程序即可完成以下操作：

1. 在多种存储机制之间拷贝镜像，例如从一个仓库拷贝到另外一个
2. 查看远程镜像的属性，包括它的层，而不需要预先拉取到本地
3. 从仓库中删除镜像
4. 支持向仓库提供身份凭证信息

执行下面的命令安装：

add-apt-repository ppa:projectatomic/ppa
apt-get update
apt-get install skopeo-containers -y 

这是一个轻巧的CLI工具，可以基于OCI规范产生和运行容器进程。

pushd /usr/bin
wget https://github.com/opencontainers/runc/releases/download/v1.0.0-rc6/runc.amd64
mv runc.amd64 runc
chmod +x runc

CRI-O可以支持多种运行时，可以将runc作为默认运行时，让kata作为不受信任负载的运行时。

crio没有提供预编译的二进制文件，你需要自己编译。首先安装Go的SDK并初始化工作区：

wget https://dl.google.com/go/go1.11.4.linux-amd64.tar.gz
tar zxf g1.11.4.linux-amd64.tar.gz
mv go $HOME/Go/sdk/1.11.4
mkdir -p $HOME/Go/workspaces/default
export GOROOT=$HOME/Go/sdk/1.11.4
export GOPATH=$HOME/Go/workspaces/default
export PATH=$PATH:$GOROOT/bin

然后构建crictl：

go get github.com/kubernetes-incubator/cri-tools/cmd/crictl
cd $GOPATH/src/github.com/kubernetes-incubator/cri-tools
git checkout release-1.12
make
make install

然后从源码构建crio： 

apt install -y libglib2.0-dev libseccomp-dev  libgpgme11-dev  libdevmapper-dev make git gcc go-md2man

go get -d github.com/kubernetes-sigs/cri-o
cd $GOPATH/src/github.com/kubernetes-sigs/cri-o
git checkout release-1.12
make install.tools
make
make install

# 生成并安装配置文件
make install.config

修改配置文件中的以下字段：

[crio.image]
registries = ['docker.io']

[crio.runtime]
manage_network_ns_lifecycle = true
# 不受信任的负载用Kata运行
runtime_untrusted_workload = "/usr/bin/kata-runtime"
# 默认认为负载是受信任的
default_workload_trust = "trusted"
log_level = "info"

注意，CRI-O默认使用的运行时是runc。

创建Systemd服务定义：

Description=OCI-based implementation of Kubernetes Container Runtime Interface
Documentation=https://github.com/kubernetes-sigs/cri-o

[Service]

Environment="HTTP_PROXY=http://10.0.0.1:8087"
Environment="HTTPS_PROXY=http://10.0.0.1:8087"

ExecStart=/usr/local/bin/crio
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

systemctl daemon-reload
systemctl enable crio
systemctl start crio

使用下面的命令检测crio是否正常运行：

crictl --runtime-endpoint unix:///var/run/crio/crio.sock version

# Version:  0.1.0
# RuntimeName:  cri-o
# RuntimeVersion:  1.14.0-dev
# RuntimeApiVersion:  v1alpha1

--container-runtime=remote --runtime-request-timeout=15m --container-runtime-endpoint=unix:///var/run/crio/crio.sock

重新加载配置，重启kubelet后，在K8S主节点上可以看到容器运行时变为cri-o：

NAME       AGE     VERSION   OS-IMAGE             KERNEL-VERSION           CONTAINER-RUNTIME
jade       6m18s   v1.12.1   Ubuntu 16.04.1 LTS   4.4.0-66-generic         cri-o://1.14.0-dev
# xenial-101 77d     v1.12.1   Ubuntu 16.04.3 LTS   4.13.0-41-generic        docker://1.13.1
# xenon      9d      v1.12.1   Ubuntu 16.04.4 LTS   4.15.0-34-generic        docker://18.6.1

使用如下命令尝试拉取必备的镜像：

crictl pull docker.gmem.cc/k8s/kube-apiserver:v1.12.1          
crictl pull docker.gmem.cc/k8s/kube-controller-manager:v1.12.1 
crictl pull docker.gmem.cc/k8s/kube-scheduler:v1.12.1          
crictl pull docker.gmem.cc/k8s/kube-proxy:v1.12.1              
crictl pull docker.gmem.cc/k8s/pause:3.1                       
crictl pull docker.gmem.cc/k8s/etcd:3.2.24
crictl pull docker.gmem.cc/k8s/coredns:1.2.2
crictl pull k8s.gcr.io/pause:3.1
crictl pull docker.gmem.cc/calico/node:v3.2.3
crictl pull docker.gmem.cc/calico/cni:v3.2.3
crictl pull docker.gmem.cc/calico/kube-controllers:v3.2.3

kube-proxy等Daemonset管理的Pod会自动在所有节点上运行，你可以使用如下命令查看本机运行的Pod：

# 查看Pod
crictl pods
# POD ID              CREATED             STATE               NAME                             NAMESPACE           ATTEMPT
# 6914a958097c2       25 minutes ago      Ready               speaker-qkng4                    metallb-system      0

# 查看容器
crictl ps
# CONTAINER ID        IMAGE      CREATED             STATE               NAME

如果默认运行时是runc，则此时看不到Kata容器：

kata-runtime list
# NONE

我们可以创建一个标注为“不受信任”的Pod，这样CRI-O将会以Kata作为运行时来运行它：

kubectl label node jade k8s.gmem.cc/allow-untrusted-workload=true 

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: ubuntu-untrusted
  annotations:
    io.kubernetes.cri-o.TrustedSandbox: "false"
spec:
  nodeSelector:
    k8s.gmem.cc/allow-untrusted-workload: "true"
  containers:
  - args:
    - -c
    - sleep 365d
    command:
    - /bin/sh
    image: docker.gmem.cc/ubuntu:16.04
    imagePullPolicy: Always
    name: ubuntu
EOF

上述Pod运行起来后，你可以在节点上看到Kata容器、QEMU进程。 

[crio]

# 注意，存储配置默认从 /etc/containers/storage.conf 读取
# 根目录，包括容器、镜像都存放在此
root = "/var/lib/containers/storage"
# 状态信息的根目录
runroot = "/var/run/containers/storage"
# 存储驱动
storage_driver = "overlay"

# 使用文件锁还是内存锁
file_locking = true

# 文件锁的位置
file_locking_path = "/run/crio.lock"


# kubelet/gRPC接口相关配置
[crio.api]

# 守护程序监听的AF_LOCAL接口
listen = "/var/run/crio/crio.sock"
# 流服务器监听的IP地址
stream_address = "127.0.0.1"
# 流服务器监听的端口
stream_port = "0"
# 流服务器是否启用TLS
stream_enable_tls = false
# 流服务器TLS证书配置
stream_tls_cert = ""
stream_tls_key = ""
stream_tls_ca = ""


# 使用哪些OCI运行时，如何管理这些OCI运行时
[crio.runtime]
# 管理网络命名空间的生命周期
manage_network_ns_lifecycle = true

# 为每个容器设置的默认ulimit，如果不指定从CRI-O守护进程继承
# 示例：nofile=1024:2048
default_ulimits = [
]

# 运行受信任工作负载的OCI运行时的路径，未来该属性将废弃
runtime = ""

# 默认运行时的名称，此名称定义在运行时映射配置项（Runtime mapping）中
default_runtime = "runc"

# 未来该属性将废弃，使用crio.runtime.runtimes代替此属性
# 此属性相当于在crio.runtime.runtimes中创建一个名为untrusted的运行时处理器
runtime_untrusted_workload = "/usr/bin/kata-runtime"

# 未来该属性将废弃 
# 工作负载的默认受信任级别，默认值trusted，可选untrusted。CRI-O根据信任级别选择适当的运行时
# kubelet可以将工作负载标记为不受信任或受信任
default_workload_trust = "trusted"

# 用于监控OCI运行时的公共二进制文件位置
conmon = "/usr/local/libexec/crio/conmon"

# 公共环境变量
conmon_env = [
        "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
]

# 使用使用SELinux来隔离工作负载
selinux = false

# 默认的安全配置文件位置
seccomp_profile = "/etc/crio/seccomp.json"

# CRI-O默认的AppArmor配置的名称
apparmor_profile = "crio-default"

# 使用的CGroups管理机制
cgroup_manager = "cgroupfs"

# 容器默认特性列表
default_capabilities = [
        "CHOWN",
        "DAC_OVERRIDE",
        "FSETID",
        "FOWNER",
        "NET_RAW",
        "SETGID",
        "SETUID",
        "SETPCAP",
        "NET_BIND_SERVICE",
        "SYS_CHROOT",
        "KILL",
]

# 容器默认sysctls列表
default_sysctls = [
]

# 额外的设备列表
# 格式：device-on-host:device-on-container:permissions，例如/dev/sdc:/dev/xvdc:rwm
additional_devices = [
]

# OCI钩子目录，其中的钩子会自动执行
hooks_dir = [
]


# 每个容器默认挂载的文件
default_mounts_file = ""

# 容器中最大允许的线程数量
pids_limit = 1024

# 容器日志的最大尺寸
log_size_max = -1

# 容器退出文件存放位置
container_exits_dir = "/var/run/crio/exits"

# 容器Attach套接字的存放位置
container_attach_socket_dir = "/var/run/crio"

# 如果设置为true则所有容器运行在只读模式
read_only = false

# 日志输出级别
log_level = "info"

# 到宿主机的UID映射，格式containerUID:HostUID:Size，逗号分隔
uid_mappings = ""
# 到宿主机的UID映射，格式containerGID:HostGID:Size，逗号分隔
gid_mappings = ""

# 认为终止容器操作超时的最小时间
ctr_stop_timeout = 0

# 容器运行时映射表
[crio.runtime.runtimes.runc]
  runtime_path = "/usr/bin/runc"
[crio.runtime.runtimes.untrusted]
  runtime_path = "/usr/bin/kata-runtime"


# 管理OCI镜像的配置
# 默认从/etc/containers/registries.conf读取镜像仓库信息
[crio.image]
# 拉取镜像使用的默认传输协议
default_transport = "docker://"

# K8S pause镜像
pause_image = "k8s.gcr.io/pause:3.1"
pause_command = "/pause"

# 执行一个策略文件，此文件用于决定是否信任拉取的镜像
# 默认策略，例如/etc/containers/policy.json通常足够
signature_policy = ""

# 拉取非全限定名称的镜像时，从什么仓库拉取
registries = ['docker.io']


# CNI配置
[crio.network]
# CNI配置文件所在目录
network_dir = "/etc/cni/net.d/"
# CNI二进制文件所在目录
plugin_dir = "/opt/cni/bin/"

crictl pull --creds USERNAME[:PASSWORD] NAME[:TAG|@DIGEST]

crictl inspecti  docker.gmem.cc/ubuntu:16.04

crictl info 4ae949f913362 
{
  "status": {
    "conditions": [
      {
        "type": "RuntimeReady", # 运行时状态
      },
      {
        "type": "NetworkReady", # 网络状态
      }
    ]
  }
}

crictl exec -it 4ae949f913362 sh

crictl runp pod-config.yaml

The post Kata Containers学习笔记 appeared first on 绿色记忆.

CoreOS是一个轻量级的Linux操作系统，CoreOS的自动化、安全性、可扩容性特征，让其非常适用于集群化的部署场景。

与其它的发行版不同，CoreOS没有包管理器，它倾向于在容器（例如Docker）中运行应用程序。CoreOS对流行的容器系统提供了开箱即用的支持。

CoreOS可以在云服务（例如EC2、GCE）、虚拟化平台（VMware、OpenStack、KVM）、裸金属值上运行。

这是CoreOS提供的新的VM初始化机制，用于代替cloud-config。

Ignition能够执行磁盘分区、分区格式化、写入文件、配置用户、配置网络、创建RAID阵列等初始化操作。Ignition的运行时机非常的早，它在systemd启动之前、任何永久存储挂载之前即被调用。

在VM第一次（也仅仅是第一次）启动时，Ignition会从文件系统、URL、Hypervisor bridge读取JSON格式的配置文件，并将配置应用到VM。

即使是学习阶段，也最好创建3台CoreOS的集群，那样更容易认识CoreOS的特性。为了让CoreOS集群正常启动，你需要提供“点火配置”（ Ignition config ），或者通过user_data提供一个cloud-config。

本节记录基于libvirt创建CoreOS客户机的详细过程。

我们可以下载CoreOS官网提供的qcow2格式的镜像，此镜像适用于QEMU：

wget https://stable.release.core-os.net/amd64-usr/current/coreos_production_qemu_image.img.bz2

下载完毕后，解压镜像到

/home/alex/Vmware/KVM/coreos-20/vda.qcow2

为了配置CoreOS实例，我们需要在宿主机上创建一个目录，此目录中包含一些配置信息。此目录最终映射将为客户机上的一个文件系统。执行以下命令：

mkdir -p /home/alex/Vmware/KVM/coreos-20/cloud-config/openstack/latest/
touch /home/alex/Vmware/KVM/coreos-20/cloud-config/openstack/latest/user_data

user_data是cloud config格式的配置文件，它提供了客户机运行时所需要的定制化信息。我们至少需要在其中配置SSH Key以便（初次）登录到CoreOS中：

#cloud-config

ssh_authorized_keys:
 - ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIBlsU4YrAi ... EIokU+jOd0MrsnOwQn9wJbov8Xhyw==

我们可以使用类似下面的命令来定义CoreOS的Domain：

virt-install --import --name coreos-20 --ram 1024 --vcpus 1
             --disk path=/home/alex/Vmware/KVM/coreos-20/vda.qcow2,format=qcow2,bus=virtio 
             --filesystem /home/alex/Vmware/KVM/coreos-20/cloud-config/,config-2,type=mount,mode=squash

或者，在常规的Domain XML配置文件中，添加devices的子元素：

<filesystem type='mount' accessmode='squash'>
    <source dir='/home/alex/Vmware/KVM/coreos-20/cloud-config/'/>
    <target dir='config-2'/>
</filesystem>

默认情况下，CoreOS会尝试通过DHCP来获得自身的网络配置，我们可以在启动Domain后立即查看控制台，CoreOS的IP地址会打印在上面。执行下面的命令登录到CoreOS：

ssh -i path-to-key core@ip-of-coreos

登录成功后，你可以为core用户设置密码，或者执行其它操作。 

<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
    <name>coreos-20</name>
    <memory unit='MiB'>1024</memory>
    <vcpu placement='static'>1</vcpu>
    <os>
        <type arch='x86_64' machine='pc'>hvm</type>
    </os>
    <features>
        <acpi/>
    </features>
    <cpu mode='custom' match='exact'>
        <model fallback='allow'>SandyBridge</model>
    </cpu>
    <clock offset='utc'/>
    <on_poweroff>destroy</on_poweroff>
    <on_reboot>restart</on_reboot>
    <on_crash>destroy</on_crash>
    <devices>
        <emulator>/usr/bin/qemu-system-x86_64</emulator>
        <disk type='volume' device='disk'>
            <driver name='qemu' type='qcow2'/>
            <source pool="default" volume="coreos-20.qcow2" />
            <target dev='vda' bus='virtio'/>
            <boot order='1'/>
        </disk>
        <filesystem type='mount' accessmode='squash'>
            <source dir='/home/alex/Vmware/libvirt/mount/coreos-base/cloud-config/'/>
            <target dir='config-2'/>
        </filesystem>
        <controller type='usb' index='0'/>
        <controller type='pci' index='0' model='pci-root'/>
        <interface type='network'>
            <mac address='DE:AD:BE:EF:00:20'/>
            <source network='default'/>
            <model type='virtio'/>
        </interface>
        <serial type='pty'>
            <target port='0'/>
        </serial>
        <console type='pty'>
            <target type='serial' port='0'/>
        </console>
        <input type='mouse' bus='ps2'/>
        <input type='keyboard' bus='ps2'/>
        <memballoon model='virtio'/>
    </devices>
</domain>

当前推荐的配置CoreOS的方式是Ignition，但是目前libvirt没有对Ignition的直接支持，需要引入QEMU特有的配置片断。

Ignition配置为JSON格式，示例：

{
  "ignition": {
    "config": {},
    "timeouts": {},
    "version": "2.1.0"
  },
  "networkd": {},
  "passwd": {
    "users": [
      {
        "name": "core",
        "sshAuthorizedKeys": [
          "ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIBlsU4YrAif8Oh4Qdcq1SuF+CbPdr5T3DE3zzeYGG8nkcDMt/9dEjT8eHTMW+4BzCoIfYrIWIprJoykMnhZONBXnoXc/541tqU6MqF0ZRF0QlzSq6VLLLebG3zz+avdJSNLMAvolCLczP536EIokU+jOd0MrsnOwQn9wJbov8Xhyw=="
        ]
      }
    ]
  },
  "storage": {
    "files": [
      {
        "filesystem": "root",
        "group": {},
        "path": "/etc/hostname",
        "user": {},
        "contents": {
          "source": "data:,coreos-21",
          "verification": {}
        }
      }
    ]
  },
  "systemd": {}
}

libvrit Domain配置示例：

<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
    ...
    <qemu:commandline>
    	<qemu:arg value="-fw_cfg"/>
    	<qemu:arg value="name=opt/com.coreos/config,file=/home/alex/Vmware/libvirt/mount/coreos-base/provision.ign"/>
  </qemu:commandline>
</domain>

注意：QEMU 2.0版本不支持 -fw_cfg，手工构建最新版本可以支持。 

The post CoreOS知识集锦 appeared first on 绿色记忆.

Docker是一个容器化软件，所谓容器化即操作系统级别的虚拟化（Operating-system-level virtualization）。比起硬件虚拟化：

1. 容器更加轻量，它不需要运行独立操作系统，因而减少了磁盘（操作系统文件占用GB+空间）、CPU（进程调度、硬件模拟等额外消耗）等基础资源的消耗，可扩容性更强
2. 容器性能更高，虚拟硬件导致的低性能问题不复存在
3. 容器启动非常迅速（小于1秒），普通VM启动时间可能需要1分钟
4. 更加适合部署松耦合、分布式、弹性的微服务

容器化软件允许在同一个操作系统内核下存在多个相互隔离的用户空间实例，这些实例即被称为容器（Container）。从这些容器的所有者/用户的角度来看，它们就像是一个独立的服务器一样。除了隔离机制之外，容器化软件通常提供资源管理功能，限制一个容器的活动对其它容器的影响。

内核中用于支持容器化的特性：

1. 名字空间机制，用于实现容器的隔离。名字空间包括：
   1. pid名字空间，不同空间中的PID可以重复
   2. net名字空间，管理多个网络协议栈的实例
   3. ipc名字空间，管理和访问IPC资源
   4. mnt名字空间，管理文件系统的挂载点
2. 控制组（Cgroups），用于控制容器的资源用量
3. UnionFS，联合文件系统

构建（Build）、分发（Ship）、运行（Run）是Docker提出的宣传口号，它的目标就是高效的完成这三件事，提高开发、测试、运维的效率：

1. Docker将应用程序和它的运行环境（例如依赖、库）打包到一起，屏蔽不同运行环境的差异，实现可移植部署
2. Docker让应用程序在一个被隔离的容器中运行，多个应用程序可以依赖相互冲突的库却不相互干扰（尽管它们运行在单个内核中）

下图阐述了Docker和硬件虚拟化的区别：

从用户的角度来看，使用Docker的典型工作流如下：

1. 将应用程序代码及其依赖纳入到Docker容器中
   1. 编写一个Dockerfile，描述执行环境，并拉取代码
   2. 如果应用程序依赖于外部应用（例如MySQL、Redis），你需要在某个仓库（例如Docker Hub）中找到它们。某些收费的外部应用可以在Docker Store中找到
   3. 在Docker Compose file中引用应用程序，以及上面的那些外部应用，让他们能够同时运行
   4. 利用Docker Machine，在一个虚拟主机上构建、运行你的容器
2. 如果需要，为你的解决方案配置网络、存储
3. 可选的，上传你的构建结果到仓库（私有、Docker官方），与团队成员协作
4. 如果出现扩容（scale）需求，考虑使用Swarm集群，通过Universal Control Plane你可以方便的管理Swarm集群
5. 最终，利用Docker Cloud将容器镜像部署到自有服务器或者云上

本章主要介绍Ubuntu 14.04 LTS下安装、配置Docker的步骤。

你需要安装64bit的操作系统，内核的最低版本是3.10。为了支持aufs存储驱动，最好安装额外的内核包：

sudo apt-get update
sudo apt-get install linux-image-extra-$(uname -r) linux-image-extra-virtual

添加Docker项目的APT源：

sudo echo  "deb https://apt.dockerproject.org/repo ubuntu-trusty main" > /etc/apt/sources.list.d/docker.list
# 添加GPG Key
sudo apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys 58118E89F3A912897C070ADBF76221572C52609D
sudo apt-get update
# 可以查看当前系统支持的Docker引擎版本
apt-cache policy docker-engine

安装Docker引擎并启动Docker守护程序：

sudo apt-get install docker-engine
sudo service docker start

验证安装是否成功：

# 通知Docker引擎，将hello-world镜像载入到新建的容器中
docker run hello-world

# 执行下面的命令显示系统中容器的列表
docker ps -a
# 执行下面的命令显示系统中镜像的列表
docker images

上述命令将下载一个测试目的的Docker镜像，并在一个容器中运行。该镜像会打印一条消息，然后退出。 

执行下面的命令，来升级或者删除Docker：

# 升级
sudo apt-get upgrade docker-engine

# 删除
sudo apt-get purge docker-engine
sudo apt-get autoremove --purge docker-engine
# 上面的命令不会删除镜像、容器、卷或者用户创建的配置文件，你需要手工删除：
rm -rf /var/lib/docker

Docker最初是为Linux开发的，在Windows/Mac系统中，你可以借助Docker Machine来运行Docker。

从1.13开始，Windows和Mac具有基于原生虚拟化机制的Docker实现，不再依赖于Docker Machine。在Windows下，Docker基于Microsoft Hyper-V；在Mac下则基于HyperKit。

为Bash添加自动完成支持：

brew install bash-completion
brew tap homebrew/completions

在.bash_profile中添加：

if [ -f $(brew --prefix)/etc/bash_completion ]; then  
    . $(brew --prefix)/etc/bash_completion
fi

添加Docker的自动完成脚本：

pushd /usr/local/etc/bash_completion.d  
ln -s /Applications/Docker.app/Contents/Resources/etc/docker.bash-completion  
ln -s /Applications/Docker.app/Contents/Resources/etc/docker-machine.bash-completion  
ln -s /Applications/Docker.app/Contents/Resources/etc/docker-compose.bash-completion  

执行一些必要的配置，可以让Ubuntu和Docker更好的一起工作。Docker配置文件默认为/etc/default/docker。

Docker的守护程序绑定到Unix套接字（而不是TCP/IP套接字）。默认的，该套接字的所有者是root，其它用户要访问它必须sudo。为此，Docker守护程序总是以root身份运行。

为了避免在调用

docker

执行以下命令：

sudo groupadd docker
sudo usermod -aG docker $USER
# 用户$USER需要重新登录

当运行Docker时，你可能会看到类似下面的消息：

WARNING: Your kernel does not support cgroup swap limit.
WARNING: Yourkernel does not support swap limit capabilities. Limitation discarded.

在主机上启用内存和swap审计，可以避免该消息：

1. 修改

   /etc/default/grub

    ，设置内核选项：
   

   GRUB_CMDLINE_LINUX="cgroup_enable=memory swapaccount=1"

2. 更新GRUB：

   sudo update-grub

    
3. 重新启动系统

注意：启用后，即使不使用Docker，也会消耗额外1%左右的内存、降低10%左右的性能。

如果在Docker的宿主机上使用UFW，你需要额外的配置——由于UFW的默认行为是丢弃所有转发（路由）包，这会导致Docker无法正常工作。执行以下修改：

1. 修改配置文件/etc/default/ufw，设置

   DEFAULT_FORWARD_POLICY="ACCEPT"

    
2. 重新加载配置文件：

   sudo ufw reload

    
3. 允许针对Docker的入站连接：

   sudo ufw allow 2375/tcp

    

Ubuntu及其衍生的桌面版Linux，通常会自动设置/etc/resolv.conf，将127.0.0.1作为默认DNS，同时网络管理器启用dnsmasq，将DNS请求代理给真实的DNS服务器

在这样的配置下，启动Docker容器会导致如下警告：

WARNING: Local (127.0.0.1) DNS resolver found in resolv.conf and containers
can't use it. Using default external servers : [8.8.8.8 8.8.4.4]

出现此错误是因为Docker容器不能使用本地DNS服务器127.0.0.1，因此它默认使用了谷歌的DNS服务器

要避免此警告，依次执行：

1. 修改

   /etc/default/docker

    设置

   DOCKER_OPTS="--dns 10.0.0.1"

    ，其中10.0.0.1替换为你的内网DNS服务器。注意

   --dns

    选项可以指定多次，对应多个备选DNS服务器
2. 重新启动Docker守护程序：

   sudo service docker restart

    

你也可以修改网络管理器配置，/etc/NetworkManager/NetworkManager.conf，禁用dnsmasq：

# 注释掉：
dns=dnsmasq

14.10以下的版本，已经自动通过upstart配置Docker为自启动。15.04版本开始，Ubuntu使用systemd作为启动/服务管理器，你需要执行：

sudo systemctl enable docker 

默认情况下，Docker将/var/lib/docker作为基目录，并在其子目录下存储下载的镜像，以及运行过的容器，可以为Docker序指定选项-g以改变基目录：

DOCKER_OPTS=" -g /home/alex/Vmware/docker" 

你也可以使用符号链接来改变镜像的位置。

国内访问Docker Hub比较缓慢，可以使用DaoCloud提供的Mirror（需要1.3.2+）。注册DaoCloud的账号后，进入仪表盘页面，点击“加速器”链接，在新的页面上会显示类似下面的命令：

curl -sSL https://get.daocloud.io/daotools/set_mirror.sh | sh -s http://0aa2e1e9.m.daocloud.io

以root身份执行上面的命令后，文件/etc/docker/daemon.json被修改，添加以下内容：

{"registry-mirrors": ["http://0aa2e1e9.m.daocloud.io"]}

你也可以手工修改/etc/default/docker文件，设置DOCKER_OPTS，追加：

DOCKER_OPTS= "  --registry-mirror http://0aa2e1e9.m.daocloud.io"

此外，也可以注册阿里云开发者账号，获得自己的Mirror URL。

默认的，当Docker守护程序退出时，所有正在运行的容器被自动关闭。自1.12开始，你可以配置守护程序，让容器在守护程序退出后保持运行状态。

要启用该特性，可以使用选项

sudo dockerd --live-restore

{
    "live-restore": true
}

该特性于Swarm模式不兼容。 

whalesay是Docker官方提供的一个学习用镜像，运行此镜像，可以在屏幕上显示一头鲸和一句话：

# docker/whalesay为镜像名
# cowsay为执行的命令，boo-boo为命令行参数，即鲸说的那句话
docker run docker/whalesay cowsay boo-boo

本节我们以whalesay镜像为基础，学习创建自己的Docker镜像

在前面的章节我们提到过，Dockerfile用于描述镜像如何被构建。创建镜像的第一步就是编写Dockerfile。

新建一个目录作为构建镜像的上下文目录，所谓上下文目录，意味着构建过程所需的全部文件都位于其中：

mkdir mywhalesay
cd mywhalesay

touch Dockerfile

编辑Dockerfile文件，添加以下内容： 

# FROM关键字说明当前镜像基于哪个镜像来构建
FROM docker/whalesay:latest

# RUN关键字用于在构建时执行任意命令，这里安装fortunes，能够随机的输出名人名言
# 能够正常使用apt-get是因为docker/whalesay FROM ubuntu:14.04
RUN apt-get -y update && apt-get install -y fortunes

# CMD关键字用来指定镜像被加载后执行的命令，现在这头鲸会自顾自的引用名言了
CMD /usr/games/fortune -a | cowsay

在上下文执行下面的命令以构建镜像：

docker build -t mywhalesay .

 构建过程中控制台会打印详细过程，说明如下：

# 发送构建上下文给守护程序检查，确保构建需要的文件完备
# Sending build context to Docker daemon 2.048 kB
# 第一步，加载镜像docker/whalesay到临时容器，后续RUN关键字就是在修改此容器
Step 1 : FROM docker/whalesay:latest
 ---> 6b362a9f73eb   # 这里显示的是镜像ID
# 第二步，在临时容器中运行命令，安装新软件，这导致容器的文件系统发生改变，与其镜像变得不同
Step 2 : RUN apt-get -y update && apt-get install -y fortunes
 ---> Running in f8c9dec97efc  # 这里显示的是容器ID
Processing triggers for libc-bin (2.19-0ubuntu6.6) ...
 ---> 17c653933644
# 移除前面的临时容器
Removing intermediate container f8c9dec97efc
# 第三步，固化前面临时容器对docker/whalesay的改变，作为新的镜像fd35a325caf4
# 创建新的临时容器，尝试运行CMD关键字指定的命令
Step 3 : CMD /usr/games/fortune -a | cowsay
 ---> Running in 8ae48258f958  
 ---> fd35a325caf4  # 新的镜像
Removing intermediate container 8ae48258f958
# 构建完毕
Successfully built fd35a325caf4

构建过程不会对上下文目录进行修改，构建好的镜像自动存放到/var/lib/docker目录下。可以运行命令查看：

docker images
# REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
# mywhalesay          latest              c779eaff986e        2 minutes ago       275 MB
# docker/whalesay     latest              6b362a9f73eb        17 months ago       247 MB

 好了，看看这头智慧鲸都说了些什么吧：

docker run mywhalesay

首先你需要注册一个账号， 然后创建一个仓库（Repository），这里的仓库类似于Git仓库，它以你的Docker Hub用户名作为默认的名字空间，例如gmemcc/mywhalesay。

标签（tag）是用于区分镜像变体的一种方法。

利用tag命令，你可以把一个本地镜像关联到Docker Hub仓库。首先，查询镜像的ID：

docker images 
# REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
# mywhalesay          latest              baa64efc0f1d        6 minutes ago       275 MB

为之前构建的本地镜像mywhalesay打标签：

docker tag baa64efc0f1d gmemcc/mywhalesay:latest
# 可以删除本地镜像
docker rmi -f baa64efc0f1d

输入Docker Hub账号密码以登录：

docker login

使用push子命令，可以把本地镜像推送到Docker Hub上的仓库中： 

docker push gmemcc/mywhalesay

推送完毕后，可以到仓库主页去看看Tags选项卡，会出现一个lastest标签。

在运行容器、构建镜像时，只要所需镜像在本地不存在，都会执行pull子命令拉取镜像。你也可以手工的拉取镜像：

docker pull gmemcc/mywhalesay 

为了方便企业内部Docker镜像的管理，你可以搭建Docker私服（registry server）。最简单的私服例子如下：

docker run -d -p 5000:5000 --restart=always -h registry --network local --dns 172.21.0.1  --ip 172.21.0.4 --name registry registry:2
# 如果宿主机是ARM平台，考虑使用镜像 budry/registry-arm
# 否则你会收到错误 docker: no supported platform found in manifest list.

现在，你可以从Docker Hub上拉取镜像，并tag到私服中：

docker pull ubuntu
docker tag ubuntu localhost:5000/ubuntu

然后，推送镜像到私服：

docker push localhost:5000/ubuntu

之后，你可以再把镜像拉取下来：

docker pull localhost:5000/ubuntu

默认情况下，私服中的数据存放在Docker卷中，此卷位于宿主机文件系统中。要改变存放位置，可以指定选项：

--volume /path/on/host:/var/lib/registry

要想其它宿主机能访问私服，最好启用TLS，其配置类似于Web服务器的SSL配置：

# 创建密钥对
openssl genrsa -out zircon.local.key 4096
openssl req -new -x509 -days 3650 -text -key zircon.local.key -out zircon.local.crt

# 把证书复制到特定目录
mkdir -p /etc/docker/certs.d/docker.gmem.cc
sudo cp zircon.local.crt /etc/docker/certs.d/zircon.local\:5000/domain.crt
# 非本机：
scp alex@zircon.local:~/Vmware/docker/registry/certs/zircon.local.crt /etc/docker/certs.d/zircon.local\:5000/domain.crt

# 可选：全局启用证书
cp zircon.local.crt /usr/share/ca-certificates/
# 启用zircon.local的证书
sudo dpkg-reconfigure ca-certificates
# 需要重启服务
sudo service docker restart

# 重新运行私服
docker run -d -p 5000:5000 --restart=always --name registry \
 -v /home/alex/Vmware/docker/registry/certs:/certs \
 -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/zircon.local.crt \
 -e REGISTRY_HTTP_TLS_KEY=/certs/zircon.local.key \
 registry:2

这样，在网络中的机器都可以使用域名zircon.local代替localhost来访问私服了。

Mac版本的Docker目前无法访问自签名的私服，需要配置：

"insecure-registries":["zircon.local"]

只需要注意把cert.pem、chain.pem合并到一起，作为证书即可：

cd /etc/letsencrypt/live/docker.gmem.cc/
cp privkey.pem domain.key
cat cert.pem chain.pem > domain.crt
chmod 777 domain.crt
chmod 777 domain.key 

除了启用TLS，你可能还需要进行用户身份验证。首先，在宿主机上建立一个目录，并生成密码文件：

cd /home/alex/Vmware/docker/registry/
mkdir auth
# 生成密码，输出到宿主机文件
docker run --entrypoint htpasswd registry:2 -Bbn user passwd > auth/htpasswd

然后，运行私服： 

docker run -d -p 5000:5000 --restart=always --name registry \
  -v /home/alex/Vmware/docker/registry/auth:/auth \
  -e "REGISTRY_AUTH=htpasswd" \
  -e "REGISTRY_AUTH_HTPASSWD_REALM=Registry Realm" \
  -e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd \
  -v /home/alex/Vmware/docker/registry/certs:/certs \
  -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/zircon.local.crt \
  -e REGISTRY_HTTP_TLS_KEY=/certs/zircon.local.key \
  registry:2

现在你可以登录到私服了： 

docker login docker.gmem.cc 

要运行容器，首先要获得相应的镜像。运行容器时，如果镜像在本地不存在，Docker会自动到仓库下载。默认的仓库是Docker Hub。执行docker run命令可以启动一个容器：

# 不指定tag，默认使用lastest
docker run ubuntu
# 指定tag
docker run ubuntu:lastest
docker run ubuntu:14.04 

将镜像加载到容器中后，相当于得到一个预装了某些软件的操作系统。例如对于ubuntu镜像，你可以： 

# 像使用普通虚拟机一样使用容器：

# 调用echo命令
docker run ubuntu /bin/echo 'Hello world'

# 交互式的命令行
# -t 在容器内分配Terminal或者伪TTY
# -i 启动一个交互式的连接
docker run -t -i ubuntu /bin/bash

# -d 在后台运行容器（daemonize）。启动后，Docker会输出当前容器的ID
docker run -d ubuntu /bin/sh -c "while true; do echo hello world; sleep 1; done"
# 216dd35d275a6c6e1e548232bdd9db7cab8a6b2f9078367a3c842762dc458c1a

# 查看正在运行的容器，由于容器ID太长，难以记忆，因此Docker会为每一个容器生成一个名字，例如gloomy_bohr。这个名字可以修改
docker ps
# CONTAINER ID IMAGE     COMMAND                  CREATED          STATUS         PORTS    NAMES
# 216dd35d275a  ubuntu   "/bin/sh -c 'while tr"   9 seconds ago    Up 8 seconds            gloomy_bohr

# 查看所有已创建的容器，不管容器是否正在运行
docker ps --all

# 指定容器名称，容器名称必须具有唯一性
docker run --name webserver training/webapp python app.py 

# 查看容器运行日志，打印标准输出
docker logs gloomy_bohr

# 在任何时候，你可以附到一个运行中的容器，grab其标准输入/输出
docker attach gloomy_bohr

# 停止容器。超时容器未停止，则发送SIGKILL信号
docker stop gloomy_bohr

# 启动容器
docker start gloomy_bohr

# 在一个正在运行的容器中执行命令
docker exec gloomy_bohr ping 8.8.8.8
# 连接到容器，交互式的执行命令
docker exec -it ubuntu-16.04

# 查看容器内运行的进程
docker top gloomy_bohr
# 以JSON格式打印容器的详细配置信息
docker inspect gloomy_bohr

# 删除容器
# -f 即使正在运行，也将容器删除
docker rm -f gloomy_bohr

上面的每个docker命令调用，实际上都在使用Docker客户端。Docker是基于Go语言开发的，执行

version

Docker的主要应用场景在服务器端，而后者运行的程序大多是网络应用。这里我们使用training/webapp这个镜像来说明如何在容器中运行Web服务器：

# -P 自动将容器中的监听端口映射到宿主机的某个端口
docker run -d -P --name web training/webapp python app.py
# 执行下面的命令查看端口如何映射
docker ps -l
# PORTS  端口映射情况位于该列
# 0.0.0.0:32769->5000/tcp   宿主机的32769端口映射到容器的5000端口

# -p 手工指定端口映射，宿主机的80端口映射的哦容器的5000端口
docker run -d -p 80:5000 training/webapp python app.py

# 查询端口映射
docker port hungry_payne 5000

# 查看Web应用日志
# -f的效果类似于tail -f
docker logs -f hungry_payne

利用网络驱动（network drivers） ，Docker为容器提供了网络支持。网络驱动主要有两类：bridge、overlay。默认随着Docker引擎一起安装了三个网络：

docker network ls
# NETWORK ID          NAME                DRIVER              SCOPE
# f160b7cc8b94        bridge              bridge              local               
# fc47bb582730        host                host                local               
# 5ac20f3697f3        none                null                local

除非明确指定，新启动的容器总是使用bridge这个网络。 

执行network inspect子命令可以查看一个网络的详细信息，包括它为各连接到的容器分配的IP地址：

执行：

docker network inspect bridge

[
    {
        "Name": "bridge",
        "Id": "f160b7cc8b94b782e5fed8b2e50e72f14ad205917540b1dc464f509f7eb11dec",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.17.0.0/16",
                    "Gateway": "172.17.0.1"
                }
            ]
        },
        "Internal": false,
        /* 连接到此网络的容器的集合 */
        "Containers": {
            "87afe74d233dcd2e6caf2d569c785b0457123d4ad25f1c1bd9850576ba3afd1c": {
                "Name": "web",
                "EndpointID": "e8a0db5f066fd13bc2cb432f375582cb92e445a982a0ed667d26d92adb19550f",
                "MacAddress": "02:42:ac:11:00:02",
                "IPv4Address": "172.17.0.2/16",
                "IPv6Address": ""
            }
        },
        "Options": {
            "com.docker.network.bridge.default_bridge": "true",
            "com.docker.network.bridge.enable_icc": "true",
            "com.docker.network.bridge.enable_ip_masquerade": "true",
            "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
            "com.docker.network.bridge.name": "docker0",
            "com.docker.network.driver.mtu": "1500"
        },
        "Labels": {}
    }
]

要把一个容器从网络中移除，可以执行：

# 把web从网络bridge中移除
docker network disconnect bridge web

要创建一个简单的网络，可以执行：

docker network create -d bridge newbridge

类似的，再不需要时，可以删除自定义网络：

docker network rm newbridge

注意：名为bridge的默认网络不能被删除。

如果不希望容器使用默认网络，可以在运行容器的时候指定--network参数：

docker run -d --network=newbridge --name db training/postgres
# 获得容器的IP地址
docker inspect --format='{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' db

Docker允许在运行时将容器添加到任意多个网络：

docker network connect bridge db

所谓数据卷（Data volumes），是一个或者多个容器中特定的目录，这些目录绕过容器的联合文件系统（UFS，可以将不同物理位置合并mount到Linux目录树的同一位置） ，数据卷的一系列特性有利于数据的持久化、共享：

1. 数据卷在容器被创建时初始化，如果容器使用的基础镜像在数据卷的挂载点上包含数据，则这些数据被拷贝到新初始化的数据卷中。注意：当挂载宿主机目录作为数据卷时，拷贝行为不发生
2. 数据卷可以被多个容器共享，或者被重用
3. 对数据卷的更改是直接进行的
4. 当你升级基础镜像时，对数据卷的修改不被包含其中
5. 即使容器本身被删除，数据卷依然存在，数据卷独立于容器的生命周期

注意：作为挂载点的容器目录，其原有的文件全部不可见，不会进行Overlay。

要添加匿名数据卷，可以在启动容器时指定-v参数：

# 在容器的/webapp位置创建一个匿名数据卷
docker run -d -P --name web -v /webapp training/webapp python app.py

在制作镜像时，你可以用VOLUME指令声明一个或者多个数据卷，任何基于此镜像的容器，自动添加这些数据卷。

匿名数据卷在宿主机上以目录的形式存在，要定位此目录，可以执行inspect子命令：

/* docker inspect web的部分输出 */
"Mounts": [
    {
        "Name": "356707e2ddc02715db78b958b623707c2475f66258c14b68de48f0e29188bc0f",
        /* 在宿主机上的存放位置 */
        "Source": "/mnt/c3d88ac1-b4d5-4cdd-86b4-4255aba9ddb1/docker/volumes/35670b68de.../_data",
        "Destination": "/webapp",
        "Driver": "local",
        "Mode": "",
        "RW": true,
        "Propagation": ""
    }
]

你也可以把任意宿主机目录挂载为数据卷，映射到容器的目录树中，仍然使用-v参数： 

# 宿主机目录/src/webapp被挂载到容器的/webapp
# 容器中的挂载点必须总是指定绝对路径
# 宿主机目录可以指定绝对路径，也可以指定一个名称，Docker引擎依据此名称创建/引用命名卷
docker run -d -P --name web -v /src/webapp:/webapp training/webapp python app.py

上面的例子中，如果容器的基础镜像已经包含了/webapp目录，则它会被宿主机的/src/webapp覆盖，但是容器从基础镜像得到的/webapp中的内容不会被删除，一旦数据卷被卸载，则/webapp中的内容恢复原样。

挂载单个宿主机文件也被支持：

-v ~/.bash_history:/root/.bash_history

除了挂载宿主机的本地目录，你也可以挂载共享存储为数据卷，Docker通过Volume plugins来支持iSCSI、NFS、FC等共享存储。使用共享存储的好处是它们是不依赖于主机的。

你可以在启动容器时，即时的在共享存储上创建命名卷（named volume）：

# --volume-driver 指定卷驱动，可选
# my-named-volume为新创建的卷的名字
docker run -d -P  --volume-driver=flocker   -v my-named-volume:/webapp  
    --name web training/webapp python app.py

或者，先手工创建命名卷，然后引用命名卷：

docker volume create -d flocker -o size=20GB my-named-volume
docker run -d -P -v my-named-volume:/webapp

例子中的flocker是一个专为Docker设计的数据卷管理工具。flocker管理的数据卷可以位于集群中的任何主机上，而不是绑定到某台宿主机。

注意：

1. 命名卷对应/var/lib/docker/volumes/my-named-volume/_data目录。该目录会自动创建
2. 容器A、B共享一个命名卷，则A的写入B可以看到
3. A使用 -v my-named-volume:/data，则data中原有（镜像自带）的文件可以在my-named-volume中看到

数据卷可以挂载为只读：

-v /src/webapp:/webapp:ro #添加:ro后缀

可以参考下面的命令，来备份一个数据卷：

# --volumes-from  引用来自dbstore的数据卷/dbdata
# -v 挂载宿主机当前目录到/backup
# 容器启动后，使用tar命令，将/dbdata的内容压缩，存放到/backup，亦即宿主机的当前目录
# tar完成后，容器停止，备份完毕
docker run --rm --volumes-from dbstore -v $(pwd):/backup ubuntu tar cvf /backup/backup.tar /dbdata

使用类似的方法，可以首先数据卷的恢复。 跨宿主机联用备份/恢复，可以实现数据卷迁移。

默认情况下，容器删除后，其挂载的数据卷会被保留。一般的，你可以指定：当容器被删除后，自动清理匿名卷：

# --rm示意自动清理匿名卷/foo
# 挂载到/bar的命名卷awesone不会被清理
docker run --rm -v /foo -v awesome:/bar busybox top

数据卷可以通过--volumes-from选项被其它容器引用，这种情况下，创建/引用数据卷的全部容器被删除之前，数据卷是无法删除的。要在删除容器时，同时删除数据卷，可以指定-v选项，例如

# 删除db3的同时，删除其使用的数据卷。注意，db3必须是最后一个使用它引用的所有数据卷的容器
docker rm -v db3

如果需要在多个容器之间共享持久化数据，或者期望在非持久化容器中使用持久化数据，最好的方法是创建命名数据卷容器——仅仅为了提供共享数据卷的容器，并在其中挂载数据卷供其它容器引用。

首先创建一个命名的容器，但是不需要它执行任何命令：

# 创建一个名为dbstore的容器，其包含一个数据卷/dbdata
docker create -v /dbdata --name dbstore training/postgres /bin/true
# 注意 -v 非常重要，如果不声明-v，则此容器的目录不会暴露出去
docker run -v /jdk --name jdk docker.gmem.cc/jdk:7u80

然后，你可以利用选项--volumes-from，在其它容器中挂载dbstore的/dbdata目录 ：

docker run -d --volumes-from dbstore --name db1 training/postgres
# 再创建一个容器，与db1共享来dbstore的/dbdata。两个容器的共享卷的挂载路径一致
docker run -d --volumes-from dbstore --name db2 training/postgres

这样启动db1、db2后，如果postgres镜像包含/dbdata目录，它将被来自dbstore的数据卷mask掉，仅dbstore的/dbdata对于db1、db2可见。

选项--volumes-from 可以指定多次，这样你可以联合使用来自多个容器的数据卷。

选项--volumes-from可以通过链式的结构扩展——链条上的后面的容器可以使用前面任意容器声明的数据卷：

# 由于db1使用了dbstore的数据卷/dbdata
# 因此db3也可以使用
docker run -d --name db3 --volumes-from db1 training/postgres

注意，提供数据卷的容器不需要处于运行状态。

多个容器共享一个数据卷时，可能导致数据破坏，这是由并发的写操作导致的。并发写操作可能来自于容器或者宿主机。 

所谓基本镜像（Base image），一般是指没有父镜像的镜像。此类镜像打包一个空白的操作系统。制作基本镜像的步骤依赖于你想打包的Linux发行版。

一般情况下，你可以在这样的Linux操作系统下完成基本镜像的创建——该操作系统就是你希望打包的Linux发行版。

某些工具可以简化镜像的创建，例如Debootstrap可以安装一个Debian/Ubuntu的基本操作系统到一个目录中。使用该工具的示例：

# 下载Ubuntu 16.04（xenial）基本操作系统到xenial目录
sudo debootstrap xenial xenial

# tar -C切换工作目录 -c 创建压缩文件
# 压缩结果通过管道传递给docker import
# import子命令创建一个空白文件系统镜像，然后把Tar的内容导入进去
# ubuntu:16.04 创建一个名为ubuntu的仓库，Tag为16.04
sudo tar -C xenial -c . | docker import - ubuntu:16.04

其它创建基本镜像的脚本，可以参考Create a base image 

scratch是Docker保留的名称，它不是一个镜像，你也不能把任何仓库命名为scratch。scratch可以作为构建基本镜像的起点：

FROM scratch
ADD hello /
CMD ["/hello"]

该主题包含以下关注点：

1. 如何透明的依据体系结构，自动拉取镜像。这个需求可以通过镜像清单（Manifest）满足，清单包含同一功能的镜像（例如Alpine:3.10）对应到多个体系结构的版本。拉取镜像时，不管是什么平台，都使用alpine:3.10这个名字，Docker会自动拉取匹配体系结构的镜像
2. 如何去构建其它体系结构的镜像，这个将是本节的主题

如果你使用了桌面版本的Docker，或者使用高于4.8+内核的Linux，你可以直接在x86_64的机器上，运行各种其它体系结构的镜像。

在Linux上启用Docker与QEMU集成的方式：

docker run --rm --privileged linuxkit/binfmt:v0.8

# 正常情况下，不会报错，并且
ls -1 /proc/sys/fs/binfmt_misc/qemu-*
# 出现：
# /proc/sys/fs/binfmt_misc/qemu-aarch64
# /proc/sys/fs/binfmt_misc/qemu-arm
# /proc/sys/fs/binfmt_misc/qemu-ppc64le
# /proc/sys/fs/binfmt_misc/qemu-riscv64
# /proc/sys/fs/binfmt_misc/qemu-s390x

重启Docker守护进程后，可以看到默认Builder支持多种平台：

docker buildx ls

# BEFORE:
# NAME/NODE DRIVER/ENDPOINT STATUS  PLATFORMS
# default * docker                  
#   default default         running linux/amd64, linux/386


# AFTER:
NAME/NODE DRIVER/ENDPOINT STATUS  PLATFORMS
default * docker                  
  default default         running linux/amd64, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/arm/v7, linux/arm/v6

这是一个Docker CLI插件，可以通过BuildKit进行Docker镜像的构建。使用buildx，你可以为不同体系结构构建镜像，并合并在一个镜像清单中，不需要作Dockerfile或源代码上的变动。

buildx把工作委托给builders：

# 列出现有的builders
docker buildx ls

# 创建本地builder:
docker buildx create --use --name local default
# 注意，docker驱动使用守护进程中的代理设置，但是docker-container不使用。此外由于builder容器
# 不是CLI创建的，因此~/.docker下设置的代理也不会变为容器的环境变量
# 目前支持创建builder时指定代理设置
docker buildx create 
                     # 使用哪种驱动
                     #   docker  使用编译到Docker守护进程中的BuildKit库，体验和原先的docker build相似
                     #   docker-container 在容器中启动BuildKit
                     #   kubernetes
                     --driver docker-container \
                     # 这些代理貌似也没什么价值，sh到builder容器中代理生效。但是Dockerfile中的命令，例如
                     # apk却不会使用这些代理，因此对构建过程没有价值
                     --driver-opt env.HTTP_PROXY=http://10.0.0.1:8088 \
                     --driver-opt env.HTTPS_PROXY=http://10.0.0.1:8088 \
                     --driver-opt network=host   \
                     --driver-opt '"env.NO_PROXY='$NO_PROXY'"'   \
  --use --name proxied default


# 添加远程builder：
docker context create arm --docker "host=tcp://10.0.0.90:2376"
docker context use arm
docker buildx use arm

# 切换使用的builder：
docker buildx use default

要使用buildx发起镜像构建，执行命令：

docker buildx build .

buildx将使用BuildKit引擎进行构建，不需要设置

DOCKER_BUILDKIT=1

buildx支持docker build的所有特性，包括19.03引入的输出配置、内联build缓存、指定目标platform。此外，buildx还支持manifest、分布式缓存、导出为OCI格式等docker build不支持的特性。

buildx可以在不同配置下运行，每个配置称为driver。默认使用编译到Docker守护进程中的BuildKit库，此驱动称为docker，该驱动使用你本地的Docker守护进程，并提供和docker build相似的体验。此外，你还可以使用docker-container驱动，它在容器中启动BuildKit。

驱动docker的输出，自动在docker images列表中可见。对于其它驱动，输出到何处需要

--output

通过创建新的builder实例，可以得到隔离的构建环境（不改变共享的Docker守护进程的状态），在CI中较为有用。 你甚至可以在远程Docker守护进程上创建多个builder，形成builder farm，并随意在这些builder之间切换。

Docker 19.03引入了类似Kubectl的context特性，可以为一个远程Docker守护进程的API端点提供一个名称。对于每个context，buildx会生成一个默认的builder实例。

docker buildx build --platform linux/amd64,linux/arm64 .

执行命令：

docker buildx install

执行

docker buildx uninstall

Docker读取Dockerfile中的指令以构建新的镜像，Dockerfile中的指令说明了镜像应该如何一步步的被构建。

执行

docker build

所谓上下文，是指定PATH（宿主机本地目录）或者URL（Git存储库）中的文件集合。上下文会被递归的处理，即子目录被包含在上下文中。在大部分情况下，最好将空白目录作为上下文，其中仅包含一个Dockerfile和构建过程必备的文件。

要使用上下文中的文件，你必须编写特定的指令，例如COPY。你可以在上下文目录中添加一个

.dockerignore

按照约定，在上下文根目录中的名为Dockerfile的文件被作为“Dockerfile”，但是你可以指定任意文件作为“Dockerfile”：

docker build -f /path/to/a/Dockerfile .

你可以为正在构建的镜像指定仓库（Repository）:标签（tag），如果构建成功，镜像将被存放到相应的仓库:标签：

docker build -t gmemcc/myapp .
# 指定多个仓库/标签也是允许的
docker build -t gmemcc/myapp:1.0.2 -t gmemcc/myapp:latest .

Docker守护程序会逐条的执行Dockerfile中的指令，如果必要，将指令的执行结果提交到正在构建的那个新的镜像中去。在最终输出镜像ID之前，守护程序会自动清理客户端发送的上下文。

需要注意的是，每条指令都是独立的执行的，因此

RUN cd /tmp

为了提高构建的性能，Docker会重用中间的（intermediate ）镜像（所谓缓存）。当使用缓存时，Docker会在控制台打印

Using cache

Dockerfile中只有注释、指令两类元素：

# Comment
INSTRUCTION arguments

指令名称大小写不敏感，通常使用全大写。第一条指令必须是FROM，指定基础镜像。 以#开头的行通常被作为注释看待，除非它是合法的解析器指令（parser directive）。

解析器指令（directive）影响Dockerfile中其它行的处理方式，该指令不会增加额外的层，也不会显示为构建步骤。

解析器指令的语法类似于一种特殊的注释：

# directive=value

解析器指令同样是大小写不敏感的，但是通常都使用全小写。在解析器指令之后，通常留有空白行。编写解析器指令时不得使用行连接符（\）

目前支持的解析器指令包括：

# escape=`

RUN

使用

ENV

$variable_name

${variable_name}

1. ${variable:-word}

    ，如果设置了环境变量variable，表达式的结果是$variable，否则是word

2. ${variable:+word}

    ，如果设置了环境变量variable，表达式的结果是word，否则是空串

以下指令支持变量替换：ADD、COPY、ENV、EXPOSE、LABEL、USER、WORKDIR、VOLUME、STOPSIGNAL。在1.4+，当ONBUILD与前述指令一起使用时，也支持环境变量。

注意：环境变量的值在同一个指令中保持不变，考虑下面的片断：

ENV abc=hello
ENV abc=bye def=$abc   # def值为hello而不是bye
ENV ghi=$abc           # ghi值为bye

Docker客户端发送上下文到守护程序之前，会读取上下文根目录下名为.dockerignore的文件。如果此文件存在，则客户端会依据其中声明的规则来排除掉上下文中的部分文件或者目录。使用.dockerignore可以避免过多的、敏感的文件到守护程序，并被ADD/COPY命令复制到镜像中。

此文件中的每行是一个UNIX glob风格的匹配Pattern，上下文根目录被作为此Pattern的根目录，下面是一些示例：

指令格式：

FROM <image>
FROM <image>:<tag>
FROM <image>@<digest>

# --platform  如果image是多平台的镜像，则此参数选择该镜像的特定平台版本
#             默认自动选择匹配构建目标平台的版本

# AS 为该build stage命名，名字可以被后续的stage引用
FROM [--platform=<platform>] <image> [AS <name>]

用于指定正在构建镜像的Base镜像：

1. 该指令必须是Dockerfile中第一个非注释指令
2. 该指令可以在一个Dockerfile中出现多次，用于构建多个镜像
3. tag、digest可选， 如果不指定，自动使用latest 

一个Dockerfile中可以包含多个FROM指令，这叫多Stage构建。下面是一个例子：

ARG ARCH

# 第一个stage，构建出二进制文件
FROM golang:1.13 as builder
WORKDIR /workspace
RUN CGO_ENABLED=0 GOOS=linux GOARCH=$ARCH GO111MODULE=on go build -a -o pause pause.go

# 第二个stage，构建出镜像
FROM docker.gmem.cc/tcnp/alpine-${ARCH}:3.11
WORKDIR /
#    用名字来引用前面的stage，复制出其中的文件
COPY --from=builder /workspace/pause .
ENTRYPOINT ["/pause"]

如上面的例子所示，FROM中可以使用在第一个FROM指令之前出现的ARG中定义的构建时变量。

指令格式：

MAINTAINER <name>

该指令具有两种格式：

# shell格式，command在Shell中运行，默认/bin/sh -c或者 cmd /S /C
RUN <command>
RUN ["executable", "param1", "param2"]

# 示例：
RUN ["/bin/bash", "-c", "echo hello"]

该指令在当前intermediate镜像之上新建一层，并在其中执行任意命令，然后提交结果。提交结果后形成的新intermediate镜像被下一个指令使用。

运行RUN指令时触发分层（Layering）符合Docker的核心理念——提交（Commit）操作想对廉价，并且可以从镜像历史的任意位置（任意一层）创建容器。分层也是构建过程中镜像缓存的基础。

使用exec格式可以避免Shell字符串相关的陷阱，也可以在Base镜像中没有/bin/sh程序的情况下执行命令。使用exec格式时需要注意：

1. 由于exec格式不调用Shell，因此也不会发生变量替换：
   

   # $HOME不会被替换
   RUN [ "echo", "$HOME" ]
   # $HOME会被替换，因为虽然是exec格式，但是它调用了sh
   RUN [ "sh", "-c", "echo $HOME" ] 

2. exec指令的参数必须是规范化的JSON数组，所以：
   1. 字符串必须使用双引号包围
   2. 字符串中的反斜杠必须JavaScript语法转义，即

      \\

        

使用shell格式时，你可以使用

\

RUN指令导致的镜像缓存不会自动失效，要禁用缓存，可以在构建时指定

--no-cache

可以用SHELL指令，设置shell格式的RUN指令所使用的Shell程序，其它几个具有exec格式/shell格式区分的指令，也受到SHELL指令的影响。

该指令具有三种格式：

# exec格式，推荐的格式
CMD ["executable","param1","param2"]
# 用作ENTRYPOINT的默认参数
CMD ["param1","param2"]
# shell格式
CMD command param1 param2

Dockerfile中仅能包含一个CMD指令， 如果指定了多个CMD指令则仅最后一个有效。该指令的主要意图是为执行容器（executing container）提供默认值（defaults），这些默认值可以包含一个可执行文件，与ENTRYPOINT指令联用时，则仅仅包含执行选项。

使用CMD指令时要注意：

1. CMD不会在构建阶段做任何事情
2. 如果用CMD为ENTRYPOINT提供默认参数，则这两个指令的参数均为规范化的JSON数组
3. exec、shell格式调用的注意点，参考RUN指令

如果使用了CMD指令，并且运行容器时没有指定需要执行的命令，则CMD中的命令会被执行。要让容器每次都运行同一个程序，应当联合使用ENTRYPOINT、CMD。

指令格式：

LABEL <key>=<value> <key>=<value> <key>=<value> ...

该指令为镜像添加元数据（metadata），每个标签是一个键值对。如果需要为镜像添加多个标签，最好在单个LABEL指令中完成。下面是一些示例：

# 如果键/值中包含空格，可以用引号包围
LABEL "Author Name"="Alex Wong"
# 可以使用反斜杠跨行
LABEL description="Hello \
There !"

镜像会继承来自FROM镜像的标签，如果当前镜像的某个标签的键与FROM镜像冲突，则当前的覆盖FROM的。 

使用

docker inspect

指令格式：

EXPOSE <port> [<port>...]

该指令声明容器在运行时侦听的端口。该指令并不会让容器和宿主机之间发生端口映射，要真正映射（发布）端口，必须在创建容器时使用选项：

1. 使用-p参数运行镜像，指定发布的端口范围
2. 使用-P参数，发布所有EXPOSE声明的端口

该指令支持两种格式：

# 为单个变量（key）设置单个值（value）。第一个空格之后的全部内容被作为值看待，即使其中包含空格、引号
ENV <key> <value>
# 允许设置多个环境变量
ENV <key>=<value> ...

设置构建过程、运行期间均可见的环境变量，这些环境变量对任何后代Dockerfile都可用。

部分Dockerfile指令或者指令的某种形式，支持引用环境变量，语法和Bash一致。

在运行期间，可以使用docker inspect查看环境变量。在命令行中，可以使用

--env <key>=<value>

 该指令支持两种格式：

# src是上下文中的目录或者远程URI；dest为镜像中的目录
ADD <src>... <dest>
# 用于路径中包含空格的情况
ADD ["<src>",... "<dest>"]

拷贝本地目录、文件或者远程文件URI，将它们加入到容器文件系统的dest位置。注意以下几点：

1. 可以指定多个src，src中可以包含*、?等通配符
2. 如果src是目录、文件，必须指定相对于上下文根的相对路径，src目录/文件必须位于上下文内部。/something、../something均非法
3. 当src是目录时，其内部所有内容，包括文件系统元数据都被拷贝。但是目录本身不被拷贝
4. 当src是一个本地压缩文件时，它被解压为一个目录，然后拷贝到dest
5. 当src是本地目录（包括解压后的压缩文件）时，覆盖到dest的行为类似于tar -x
6. 当src是远程URI时：
   1. 如果dest以/结尾，则文件名从URI中推定，保存为<dest>/<filename>
   2. 如果dest不以/结尾，则文件保存为dest
7. dest指定容器中的绝对路径。如果使用相对路径，则相对于WORKDIR
8. 当dest以/结尾时，被看作目录，否则看作一般文件。如果dest不存在，会被自动创建
9. 容器中所有的新文件，以UID=GID=0创建
10. 如果src为远程URI，则dest的模式被设置为600。如果通过HTTP协议获取远程文件，则Last-Modified头用于设置dest中文件的mtime
11. mtime不会影响缓存判断
12. 当通过stdin读取Dockerfile并构建时：

    docker build - < somefile

     ，由于没有构建上下文，因此ADD指令必须使用基于URI的src。如果somefile是一个压缩包（tar.gz），则压缩包中根目录被作为构建上下文，而根目录中须有Dockerfile文件
13. 由于ADD不支持身份认证，因此远程URI需要身份验证时，你必须使用RUN wget/curl代替ADD
14. 如果src的内容发生变化，ADD会导致所有后续指令对应的Layer缓存失效

示例：

# 拷贝上下文根目录中所有hom开头的文件到镜像的/mydir/目录下
ADD hom* /mydir/
# 拷贝上下文目录中home.txt之类的文件，e可以是任何单字符
ADD hom?.txt /mydir/

# 拷贝到相对路径 $WORKDIR/relativeDir/下
ADD test relativeDir/

该指令支持两种格式：

COPY <src>... <dest>
# 用于路径中包含空格的情况
COPY ["<src>",... "<dest>"]

拷贝文件或者目录到容器文件系统中。 注意点类似于ADD，但是COPY不理解远程URI也不处理压缩文件。

该指令支持两种格式：

# 推荐的exec格式，参数以JSON数组传递。该方式不会调用Shell命令，因此不会发生参数替换等行为
ENTRYPOINT ["executable", "param1", "param2"]
# shell格式，阻止传参。可以使用环境变量。容器运行时调用/bin/sh -c "command param1 param2"
ENTRYPOINT command param1 param2

使用入口点，可以如同使用可执行文件那样运行一个镜像。docker run时，镜像名后面的所有参数，都作为参数传递给ENTRYPOINT指定的命令/可执行文件，并且覆盖CMD中指定的默认参数。当镜像名和可执行文件名一致的时候，dock run看起来就好像在执行一个文件，而不是运行镜像。

shell格式的调用，阻止CMD指定的默认参数和dock run指定的参数。但是这种格式下可执行文件将作为/bin/sh -c的子命令运行，这导致可执行文件的PID不是1并且不能接收UNIX信号。你的可执行文件将无法接收docker stop发送来的SIGTERM信号。

如果该指令使用多次，则仅仅最后一个被使用。

你可以使用

--entrypoint

# 以命令bash作为入口点，覆盖默认的入口点，将--version作为bash的参数
docker run -it --rm  --entrypoint bash docker.gmem.cc/maven:3.5.2 --version

使用该格式，可以方便的设置容器执行的默认命令及其稳定的默认参数：

ENTRYPOINT ["top", "-b"]

然后，可以联用CMD指令，设置可覆盖的默认参数：

CMD ["-c"]

下面的例子，在前台（PID为1）运行Apache服务器：

FROM debian:stable
RUN apt-get update && apt-get install -y --force-yes apache2
EXPOSE 80 443
VOLUME ["/var/www", "/var/log/apache2", "/etc/apache2"]
# -D FOREGROUND 不去fork出子进程
ENTRYPOINT ["/usr/sbin/apache2ctl", "-D", "FOREGROUND"]

你可以使用任何脚本作为入口点可执行程序的启动脚本，为了确保底层可执行文件能够接收UNIX信号，必须使用exec命令替换进程：

ENTRYPOINT ["/usr/bin/start-postgres.sh"]

#!/bin/bash
set -e
# 如果第一个参数是postgress，则启动postgress服务
if [ "$1" = 'postgres' ]; then
    # 初始化，改变目录所有权
    chown -R postgres "$PGDATA"
    # 初始化数据库
    if [ -z "$(ls -A "$PGDATA")" ]; then
        gosu postgres initdb
    fi
    # 使用exec、管理员权限运行postgres。exec确保postgres进程PID=1，能够接收UNIX信号
    exec gosu postgres "$@"
fi
# 否则，运行参数指定的程序
exec "$@"

如果需要进行清理工作，可以在入口点脚本中编写trap语句：

# 捕获多种信号，然后执行引号中的脚本，停止Apache服务
trap "stopping apache /usr/sbin/apachectl stop" HUP INT QUIT TERM
# 在后台启动Apache服务，这种服务无法接收信号
usr/sbin/apachectl start
echo "Press ENTER to exit"
read
# 回车后，也可以停止Apache服务
echo "stopping apache"
/usr/sbin/apachectl stop

这种方式指定的入口点，将在Shell中（默认 /bin/sh -c） 执行指定的程序，能够进行变量替换。该方式会忽略CMD指令和docker run image 后面的参数。

为了确保长时间运行的入口点程序能够正确接收docker stop发来的UNIX信号，应当使用exec来执行目标程序，例如：

ENTRYPOINT exec top -b

指令格式：

VOLUME ["/mount/point"]
VOLUME  /mount/point1 /mount/point2

在镜像中创建一个挂载点，并将其标记为“承载来自宿主机、其它容器的外部卷”。

在构建阶段，你可以往挂载点写入数据，然后再声明VOLUME指令，这样数据会持久化在镜像中：

RUN echo "Hello Docker!" > /mount/point/greetings
# 后声明VOLUME
VOLUME /mount/point
# 再此之后对/mount/point进行任何改动，都会被丢弃

在docker run时， 容器会在/mount/point挂载新的卷，并且把greetings文件拷贝到此卷中。

指令格式：

USER username-or-uid

在我机器上尝试MySQL镜像时，设置USER为mysql，生效的ID为999，而mysql用户的真实ID是118。直接设置USER为118，没有问题。

指令格式：

WORKDIR /path/to/workdir

指定RUN, CMD, ENTRYPOINT, COPY,ADD指令的工作目录，你可以多次使用该指令，并且可以使用相对（于上一个WORKDIR）路径。示例：

ENV PREFIX /usr/local
# 可以使用环境变量
WORKDIR $PREFIX/bin
# 下面的指令导致工作目录变为/usr/local/bin/python
WORKDIR python

指令格式：

ARG <name>[=<default value>] #该指令可以声明多次，也可以指定一个默认值

该指令定义一个构建时变量。变量的值可以通过

docker build --build-arg <varname>=<value>

ARG定义的变量，对Dockerfile当前行之后的指令生效。ARG变量不会持久化到镜像中。

使用ENV、ARG都可以向RUN指令传递变量，如果这两个指令声明同名的变量，则ENV总是覆盖ARG。

以下ARG是Docker预定义的，不需要声明即可使用：http_proxy、https_proxy、ftp_proxy、no_proxy以及这4个变量的全大写版本。

ARG JAR_FILE
ADD target/$JAR_FILE /app.jar 

如果ARG的值在下一次构建时发生了修改，则第一次使用它定义的变量的那个指令对应的Layer缓存失效。

指令格式：

ONBUILD [INSTRUCTION]

为镜像添加一个触发器指令（ trigger instruction），该指令会在当前镜像被作为其它构建的Base镜像时执行。ONBUILD指定的指令会在子镜像构建时、在子镜像的构建上下文中立即执行，就好像把该指令直接插入到FROM指令后面一样。

所有构建指令都可以通过ONBUILD注册为触发器。

当你制作一个专用于被扩展的Base镜像ONBUILD很有用。举例来说，假设你构建了一个Pyhton的应用编译环境（Base镜像），它要求被构建的Python源码被放置在特定的目录，并在之后调用编译脚本。你无法在构建Base镜像的时候使用ADD、RUN完成前述的工作，因为Base镜像的构建者并不知道源码在哪——每个具体应用程序的源码位置都不同。这时，ONBUILD可以帮助你：

1. 构建Base镜像时，当遇到ONBUILD时，Docker在镜像元数据中添加一条触发器数据。ONBUILD中的指令不会影响Base镜像的构建
2. 在Base镜像构建完毕后，所有触发器的列表（对应多个ONBUILD）被存放到镜像的元数据清单（manifest）中，以OnBuild为Key。你可以对Base镜像执行docker inspect查看触发器列表
3. 构建子镜像时，执行FROM指令时，ONBUILD触发器会按照它们在Base镜像中的声明顺序，依次执行，指有它们全部执行成功，子镜像才会继续构建，否则在FROM指令处失败
4. 子镜像构建完毕后，ONBUILD触发器从子镜像的元数据中移除，这意味着孙子镜像不会感知到ONBUILD触发器

下面是一个具体的例子：

# 将子镜像的构建上下文拷贝到临时容器的特定位置
ONBUILD ADD . /app/src
# 构建Python应用程序，结果的结果固化在子镜像中
ONBUILD RUN /usr/local/bin/python-build --dir /app/src

构建子镜像时，只需要把Python程序源码放在上下文目录中，构建完毕后，子镜像的容器就直接可以使用与子镜像同时构建的Python程序了。 

使用ONBUILD时需要注意：

1. 不支持ONBUILD ONBUILD...
2. 不支持ONBUILD FROM或者ONBUILD MAINTAINER

指令格式：

STOPSIGNAL signal

该指令支持两种格式：

# 在容器内运行一个命令以检测容器的健康状况
# command 要么是一个Shell命令字符串，要么是一个JSON数组
HEALTHCHECK [OPTIONS] CMD command
# 在CMD之前，可以指定以下选项：
--interval=DURATION   # 默认30s，第一次运行健康检测，于容器启动后DURATION秒后，以后每隔DURATION秒检测一次
--timeout=DURATION    # 默认30s，如果健康检测命令超过DURATION秒没有完成，则认为执行失败
--retries=N           # 默认3， 健康检测命令连续失败的最大次数，超过此次数，认定容器处于unhealthy状态

# 禁用任何从Base镜像继承来的健康检测指令
HEALTHCHECK NONE

该指令告知Docker，如何确认容器仍然在正常工作。正常工作不仅仅要求进程在运行，还要求特定于具体应用的检测可以通过（例如对于Web应用，能够正常处理HTTP登录请求）。

当指定了该指令后，在normal status之外，还多了一个health status。该状态的初始值为starting，当健康检测通过后，变为healthy；当检测不通过、或者若干次检测失败后，变为unhealthy。

command的退出状态用于判断容器是否健康：0 表示健康；1表示不健康；2为暂不使用的保留值。command的输出到stdout/stderr的信息，可以通过docker inspect命令查看到。

每个Dockerfile仅支持一个HEALTHCHECK指令，如果指定了多个，只有最后一个生效。

指令格式：

SHELL ["executable", "parameters"]

用于覆盖那些使用shell格式的指令所使用的默认Shell：

1. Linux下默认Shell为

   ["/bin/sh", "-c"]

    
2. Windows下默认Shell为

   ["cmd", "/S", "/C"]

    

在Windows平台上该指令很有用，因为Windows提供了两个常用却完全不同的Shell：cmd和powershell。

SHELL指令可以出现多次，每次均覆盖之前的取值。

你可以在Dockerfile中使用多个FROM语句，每个FROM触发一个新的构建阶段（Stage）。你可以选择性的把某些构建从一个阶段拷贝到另外一个，而把任何不需要引入最终镜像的文件丢弃 —— 例如构建工具、依赖包。

下面是一个例子：

FROM golang:1.7.3
WORKDIR /go/src/github.com/alexellis/href-counter/
RUN go get -d -v golang.org/x/net/html  
COPY app.go .
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app .

FROM alpine:latest  
RUN apk --no-cache add ca-certificates
WORKDIR /root/
# --from表示从前面的stage拷贝
COPY --from=0 /go/src/github.com/alexellis/href-counter/app .
CMD ["./app"]

这个例子的第一阶段使用Go SDK构建源码，第二阶段则将第一阶段中的文件拷贝过来。

除了使用序号，你还可以通过名称来引用Stage：

FROM golang:1.7.3 as builder
...
FROM alpine:latest 
COPY --from=builder /go/src/github.com/alexellis/href-counter/app .

你可以仅仅执行一部分Stage，然后就停止构建：

# 执行到builder这个stage即停止
docker build --target builder -t alexellis2/href-counter:latest .

任何一个镜像都可以作为Stage使用，从中拷贝文件：

COPY --from=nginx:latest /etc/nginx/nginx.conf /nginx.conf

为了编写易用、有效的Dockerfile，Docker官方发布了若干条最佳实践。如果你要构建官方镜像，则必须遵守这些实践。

容器的生命周期应该尽可能的短暂，创建、启动、停止、删除应当消耗最小化的时间。这意味着你应该尽可能的通过Dockerfile把内容放在镜像内。

大部分情况下，可以把Dockerfile放置在空白的目录中，后续仅在此目录中存放构建镜像时所必须的文件。 

如果目录中包含一些你需要排除出构建过程的目录/文件，可以编写一个.dockerignore文件，其格式类似于 .gitignore。

尽可能少的安装Linux软件包，这样可以降低镜像的大小、构建过程的耗时

大部分情况下，你应该在单个容器中运行仅单个程序（例如Web服务、DB服务）。将应用程序解耦到不同容器中可以更好的实现容器重用、水平扩展。

当一个程序依赖于另外一个时，可以使用容器链接（container linking）。

应当十分谨慎的考虑Dockerfile使用的层数（Number of layers），在Dockerfile可读性（可维护性）和最小化层数之间寻求平衡。

尽可能的按照字典序对参数（特别是apt安装的软件包参数）进行排序，这样可以避免后续维护者添加重复的安装包。

在构建镜像时，Docker会遍历你的Dockerfile的指令，检查完这些指令后，它会到缓存中寻找已经构建的镜像，而不是构建“重复”镜像。要避免使用缓存，可以在docker build时指定

--no-cache=true

如果使用缓存，你必须明白它是如何寻找“重复”镜像的：

1. 选取与当前Dockfile使用同一Base镜像的缓存镜像列表，遍历此列表，如果某个条目的构建指令与当前Dockerfile完全一致，则该条目可能是“重复镜像”
2. 对于ADD、COPY指令，目标文件集合被检查并计算Checksum（不包含修改时间、最后访问时间信息），如果某个缓存镜像条目对应的ADD、COPY指令操控的文件集合的Checksum与前面的Checksum一致，则该条目匹配“重复”镜像

当找不到匹配的镜像时，Docker将从头开始，构建一个新镜像。

# 在同一行中声明多个标签
LABEL cc.gmem.version="0.0.1-beta" cc.gmem.release-date="2015-02-12"
# 除了使用引号包围含有空格的字符串以外，还可以使用转义的方式：
LABEL vendor=Gmem\ Studio

RUN apt-get update && apt-get install pkg-bar

# 在同一个指令中完成update和install
RUN apt-get update && apt-get install -y \
    # 按字典序排列软件包，便于维护
    aufs-tools \
    build-essential \
    curl \
    dpkg-sig \
    ruby1.9.1 \
    ruby1.9.1-dev \
    s3cmd=1.1.* \ # 指定软件包版本
 && rm -rf /var/lib/apt/lists/*  
    # 清理apt缓存，减少镜像尺寸。
    # 注：Docker官方提供的Debian/Ubuntu镜像自动运行apt-get clean，因此不需要这里的rm命令

CMD ["executable", "param1", "param2"…]

CMD ["apache2","-DFOREGROUND"

CMD ["perl", "-de0"]

CMD ["python"]

# 暴露一个端口范围
EXPOSE 7000-8000
# 暴露一个端口
EXPOSE 8080 

ENV PATH /usr/local/nginx/bin:$PATH

CMD [“nginx”]

ADD rootfs.tar.xz /.

ENTRYPOINT ["s3cmd"]
CMD ["--help"]

# 这里的s3cmd是镜像名，而不是s3cmd命令
docker run s3cmd
# 效果上等同于docker run s3cmd  s3cmd --help

# 你也可以传递任何其它选项
docker run s3cmd ls s3://gmem

ENTRYPOINT ["/docker-entrypoint.sh"]

$@

RUN groupadd -r postgres && useradd -r -g postgres postgres

RUN cd … && do-sth

要有效利用Docker的存储机制，首先需要搞清楚它是如何构建、存储镜像的，然后要理解镜像是如何被容器使用的。

一个镜像文件由一系列层层叠加的、只读的层（Layers）构成，这些层共同组成了镜像的根文件系统。Docker的存储驱动负责管理这些层，对外提供单一的文件系统视图。

当你创建一个容器时，Docker会在镜像的层叠之上，添加一个薄的、可读写的容器层（container layer）。容器运行过程中对文件系统的任何更改（增加、修改、删除文件），都持久化到容器层中。

所有镜像、容器的层都位于本地文件系统中，由存储驱动管理。在Linux下，默认存储目录为/var/lib/docker/。

下图是基于Ubuntu:15.04的容器的文件系统层叠示意图：

Docker从1.10开始，引入了一个新的内容寻址存储（Content addressable storage，CAS）模型。该模型提供了在磁盘上寻址镜像、层数据的全新方法。在此之前，镜像、层数据使用随机的UUID来引用和存储，CAS则使用内容哈希值（content hash）来引用镜像、层数据。

CAS增强了安全性，内置了防止ID冲突的机制，并且能在pull、push、load、save操作后保证数据完整性。它也提供了更好的层共享机制——允许很多镜像自由的共享层，即时这些层来自不同的构建。

使用CAS后，所有层的ID均变成基于其内容的哈希值。但是，容器的ID仍然是随机的UUID。

这一变化导致，从老版本的Docker升级到1.10后：

1. 既有镜像需要迁移：由于层ID的生成规则发生变化，老版本Docker从仓库Pull下来的镜像的ID必须重新生成。新版本的Docker守护程序在初次运行时会自动执行这一迁移操作。迁移操作完毕后，所有镜像、标签具有新的secure IDs。如果本地镜像非常多，迁移操作可能消耗很长的时间才能完成，这期间Docker守护程序无法响应外部请求

从存储角度来看，镜像与容器的主要区别就在于后者的Layer栈顶部包含一个薄的可读写层。当容器创建后，该读写层一同创建；当容器删除后，该读写层也被删除；容器运行时，所有对文件系统的变更都落到这个读写层中。

由于一个镜像的所有容器具有自己的可读写层，因而它们能够安全的共享底层的镜像。Docker的存储驱动负责管理所有的层（不管是镜像还是容器的），如何管理取决于具体的驱动，但是两个关键技术是通用的：1、可层叠镜像层（stackable image layers）；2、copy-on-write

这个策略在软件系统中很常见。例如在操作系统中，两个使用相同数据块的进程，可以安全共享数据块的单份拷贝。只有当其中一个进程需要对共享数据进行修改（而另外一个进程不进行修改）时，才需要共享数据的额外拷贝。

Docker同时对镜像、容器使用此CoW策略，以便节约存储空间并缩短容器启动时间。CoW依赖于存储驱动的支持，不是所有驱动支持CoW。

执行pull/push子命令时，Docker客户端会报告其操作的Layer：

docker pull ubuntu:15.04
# 9502adfba7f1: Pull complete 
# 4332ffb06e4b: Pull complete 
# 2f937cc07b5f: Pull complete 
# a3ed95caeb02: Pull complete 
# Digest: sha256:2fb27e433b3ecccea2a14e794875b086711f5d49953ef173d8a03e8707f1510f
# Status: Downloaded newer image for ubuntu:15.04

可以看到，拉取Ubuntu镜像时，实际上下载了4个Layer，它们共同组成了完整的系统镜像。

如果使用AUFS驱动，在1.10版本之前，Layer以其ID为目录名，存放在本地存储的子目录/var/lib/docker/aufs/layers中。

不管Docker引擎的版本是多少，相同的Layer都会被共享，而不是重新拉取。

前面提到，对容器文件系统的所有修改都写在一个薄的顶部层中，来自镜像的层都是只读的，这意味着多个容器可以共享一个镜像。

当容器修改了一个文件后，Docker利用存储引擎来执行CoW策略，具体细节取决于引擎。对于AUFS、OverlayFS这两种存储引擎来说，CoW的大概步骤如下：

1. 从顶层向下，逐层寻找，定位到被修改的文件
2. 将找到的文件拷贝（Copy-up）到顶部的可写层
3. 修改位于可写层中的文件副本

Copy-up操作可能带来重大的性能影响，影响程度取决于存储驱动。但是过大的文件、过多的层、过深的目录树都会加重影响程度。不过Copy-up操作对一个文件至多发生一次。

CoW让容器共享镜像，这一方面让容器本身的尺寸很小，另一方面则让容器高效的创建、执行，因为不需要牵涉到太多的I/O操作。

当容器被删除后，所有没有存储在数据卷（Data volume）中的数据都会被删除。数据卷是宿主机上的一个目录或者文件，它被直接挂载到容器的目录树中。

多个容器可以共享数据卷，但是要注意并发修改的问题。

数据卷不受存储驱动的控制，对其进行的I/O操作绕过存储驱动，直接由宿主机执行，其速度和宿主机上普通I/O操作一样快。

为了基于实际运行环境选择最好的驱动，Docker设计了可拔插的存储驱动架构。存储驱动基于一个Linux文件系统或者卷管理器，它们可以自由的实现镜像/容器Layer的管理。

在决定使用哪种驱动后，你需要设置Docker守护程序的启动参数。修改/etc/default/docker中的DOCKER_OPTS，添加

--storage-driver=<sd_name>

注意一个Docker守护程序同时只能使用一种存储驱动。执行命令：

docker info | grep "Storage Driver"
# Storage Driver: aufs

可以看到当前使用的存储驱动。上例中的aufs为存储驱动的名称，存储技术与存储驱动名称对照表如下： 

许多企业使用SAN、NAS之类的共享存储技术以提高性能和可靠性，或者实现Thin Provisioning（避免预分配过多的容量）、数据复制、压缩等高级特性。

Docker存储驱动、数据卷均可以在这些共享存储系统之上工作，但是Docker不能直接与底层的共享存储技术集成。你需要选择与共享存储技术匹配的存储驱动。

OverlayFS是目前使用比较广泛的层次文件系统，实现简单，读写性能较好，并且稳定。

与OverlayFS相关的存储驱动有两个：overlay、overlay2。前者的缺陷包括inode耗尽和commit performance，后者就是为了解决这两个问题而生，但是需要4.0或者更高版本的Linux内核。

AUFS是第一个出现的Docker驱动，它非常稳定，在生产环境下有很多部署案例，并且社区支持很好。AUFS的优势包括：

1. 容器启动时间短
2. 存储利用效率高
3. 内存利用效率高

对于PaaS或者其它需要高密度容器实例的应用场景，AUFS是很好的选择。但是由于CoW策略，第一次写文件操作可能带来很大的开销。

由于AUFS不在Linux内核主线中，因此某些发行版不会自带AUFS，需要手工下载和安装。

要验证当前系统是否支持AUFS，可以执行命令：

cat /proc/filesystems | grep aufs

如果上述命令没有输出，先确保你的内核版本高于3.13，并参考如下命令安装：

sudo apt-get install linux-image-extra-$(uname -r) linux-image-extra-virtual

安装完毕后，修改Docker守护程序的参数：

sudo dockerd --storage-driver=aufs

上面的参数修改不是持久化的，要永久的修改，需要打开Docker配置文件，添加：

DOCKER_OPTS="--storage-driver=aufs" 

AUFS是一种联合文件系统（UFS），它管理单个Linux宿主机上的多个目录，并将其叠加在一起，在单个挂载点形成统一的视图。与UnionFS、OverlayFS类似，AUFS是一种union mounting实现。AUFS管理的每个Linux宿主机目录称为联合挂载点（union mount point）或者分支（branch）。

AUFS的思想与Docker的Layer机制天然吻合——每个branch对应一个镜像/容器的Layer。Copy-up操作实质上就是在宿主机文件系统的不同目录之间复制文件。

由于AUFS在文件级别上操作，这意味着，即使在仅仅修改文件一小部分的情况下，CoW操作也需要复制整个文件。因此，当写入一个体积很大的文件时，AUFS会遭遇一次性的性能问题。

当删除文件时，AUFS在顶层Layer添加一个所谓without文件，该文件命名为

.wh.filename

使用AUFS时，镜像、容器的文件默认被存放到dockerd所在机器的/var/lib/docker/aufs/目录下 。

安装Docker之后，会自动创建bridge、none、host这三个网络，可以通过命令

docker network ls

--network

在三个默认网络中，通常你只会和bridge做交互。这些网络不能被删除，因为Docker本身需要使用。

你可以创建其它自定义网络，并在不需要的时候删除它们。

为了更好的隔离容器，可以创建自定义网络。利用Docker提供的网络驱动，你可以创建桥接（Bridged）、重叠（Overlay）、MACVLAN等类型的网络。

自定义网络可以创建多个，每个容器也可以加入到多个网络中。容器仅仅能在网络内部而不能跨网络通信。当容器连接到多个网络时，其外网连接性由第一个（词法序）具有外部连接能力的网络提供。

Linux内核支持虚拟网桥，可以连接多个网络接口，功能类似于交换机。

在自定义网络中，桥接是最简单的一种。添加到桥接网络的容器，必须位于同一台宿主机上。网络中的所有容器可以相互通信，但是这些容器不能访问外部网络。

与Docker0不同，自定义桥接网络不支持--link。但是你可以暴露/发布容器的端口，这样桥接网络的一部分可以被外部访问。自定义桥接网络嵌入了DNS服务器，容器之间可以通过名字访问。

当你需要基于单宿主机建立一个简单的网络时，可以考虑自定义桥接网络。

桥接网络的示例：

docker network create -d bridge --subnet=172.21.0.0/16 --gateway=172.21.0.99 local 

这个特殊的本地桥接网络，在以下两种情况下，由Docker自动创建：

1. 当你初始化或者加入到一个swarm时，Docker创建docker_gwbridge，以便跨主机的进行swarm节点之间的通信
2. 如果容器所加入的任何网络都不具有外部连接性，Docker把容器连接到docker_gwbridge

你可以提前手工创建docker_gwbridge网络，进行定制化配置。

当使用overlay网络时，docker_gwbridge总是存在。

利用Overlay网络可以跨越多台宿主机组网。

在swarm模式下运行Docker引擎时，你可以在管理节点上创建overlay网络，这种网络不需要外部的key-value存储。

swarm可以让overlay网络仅仅对需要它以提供一个服务的swarm节点可用。当你创建一个使用overlay网络的服务时，管理节点会自动扩展overlay网络以覆盖运行服务的节点。

下面的命令示例如何在swarm管理节点创建overlay网络，并在服务中使用它：

# 创建一个overlay网络
docker network create --driver overlay --subnet 10.0.9.0/24 my-multi-host-network
# 创建一个Nginx服务，并把刚刚创建的网络扩展到运行Nginx服务的那些节点
docker service create --replicas 2 --network my-multi-host-network --name my-web nginx

注意：这种overlay网络对docker run启动的容器是不可用的，目标容器必须是swarm模式服务的一部分。

基于swarm模式的overlay网络默认具有安全保证。swarm节点使用gossip协议来交换overlay网络的信息，并且使用GCM模式的AES算法加密gossip协议，管理节点默认每12小时更换密钥。

如果要加密容器通过overlay网络交换的信息，需要使用选项：

docker network create --opt encrypted --driver overlay  nw

上述命令将自动为参与到overlay网络的节点创建IPSEC通道，这些通道也使用GCM模式的AES算法，每12小时更换密钥。 

此方式的overlay网络与swarm模式的overlay网络不兼容。主要用于需要考虑兼容性的场景。

当不在swarm模式下使用Docker引擎时，启用overlay网络依赖于外部key-value存储的支持，这些存储包括Consul、Etcd、ZooKeeper。你需要手工安装这些存储，并确保它们可以和Docker宿主机自由通信。

宿主机必须开启4789、7946端口。如果启用加密的overlay网络（--opt encrypted）则需要允许protocol50(ESP)流量。此外KV服务也需要暴露端口。

各宿主机上的Docker引擎守护程序，需要配置dockerd选项以支持overlay网络：

这种网络不同于overlay，可以把容器直接暴露到物理网络中。

首先，创建网络：

# 设置目标网卡为混杂模式
sudo ip link set virbr0 promisc on
# parent指定桥接到的宿主机网卡，以及子网信息
docker network create -d macvlan --subnet=10.0.0.0/8 --gateway=10.0.0.5  -o parent=virbr0 virbr0

然后，运行容器： 

docker run -it --rm --network=virbr0 --ip=10.0.0.100 ubuntu:14.04

注意，如果不指定IP，则容器的IP会从当前网段的192.168.0.2开始分配，不管是否被占用。 

连接到默认桥接网络，且以--link选项创建容器时：

1. 可以解析其它容器的名字为IP
2. 可以为其它容器指定任意别名：

   --link=CONTAINER-NAME:ALIAS

    
3. 安全容器连接，即--icc=false
4. 环境变量注入

当使用自定义桥接网络时，上述特性默认启用，不需要额外的选项。并且你可以：

1. 基于网络内嵌的DNS服务器进行容器名到IP的解析
2. 使用--link（仅用来）指定别名

link选项的示例：

# 创建容器，连接到isolated_nw，并且当前容器访问container5时可以使用别名c5
docker run --network=isolated_nw -itd --name=container4 --link container5:c5 busybox
# 在连接到某个网络时，也可以指定link选项
docker network connect --link container5:foo local_alias container4

与--link不同 ，该选项可以指定当前容器在网络中的别名，网络中的其它容器都可以使用该别名：

docker run --network=isolated_nw -itd --name=container6 --network-alias app busybox

多个容器可以声明相同的别名，这种情况下，其中一个容器（随机）会响应DNS解析。当该容器宕掉后，其它同名容器自动响应解析。这个特性可以用来实现简单的高可用性。

自定义网络中的容器的DNS查找行为与默认bridge网络不同，处于向后兼容的目的，后者的行为与旧版本保持一致。

自1.10版本开始，Docker守护程序嵌入了DNS服务，此服务支持基于容器link、name、net-alias配置的DNS查找。容器还可以通过--dns等选项来指定外部DNS服务器，当内嵌DNS服务器无法解析某个主机名时，会转给外部DNS处理。

默认情况下，容器不被施加资源限制，可以使用宿主机内核调度器允许的最大资源。Docker提供了控制内存、CPU、块I/O用量限制的方法。

你可以为容器施加硬性内存限制，确保容器不占用超过特定值的用户/系统内存。你也可以施加软性限制，允许容器按需使用内存，但当特定条件（例如内核检测到宿主机内存过低）发生时，限制容器内存占用。

内存限制通过docker run命令的选项给出，这些选项的值都是正整数，后面可以跟着b/k/m/g等单位：

默认的，容器可以无限制的使用CPU时钟周期。Docker提供了若干选项，对容器的CPU使用进行限制。这些选项支持CFS调度器，自1.13开始实时调度器也支持某些选项。

CFS是用于大部分Linux进程的调度器，Docker提供以下容器选项：

自1.13版本开始，Docker支持配置容器使用实时调度器。作为前提条件，宿主机内核选项CONFIG_RT_GROUP_SCHED必须开启。

要使用实时调度器运行容器，需要设置dockerd选项

--cpu-rt-runtime

相关配置选项：

典型的容器在启动时，仅仅会发动一个进程——例如Apache或者SSH守护进程。要在容器中运行多个服务，你可以编写脚本，或者使用进程管理工具。

Supervisor是一个流行的进程管理工具，使用它可以更加方便的控制、管理、重启容器中的进程。本章以一个例子来说明如何使用Supervisor来管理容器中的多个服务。

# 安装Supervisor和两个服务
RUN apt-get update && apt-get install -y openssh-server apache2 supervisor
# 守护进程需要的目录
RUN mkdir -p /var/lock/apache2 /var/run/apache2 /var/run/sshd /var/log/supervisor
# 复制Supervisor配置文件到容器上下文
COPY supervisord.conf /etc/supervisor/conf.d/supervisord.conf
# 暴露端口
EXPOSE 22 80
# 容器启动时执行supervisord
CMD ["/usr/bin/supervisord"]

该配置文件内容如下：

; 第一段，配置Supervisor本身
; nodaemon提示Supervisor以交互式运行，而不是守护式。这样可以确保它可以正常接收信号
[supervisord]
nodaemon=true

; 以下的每个段，分别定义一个需要被控制的服务
[program:sshd]
command=/usr/sbin/sshd -D

[program:apache2]
command=/bin/bash -c "source /etc/apache2/envvars && exec /usr/sbin/apache2 -DFOREGROUND"

该命令可以实时监控容器的CPU、内存、网络、块I/O资源的占用情况。

Linux容器所依赖的内核机制——控制组（Cgroups），不仅仅支持跟踪进程组，还暴露了度量CPU、内存、块I/O的接口。

控制组通过一个伪文件系统

/sys/fs/cgroup

grep cgroup /proc/mounts

在每个子系统内部，可以存在多级子目录。这些目录的最深处，会包含1-N个伪文件，其中包含了统计信息。

查看文件/proc/cgroups可以查看系统中已经支持的Cgroup层次。输出中包含Cgroup子系统名称、包含的组数量等信息。

查看文件/proc/$PID/cgroup可以查看某个进程所属的Cgroup。输出 / 表示没有划分到特定的Cgroup，/lxc/pumpkin可能意味着进程属于容器pumpkin的成员。

子系统memory提供内存的统计信息。由于memory控制组会增加一定的overhead，因此某些发行版默认情况下禁用了它。你可能需要添加内核参数：

cgroup_enable=memory swapaccount=1

该子系统对应的伪文件是memory.stat。不包含total_前缀的数据项，与当前Cgroup中的进程有关，包含total_d前缀的数据项，则与当前Cgroup、所有子代Cgroup中的进程有关。

常用数据项列表如下：

该子系统对应的伪文件是cpuacct.stat，包含容器中进程累计的CPU使用信息。user、system分别表示用户空间、系统空间中代码消耗的时间。时间的单位为jiffies，在X86上通常为10ms。

Cgroup没有直接暴露网络度量信息。尽管内核可以计算出一个Cgroup中进程收发的网络包数量，但是意义不大。你可能需要基于网络接口的度量，因为lo接口上的流量没有太大价值。

单个Cgroup中的进程可以属于多个网络名字空间（ network namespace），多个网络名字空间意味着多个lo甚至eth0，这导致难以收集Cgroup的网络流量。

你可以基于iptables规则设置计数器，然后使用命令获取度量。

获取网络接口级别的度量信息是可能的，因为每个容器都关联了宿主机上的一个虚拟以太网接口。但是难以知道这些接口和容器的对应关系。

命令

ip netns exec

# $CID为容器ID，TASKS为容器下进程的PID列表
TASKS=/sys/fs/cgroup/devices/docker/$CID*/tasks
PID=$(head -n 1 $TASKS)
# 创建后面命令需要的符号连接
mkdir -p /var/run/netns
ln -sf /proc/$PID/ns/net /var/run/netns/$CID
# 在容器的网络名字空间下执行netstat命令
ip netns exec $CID netstat -i

对于每一个容器，在每一个Cgroup子系统中均会创建一个与之对应的组。

如果使用最近版本的LXC工具，Cgroup名字为lxc/$container_name。

对于使用Cgroup的Docker容器，Cgroup路径为/sys/fs/cgroup/$subsystem/docker/$longid/，其中longid为容器完整的ID。

要使用Swarm模式，你可以安装1.12版本以上的Docker。Swarm模式用于管理Docker引擎的集群。你可以使用Docker CLI来创建Swarm、部署应用服务到Swarm、管理Swarm的行为。

准备三台宿主机，一台用作Manager，其它的用作Worker。Swarm中所有节点都必须能够访问Manager的IP地址。以下端口必须开启：

默认的，Swarm模式是禁用的。你可以创建新Swarm、加入既有Swarm，以使当前节点进入Swarm模式。

确保Docker引擎守护程序正在运行，然后登录到Manager节点，执行：

docker swarm init --advertise-addr 10.0.0.1

这样当前节点就称为新建Swarm集群的管理节点了。管理节点使用通知地址（advertise address）来允许集群中其它节点访问Swarmkit API以及Overlay网络，因此IP地址10.0.0.1必须可以被所有其它节点访问到。如果宿主机具有单个IP地址，你可以不指定--advertise-addr，反之则必须指定。

执行docker info，可以看到当前Swarm的基本信息；执行docker node ls则可以看到集群中的节点列表。

首先在Manager节点上执行：

# 获取Worker的加入令牌
docker swarm join-token worker --quiet
# 输出  SWMTKN-1-5evgfnqh3xw67rtqucyq3cctxb929sqwfczv8s1gtz0cptpe5m-84evs0quy124fql5zcyxp7ppe

# 获取Manager的加入令牌
docker swarm join-token manager --quiet 

登录到用作Worker节点的宿主机，执行：

docker swarm join --token SWMTKN-1-...-... 10.0.0.1:2377

作为工作节点加入时，swarm join子命令会执行以下操作：

1. 把目标节点的Docker引擎切换到Swarm模式
2. 向管理节点请求一个TLS证书
3. 基于宿主机名来命名节点
4. 通过管理节点的通知地址、基于令牌加入目标节点到集群中
5. 设置目标节点的可用性为Active，使之能够接收Task
6. 扩展ingress overlay网络，使之覆盖当前节点

作为管理节点加入时，执行的操作与上面类似。新的管理节点状态为Reachable，但是Swarm的Leader不变。

所谓令牌，是加入Swarm时需要的一个字符串，作为管理节点/工作节点加入时的令牌是不一样的。管理节点的令牌要特别注意保护。当发生以下情况下，考虑使用join-token子命令更改（rotate）令牌：

1. 令牌被意外泄漏，例如签入到版本控制系统
2. 如果怀疑某个节点被入侵
3. 如果期望禁止任何可能的新节点加入到Swarm
4. 建议最多每6个月更换令牌

下面的命令示例如何更换工作节点令牌：

docker swarm join-token  --rotate worker 

在管理节点上运行

docker node ls

输出的AVAILABILITY列表示节点的可用性：

输出的MANAGER STATUS表示节点参与Raft consensus的情况：

所谓服务就是在特定镜像上执行的命令，而任务即服务的实例，任务的数量即服务的replicas个数。

在管理节点上运行：

docker service create --replicas 4 --name ping ubuntu:14.04 ping 10.0.0.1

即可创建在Ubuntu 14.04上运行ping命令的服务，这个服务有4个实例（Task） 。

执行下面的命令可以查看任务执行的概要信息：

docker service ls

# ID            NAME  REPLICAS  IMAGE         COMMAND
# 48qbjfwd8u8r  ping  1/4       ubuntu:14.04  ping 10.0.0.1

如果想让服务对Swarm外部可见，你需要暴露特定的端口。

你可以设置服务的环境变量、工作目录、运行身份：

docker service create --name ping --env MYVAR=myvalue --workdir /tmp  --user my_user  ...

使用--secret选项，可以授予服务对Docker管理的Secret的访问权。

可以执行以下命令查看服务执行的详细信息：

docker service inspect --pretty  ping
docker service ps  ping

在管理节点上执行下面的命令，可以动态的修改服务的任务数量：

docker service scale ping=1

在管理节点上执行下面的命令可以删除服务：

docker service rm ping

注意，尽管服务被删除，执行Task的容器可能还需要一段时间执行清理工作

所谓滚动更新，是指逐步的更新服务的每个实例。下面的例子演示如何从Redis 3.0.6滚动更新到Redis 3.0.7。

首先创建服务：

docker service create  --replicas 3   --name redis   --update-delay 10s  --update-parallelism 1 redis:3.0.6

选项--update-delay定义了更新一个/一组任务的延迟时间，你可以使用10m30s这样的形式。 默认情况下是一个接着一个的更新，要每次更新多个Task可以使用选项--update-parallelism。

默认情况下，当正在更新的任务状态变为RUNNING后，调度器会调度下一个任务的更新，此步骤一直执行直到所有任务都被更新，如果更新过程中任何一个任务返回FAILED状态，则调度器暂停更新。选项--update-failure-action可以改变此行为。

执行下面的命令把Redis版本更改为3.0.7：

docker service update --image redis:3.0.7 redis

# 更新步骤：
# 1、停止第1个任务
# 2、调度此任务的更新操作
# 3、启动被更新过的任务
# 4、如果新任务返回RUNNING，继续更新下一个任务
# 5、如果新任务返回FAILED，暂停更新

要重启被暂停的更新，可以执行：

docker service update redis

如果更新后的服务工作不正常，你可以回滚到前一个版本：

# --rollback 回滚服务
# --update-delay 0s 立即回滚
docker service update --rollback --update-delay 0s my_web

当Swarm中的几个服务需要相互通信时，可以使用Overlay网络。

首先，在Swarm模式下的管理节点上创建Overlay网络：

docker network create --driver overlay my-network

这样，所有管理节点都可以访问该Overlay网络了。创建服务：

docker service create  --replicas 3 --network my-network --name my-web nginx

这样，所有运行my-web服务的Task的节点，都被Overlay网络覆盖。

前面例子中的Worker节点，其可用性（availability）都是ACTIVE。Manager节点可以向ACTIVE派发任务。

某些时候（例如需要维护节点硬件），需要把可用性设置为DRAIN。DRAIN阻止管理节点派发新的任务，并且，停止DRAIN节点上正在运行的任务，在可用的ACTIVE节点上启动对应数量的任务副本。

执行下面的命令可以查看节点可用性：

docker node ls

# ID                           HOSTNAME  STATUS  AVAILABILITY  MANAGER STATUS
# 5imye5fakqgdd7jg6erkize8a    coreos    Ready   Active        
# ap7gwtam1jjqvp3h4arco6vdz *  Zircon    Ready   Active        Leader
# bfini24kw83rzrh2e5cb33g8f    Jade      Ready   Active

执行下面的命令可以设置DRAIN：

# 可以使用HOSTNAME或者ID
docker node update --availability drain  coreos

维护完成后，重新设置为ACTIVE：

docker node update --availability active coreos

为了让外部资源能够轻松的访问Swarm中的服务，Docker引擎提供了方便的端口暴露机制。所有Swarm节点均参与到一个入口路由网（Ingress Routing Mesh），此路由网允许Swarm中的任意节点接收某个服务暴露端口的请求——甚至在节点没有运行此服务的任务的情况下。路由网负责把对暴露端口的请求路由到活动的服务容器中。

要正常使用入口路由网，需要确保TCP/UDP端口7946、UDP端口4789开放。当然，Swarm服务暴露的端口也需要被外部资源（例如负载均衡器）正常访问。

要暴露端口，可以在创建服务时使用

--publish PUBLISHED-PORT:TARGET-PORT

# 暴露端口8080，此端口自动转发给my-web服务运行节点上的80端口
docker service create --name my-web  --publish 8080:80 --replicas 2  nginx

对于已经存在的服务，可以在更新时指定

--publish-add PUBLISHED-PORT:TARGET-PORT

暴露的端口，默认是TCP端口，可以使用以下格式指定TCP或者UDP端口：

# TCP
--publish 53:53
--publish 53:53/tcp
# TCP和UDP
--publish 53:53/tcp -p 53:53/udp 
# UDP
--publish 53:53/udp

使用入口路由网的端口暴露机制，可能不满足应用需求。你可能需要根据应用程序状态来决定如何路由请求，或者你需要对路由处理过程进行完全的控制。

要直接暴露服务所在运行的节点上的端口，可以使用

--publish mode=host

--mode=global

在1.13版本之后，在服务创建之后你可以使用

service update --image

每个镜像Tag对应了一个摘要（Digest），就像Git的Hash一样。某些标签，例如latest，其指向的摘要会改变。当你运行service update --image时，管理节点根据Tag到Docker Hub或者本地私服查询。如果：

1. 管理节点能够把Tag解析为Digest，则指示工作节点使用Digest对应的镜像来重新部署任务
   1. 如果工作节点已经缓存了此Digest对应的镜像，则使用之
   2. 否则，从Docker Hub或者私服拉取镜像
      1. 如果拉取成功，基于新镜像部署任务
      2. 否则，服务在工作节点上部署失败。Docker会尝试重新部署任务（可能在其它节点）
2. 管理节点不能够正常解析Tag，则指示工作节点使用Tag对应的镜像重新部署任务
   1. 如果工作节点已经缓存了此Tag对应的镜像，则使用之
   2. 否则，从Docker Hub或者私服拉取镜像
      1. 如果拉取成功，基于新镜像部署任务
      2. 否则，服务在工作节点上部署失败。Docker会尝试重新部署任务（可能在其它节点）

可以使用--replicas选项设置服务的需要的任务数：

docker service create --name my_web --replicas 3 nginx

可以使用--mode选项设置服务是全局模式还是复制模式：

docker service create --name myservice --mode global alpine top

选项

--reserve-memory

--reserve-cpu

你可以为Swarm服务创建两种类型的挂载：volume、bind。要创建挂载，指定--mount选项，如果不指定--type，默认类型为volume。

卷挂载（volume）是当运行任务的容器被移除后，仍然存在的存储。要利用既有的卷时，通常使用此类型的挂载：

docker service create  --mount src=VOLUME-NAME,dst=CONTAINER-PATH --name myservice IMAGE

# 在部署期间（调度器分发任务后、启动容器前）创建一个卷挂载：
docker service create --mount type=volume,src=VOLUME-NAME,dst=CONTAINER-PATH,volume-driver=DRIVER,\
    volume-opt=KEY0=VALUE0,volume-opt=KEY1=VALUE1  --name myservice IMAGE

绑定挂载（Bind） 映射到运行服务容器的宿主机。在Swarm初始化容器前，宿主机路径必须存在。示例：

# 挂载为读写
docker service create --mount type=bind,src=HOST-PATH,dst=CONTAINER-PATH --name myservice IMAGE
# 挂载为只读
docker service create --mount type=bind,src=HOST-PATH,dst=CONTAINER-PATH,readonly --name myservice IMAGE

绑定挂载很有用，但是也可能很危险：

1. 由于任务可能被分配到任何满足条件的节点上，而绑定挂载要求路径预先存在
2. 调度器可能在任何时候重新分配某个任务 

管理节点负责以下集群管理工作：

1. 维护集群状态
2. 调度服务
3. 提供Swarm模式的HTTP API端点服务

基于Raft（一种算法），管理节点维护整个Swarm、所有运行中服务的一致性内部状态。

在测试环境下，你可以使用单管理节点，但是，一点此节点宕机，你需要重新创建Swarm才能恢复。

为了利用Swarm的容错特性，最好建立奇数节点数的管理节点。如果有多个管理节点，Swarm可以自动从管理节点宕机中恢复，没有downtime。当总计3个管理节点时，可以容忍1个宕机；当5个管理节点时，可以容忍2个宕机；当N个管理节点时，可以容忍(N-1)/2个管理节点宕机。Docker推荐每个Swarm中有7个管理节点。

工作节点的唯一任务就是执行容器。默认的，管理节点同时也是工作节点。

要阻止派发任务给管理节点，可以将后者的可用性设置为Drain，调度器会优雅的停止Drain上运行的任务并且在其它节点上重新调度。

要在Swarm模式下部署应用程序，你需要创建一个“服务”。通常情况下，服务是某个较大应用程序的上下文中的某个“微服务“， 例如HTTP服务、数据库服务、或者任何形式的可执行程序。

当创建服务时，你需要指定使用什么镜像，以及在基于此镜像的容器中运行什么命令。你可以同时指定：

1. Swarm暴露的端口，这使得服务对外可用
2. 让服务可以与Swarm中其它服务进行通信的Overlay网络
3. CPU和内存限额、预留
4. 滚动更新策略
5. 服务的复制（replicas）份数

当你在Swarm中部署服务时，Swarm接受你给出的服务定义（service definition），作为目标服务的期望状态（desired state ）。之后，Swarm调度服务，形成在节点上运行的一个或N个任务。每个任务独立于集群中其它节点运行。

下面是具有三个Replica的HTTP服务的例子：

容器是一个被隔离的进程，在Swarm模式的模型中，每个任务调用仅一个容器。任务就好像是一个插槽，调度器将容器插入其中。一旦容器开始运行，调度器将任务设置为RUNNING状态；如果容器未通过健康检查、停止运行，则任务也被终结。

任务是Swarm调度的原子单元。当你通过创建/更新服务来声明服务的期望状态时，编排器（orchestrator）识别出被调度任务的期望状态——当你声明保持3个HTTP服务一直运行，编排器就会创建三个任务。

任务是一个插槽，调度器产生容器进程并填充到插槽。容器是任务的实例。任务是一种单向的机制，它从：已分配（assigned）、已准备（prepared）、正在运行（running）等一系列状态单向的前进。如果某个任务未通过健康检查或者终结，任务及其容器被编排器移除，新的副本任务以及对应的容器被创建，以满足期望状态。

Swarm模式底层组件包括了一般性用途的调度器、编排器。服务、任务的抽象实现，不理解容器这个概念。理论上你可以实现在非容器中运行的服务。

下图说明Swarm模式如何接受用户创建服务的请求，如何调度服务：

可以配置服务未悬挂的（pending），这样Swarm中没有节点可以运行该服务的任务。如果你仅仅需要防止服务被部署，只需要Scale到0，而不是尝试让服务进入pending状态。

下列情况下，服务会变为pending：

1. 如果所有节点被paused或者drained，那么新创建的服务会保持pending状态，直到某个节点可用。在实际情况下，第一个可用的节点会获得所有任务
2. 你可以为任务保留一定量的内存，如果Swarm中所有节点都没有足够的内存，则服务保持pending状态

从部署份数的角度来看，服务可以分为复制（replicated）、全局（global）两种。

复制服务，由指定数量的任务构成。全局服务则在每个节点运行单个任务。

Swarm模式下，我们可以使用Docker secrets管理敏感数据。所谓Secret是指一块数据，存放密码、SSH私钥、SSL证书或者其它不应该通过网络传递、明文存放在Dockerfile中的信息。

Compose是用于定义、运行多容器Docker应用程序的工具。通过编辑一个Compose文件，你可以配置应用程序的服务组件，然后，只需要单条命令，你就可以创建、启动所有需要的服务。

使用Compose通常包括以下三大步骤：

1. 使用Dockerfile定义应用程序的环境，以便可以在任何地方重现
2. 在文件docker-compose.yml中定义构成应用的服务组件，以便它们可以在一个隔离的环境下运行
3. 最后，执行

   docker-compose up

    启动整个应用

Compose的典型应用场景包括：

Compose可以在macOS、Windows或者64位Linux上运行。在Linux上的安装步骤可以参考：

sudo curl -L "https://github.com/docker/compose/releases/download/1.11.2/docker-compose-$(uname -s)-$(uname -m)" \
    -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose

# 查看版本
docker-compose --version

使用Docker Machine，你可以：

1. 在Windows或者Mac上安装、运行Docker。在1.12之前，DM是唯一在Windows/Mac上运行Docker的途径，之后这两个平台有了Native的Docker实现
2. 划分/管理多台远程Docker宿主机。可以自动在宿主机上划分虚拟机，并在虚拟机上安装Docker
3. 划分/管理Docker Swarm集群

Docker Machine是一套工具，它允许你在虚拟主机上安装Docker引擎，以及通过docker-machine命令来管理宿主机（Machine，通常是虚拟机，这些虚拟机通常由DM创建）。你可以使用DM在非Linux系统、公司网络、数据中心、云端来创建Docker宿主机。

使用docker-machine命令，你可以启动、查看、停止受管理的宿主机，升级Docker客户端/守护程序。

执行以下命令下载并安装：

curl -L https://github.com/docker/machine/releases/download/v0.10.0/docker-machine-`uname -s`-`uname -m` >/tmp/docker-machine
chmod +x /tmp/docker-machine
sudo cp /tmp/docker-machine /usr/local/bin/docker-machine

# 执行命令查看版本信息
docker-machine version

步骤通常为：

1. 创建一个新的（或者启动既有的）宿主机
2.  切换环境到宿主机
3. 使用Docker客户端创建、载入、管理容器

使用下面的命令创建新的宿主机：

# 在不支持Hyper-V的老Windows下或者在Mac下，使用virtualbox驱动
# 在支持Hyper-V的Windows下，使用hyperv驱动
docker-machine create --driver virtualbox default

注意，在Linux下需要VirtualBox预先被安装。

使用命令

docker-machine ls

使用下面的命令，可以切换环境变量，指向新创建的宿主机：

# 这个命令用于获取环境变量，这些环境变量导致当前Shell的连接目标改变
docker-machine env default
# 输出
# export DOCKER_TLS_VERIFY="1"
# export DOCKER_HOST="tcp://172.16.62.130:2376"
# export DOCKER_CERT_PATH="/home/alex/.docker/machine/machines/default"
# export DOCKER_MACHINE_NAME="default"

# 执行下面的命令，切换到default这台宿主机
eval "$(docker-machine env default)"

现在，你可以针对宿主机进行操作了。要停止或者启动宿主机，可以：

docker-machine stop default
docker-machine start default

你也可以连接到既有的宿主机，好处是，管理这台宿主机是，不需要每次提供URL：

docker-machine create --driver none --url=tcp://10.0.0.1:2376 fedora-10

宿主机必须预先配置，支持基于TLS的连接。 

检查Docker安全性时，有4个主要方面需要考虑：

1. 内核本身的安全性：名字空间的支持、Cgroups
2. Docker守护程序本身的攻击面（attack surface ）
3. 容器配置的漏洞，这些漏洞可能是默认就附带的，或者用户定制而引入的
4. 内核中固化的安全特性，这些特性如何与容器交互

Docker容器与LXC容器很类似，它们具有相似的安全特性。当你启动容器时，Docker会为容器创建一系列的名字空间和控制组。

名字空间提供第一级的、最直接的隔离性——容器中运行的进程看不到，甚至不能影响到其它容器、宿主机中运行的进程。内核名字空间机制从2.6.15 - 2.6.26版本开始引入，目前已经非常稳定。

每个容器具有自身的网络栈（network stack），这意味着容器不具有其它容器套接字、网络接口的访问权限。当然，如果宿主机正确的配置，容器之间可以基于各自的网络接口进行交互，就像与外部主机一样。

Cgroups是Linux容器的另一个关键组件，它实现了资源审计和限额，并提供很多有价值的度量信息。利用控制组，可以让容器获得公平的CPU、内存、磁盘I/O等资源。Cgroups能够有效的防范某些DoS攻击。Cgroups于2.6.24被合并到内核。

通过Docker运行容器，意味着需要运行Docker守护程序，后者需要Root权限。只有受信任用户才应该被允许控制守护程序。

由于Docker允许在宿主机、容器之间共享目录，这意味着容器可能任意的修改宿主机文件系统。

当在服务器上运行Docker时，推荐宿主机仅仅运行Docker，而把所有其它服务（除了SSH服务器这类管理工具）都放在容器中运行。

默认的，Docker以一组受限的能力（capabilities）来启动容器。能力把root/非root划分为细粒度的访问控制系统。需要绑定到1024-端口的进程不再需要root权限，而仅需要被授予net_bind_service能力。

容器也不需要被授予真正的root权限。事实上，容器中的root用户缺陷受到很大的限制，例如：

1. 禁止任何mount操作
2. 禁止访问原始套接字（避免包嗅探）
3. 禁止某些文件系统操作，例如创建新设备节点、修改文件所有权、修改属性
4. 禁止模块加载操作

由于这些限制的存在，即使攻击者获得容器的root权限，也难以进行严重的破坏。

你可以增加、删除容器的能力，以提升功能或安全性。

能力（capabilities）仅仅是现代Linux内核提供的众多安全特性之一。其它已知的著名安全系统包括：TOMOYO、AppArmor、SELinux、GRSEC等，它们都可以和Docker协作。

考虑以下建议：

1. 可以基于GRSEC、PAX来运行内核。这样会增加额外的安全检查（编译时、运行时）并防御很多缺陷。不需要针对Docker的配置，因为这些安全特性是系统级的
2. 如果你使用的发行版提供了针对Docker容器的安全模型模板（security model templates），你可以使用它们
3. 你可以使用某种访问控制系统，定义自己的安全策略

从1.10开始，用户名字空间被Docker直接支持。这一特性允许容器中的root用户直接映射到容器外部的非0 UID的任何用户，进而减少安全风险。这一特性默认没有开启。

默认的，Docker通过非网络化的Unix套接字运行，你也可以基于HTTP套接字与之通信。

如果你期望通过网络安全的访问Docker，应当启用TLS。这样，在守护程序端，仅仅通过CA认证的客户端才允许连接；在客户端，则仅仅允许向通过CA认知的服务器发起连接。

在守护程序上启用TLS的示例：

dockerd --tlsverify --tlscacert=ca.pem --tlscert=server-cert.pem --tlskey=server-key.pem -H=0.0.0.0:2376

在客户端上启用TLS的示例：

docker --tlsverify --tlscacert=ca.pem --tlscert=cert.pem --tlskey=key.pem  -H=127.0.0.1:2376 version

在使用Docker的过程中，我们常常需要从/到Docker Hub或者私服pull/push镜像。内容信任（Content trust）机制允许验证数据的完整性、镜像的发布者，不论你是从什么渠道获得镜像。

内容信任机制可以强制客户端在与远程服务（Hub或私服，registry）交互时，进行客户端签名和镜像Tag验证。该机制默认情况下是禁用的，要启用，可以设置环境变量

DOCKER_CONTENT_TRUST

一旦内容信任被启用，镜像发布者就可以对自己的镜像进行签名。镜像的消费者则可以确保镜像是来自发布者，未经篡改。

每一个镜像记录由以下字段唯一的标识：

[REGISTRY_HOST[:REGISTRY_PORT]/]REPOSITORY[:TAG]

内容信任与TAG部分关联，每个REPOSITORY具有一组供发布者签名镜像TAG的密钥。单个REPOSITORY中可以包含签名、未签名的TAG。对于启用内容信任的消费者，未签名的TAG是不可见的。

子命令push、build、create、pull、run与内容信任机制交互。例如，当你执行docker pull someimage:latest时，仅当someimage:latest被正确签名时，命令才会成功。除了指定TAG，你也可以直接指定签名Hash：

docker pull someimage@sha256:d149ab53f8718e987c3a3024bb8aa0e2caadf6c0328f1d9d850b2a2a67f2819a

与镜像标签信任管理相关的是一系列的签名密钥。当第一次使用到内容信任功能时，密钥被创建。这些密钥包括：

1. 作为内容信任根的离线密钥，该密钥属于发布镜像的组织或个人，必须被客户端妥善的秘密保存，丢弃此密钥将非常难以恢复
2. 签名仓库、标签的密钥，该密钥与一个镜像仓库关联，使用该密钥可以pull/push模板仓库的任何标签，保存在客户端
3. 服务器管理的密钥，例如时间戳密钥。保存在服务器端

除了通过环境变量来全局性的启用内容信任之外，你还可以在调用docker命令时指定

--disable-content-trust

docker build --disable-content-trust -t gmemcc/nottrusttest:latest
docker pull --disable-content-trust gmemcc/nottrusttest:latest
docker push --disable-content-trust gmemcc/nottrusttest:latest

当你第一次推送受信任内容时，Docker会提示你：

1. 警告你，新的root密钥将被创建 
2. 提示输入root密钥的密码
3. 在~/.docker/trust目录生成root密钥
4. 提示输入仓库密钥的密码
5. 在~/.docker/trust目录生成仓库密钥

如果启用内容信任机制，没有被签名的镜像是无法拉取的。

要使用自动化脚本来执行镜像TAG签名，你需要设置环境变量：

1. DOCKER_CONTENT_TRUST_ROOT_PASSPHRASE  根密钥的密码
2. DOCKER_CONTENT_TRUST_REPOSITORY_PASSPHRASE  仓库密钥的密码

参考Engine(docker) CLI。

本质上此命令行通过REST  API和守护程序通信，和守护程序一样。该命令支持HTTP_PROXY、HTTPS_PROXY，并且优先使用后者。

docker build [OPTIONS] PATH | URL | -

docker images [OPTIONS] [REPOSITORY[:TAG]]

docker images             # 列出所有镜像
docker images java        # 列出所有Repository为java的镜像
docker images java:8      # 同时限定Repository和tag

# 删除所有镜像
docker rmi `docker images -q` 

# 删除无标签镜像
docker rmi $(docker images | grep "^<none>" | awk "{print $3}")

docker commit [OPTIONS] CONTAINER [REPOSITORY[:TAG]]

# 提交为镜像，并修改环境变量、入口点、暴露端口
docker commit --change "ENV DEBUG true"  CONTAINER_ID REGISTRY/REPO:TAG
              -c 'CMD ["apachectl", "-DFOREGROUND"]'
              -c 'EXPOSE 80' 

docker run [OPTIONS] IMAGE [COMMAND] [ARG...] 

-e "LIMIT=10"

--expose=7000-8000

# 交互式的运行一个容器，分配伪终端，在退出时删除容器
docker run  -i -t --rm --name=temp ubuntu:14.04
# 指定存储驱动选项
docker run --storage-opt size=120G ubuntu
# 挂载一个虚拟内存文件系统，并指定选项
docker run --tmpfs /run:rw,noexec,nosuid,size=65536K
# 指定环境变量（命令行、文件）
docker run -e NAME=VAL --env-file=path-to-file
# 挂载其它容器定义的卷，指定ro/rw
docker run --volumes-from CONTAINER_ID:rw
# 修改容器hosts文件
docker run --add-host=zircon:10.0.0.1
# 限制容器的资源用量 type=softlimit[:hardlimit]
docker run --ulimit nofile=1024:1024

docker create [OPTIONS] IMAGE [COMMAND] [ARG...]

docker start [OPTIONS] CONTAINER [CONTAINER...]

# 交互式启动容器，并关联当前终端到该容器
docker start -i -a ubuntu

docker stop [OPTIONS] CONTAINER [CONTAINER...]

docker kill [OPTIONS] CONTAINER [CONTAINER...]

docker attach [OPTIONS] CONTAINER

# 执行此命令后，容器进入前台运行
docker attach ubuntu

docker exec -d touch /etc/config

docker rm [OPTIONS] CONTAINER [CONTAINER...]

# 删除所有容器
docker rm `docker ps --no-trunc -aq` 
# 删除所有停止的容器
docker ps --filter "status=exited" --quiet |  xargs --no-run-if-empty docker rm

docker ps [OPTIONS]

# 显示已经退出的所有容器的ID
docker ps --filter "status=exited" --quiet

docker logs [OPTIONS] CONTAINER

# 跟踪日志输出
docker logs -f ubuntu
# 要删除容器的日志，参考如下脚本： Linux only
rm $(docker inspect $1 | grep -G '"LogPath": "*"' | sed -e 's/.*"LogPath": "//g' | sed -e 's/",//g');

docker cp [OPTIONS] CONTAINER:SRC_PATH DEST_PATH|-
docker cp [OPTIONS] SRC_PATH|- CONTAINER:DEST_PATH

docker cp apache2:/usr/lib/php5/20131226 /home/alex/Docker/projects/apache2/usr/lib/php5/ 

docker stats [OPTIONS] [CONTAINER...]

# 列出可用的网络
docker network ls

# 查看网络bridge的详细信息，包括连接到网络的容器信息
docker network inspect bridge

# 将容器连接到已经存在的网络，连接后容器立刻可以和网络中的其它容器通信
docker network connect isolated_nw container2
# 断开容器到网络的连接
# -f表示强制断开，可以解决stale endpoints问题
docker network disconnect -f isolated_nw container2

# 创建一个名为isolated_nw的桥接网络，如果不指定dirver默认使用bridge
docker network create --driver bridge isolated_nw
# 创建网络并提供参数
docker network create --subnet 172.30.0.0/16  \
 --opt com.docker.network.bridge.name=docker_gwbridge \
 --opt com.docker.network.bridge.enable_icc=false \
 docker_gwbridge

# Bridge网络仅支持单个子网，overlay则支持多个
# 强烈建议显式的指定子网

docker network create -d overlay \
 --subnet=192.168.0.0/16 \
 --subnet=192.170.0.0/16 \
 --gateway=192.168.0.100 \
 --gateway=192.170.0.100 \
 --ip-range=192.168.1.0/24 \
 --aux-address="my-router=192.168.1.5" --aux-address="my-switch=192.168.1.6" \
 --aux-address="my-printer=192.170.1.5" --aux-address="my-nas=192.170.1.6" \
 my-multihost-network

# 使用 -o来指定选项
docker network create  \
    -o "com.docker.network.bridge.host_binding_ipv4"="172.23.0.1" my-network

# 移除网络，仅当没有容器连接到网络时，才能移除
docker network rm isolated_nw

# 选项
# -i 指定输入TAR的路径，如果不指定从STDIN读取
docker load [OPTIONS]

# 解压并从标准输入加载
gunzip -c busybox.tar.gz  | docker load

# 选项 -o 指定输出文件路径，不指定则输出到STDOUT
docker save [OPTIONS] IMAGE [IMAGE...]

# 保存到标准输出，然后压缩
docker save busybox:1.30.1 | gzip -c > busybox.tar.gz

# 选项：
# -c 应用Dockerfile指令到新创建的镜像
docker import [OPTIONS] file|URL|- [REPOSITORY[:TAG]]

# 选项 -o 指定输出文件路径，不指定则输出到STDOUT
docker export [OPTIONS] CONTAINER

docker swarm init [OPTIONS]

docker swarm join [OPTIONS] HOST:PORT

docker swarm join-token [-q] [--rotate] (worker|manager)

docker swarm update [OPTIONS]

docker swarm leave [OPTIONS]

docker node demote NODE [NODE...]

docker node inspect [OPTIONS] self|NODE [NODE...]

docker node ls [OPTIONS]

docker node promote NODE [NODE...]

docker node rm [OPTIONS] NODE [NODE...]

docker node ps [OPTIONS] self|NODE

docker node update [OPTIONS] NODE

docker service create [OPTIONS] IMAGE [COMMAND] [ARG...]

docker service inspect [OPTIONS] SERVICE [SERVICE...]

docker service ps [OPTIONS] SERVICE

docker service ls [OPTIONS]

docker service rm [OPTIONS] SERVICE [SERVICE...]

docker service scale SERVICE=REPLICAS [SERVICE=REPLICAS...] 

docker service update [OPTIONS] SERVICE

docker volume create [OPTIONS] [VOLUME]

# 创建一个名为hello的卷
docker volume create hello
# 创建一个100MB的tmpfs卷
docker volume create --driver local --opt type=tmpfs \
    --opt device=tmpfs --opt o=size=100m,uid=1000  foo
# 创建一个映射到NFS服务192.168.1.1的/path/to/dir目录的卷
docker volume create --driver local --opt type=nfs \
    --opt o=addr=192.168.1.1,rw--opt device=:/path/to/dir foo

# 挂载卷到容器的/world目录，注意挂载点必须是绝对路径
docker run -d -v hello:/world busybox ls /world

docker volume inspect [OPTIONS] VOLUME [VOLUME...]

docker volume ls [OPTIONS]

docker volume prune [OPTIONS]

docker volume rm [OPTIONS] VOLUME [VOLUME...]

docker manifest inspect [OPTIONS] [MANIFEST_LIST] MANIFEST

// 查看镜像的清单，获取os_arch信息
// docker manifest inspect hello-world --verbose
{
        "Ref": "docker.io/library/hello-world:latest",
        "Digest": "sha256:f3b3b28a45160805bb16542c9531888519430e9e6d6ffc09d72261b0d26ff74f",
        "SchemaV2Manifest": {
                "schemaVersion": 2,
                "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
                "config": {
                        "mediaType": "application/vnd.docker.container.image.v1+json",
                        "size": 1520,
                        "digest": "sha256:1815c82652c03bfd8644afda26fb184f2ed891d921b20a0703b46768f9755c57"
                },
                "layers": [
                        {
                                "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                                "size": 972,
                                "digest": "sha256:b04784fba78d739b526e27edc02a5a8cd07b1052e9283f5fc155828f4b614c28"
                        }
                ]
        },
        "Platform": {
                "architecture": "amd64",
                "os": "linux"
        }
} 

${HOME}/.docker/manifests/$(REGISTRY_DOMAIN)_$(REGISTRY_PREFIX)_$(IMAGE)-$(VERSION)

docker manifest create MANIFEST_LIST MANIFEST [MANIFEST...]

# 你需要指定一组成员镜像，来创建清单列表
#                      清单列表名字，任何平台的客户端都使用该名字拉取镜像
docker manifest create docker.gmem.cc/coolapp:v1 \
    docker.gmem.cc/coolapp-ppc64le-linux:v1 \
    docker.gmem.cc/coolapp-arm-linux:v1 \
    docker.gmem.cc/coolapp-amd64-linux:v1 \
    docker.gmem.cc/coolapp-amd64-windows:v1 

docker manifest annotate [OPTIONS] MANIFEST_LIST MANIFEST

# 将清单列表中的某个镜像的体系结构标注为arm
docker manifest annotate docker.gmem.cc/coolapp:v1 \
  docker.gmem.cc/coolapp-arm-linux --arch arm

docker manifest push [OPTIONS] MANIFEST_LIST

docker manifest push docker.gmem.cc/coolapp:v1 

{
  "live-restore": true,
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "50m",
    "max-file": "5"
  }
}

Docker通过libnetwork实现了此模型，CNM的架构如下：

其中：

1. 网络沙盒：提供容器的网络栈，包括网络接口、路由表、DNS配置、Iptables等。实现技术包括Linux网络命名空间、FreeBSD Jail等
2. 每个沙盒中可以包含来自多个网络的端点（Endpoint），端点是连接网络沙盒和后端网络的桥梁，实现技术包括Veth对、tap/tun设备、OVS内部端口等
3. 容器网络（Backend Network）：一组可以相互通信的端点的集合。对应的实现技术可以是Linux Bridge、VLAN等

此外，CNM还依赖于另外两个对象来完成Docker网络管理：

1. Network Controller：对外提供分配、管理网络的APIs
2. Drivers：负责一种网络的管理，包括IPAM

CNM的原生实现是Libnetwork，是Docker团队从Docker核心中分离出来的网络相关功能。

默认情况下，Docker使用Veth对的方案：

1. 创建一个docker0网桥，如果没有容器运行，则此网桥是down状态
2. 创建一个Veth对，一端接到网桥docker0，另外一端放在容器网络命名空间中，作为eth0
3. 属于同一网络的容器，都会连接到docker0，因此可以相互通信

隧道网络也叫overlay网络，在IaaS网络中就被大量使用。

优势：几乎不依赖基础网络架构，只要3层互联即可。

劣势：

1. 随着节点规模的增加，复杂度随之升高
2. 封包二次包装，网络问题定位麻烦，而且影响性能

基于覆盖网络的插件包括：

1. Weave，基于VXLAN
2. Open vSwitch（OVS）：基于VXLAN + GRE，性能方面损失较为严重
3. flannel：支持自研UDP封包（性能较差，性能损失50%+），以及Linux内核的VXLAN（性能损失20-30%）

隧道方案解决的问题是，主机之间无法直接传递容器IP的封包。如果解决路由的问题，就可以避免二次包装的性能损失。

基于路由的方案包括：

1. Calico，基于BGP，支持细致的ACL控制，混合云友好
2. Macvlan，隔离性好，性能最优，需要二层网络，大多数云服务商不支持，难以实现混合云
3. Metaswitch，容器内部分配一个路由只想宿主机地址，性能接近原生

位置在：/run/containerd/io.containerd.runtime.v1.linux/moby/$CONTAINER_ID/config.json

如果容器正在运行，可以通过nsenter进入。

如果容器已经死掉，可以通过命令：

docker inspect 3b7227ffdb88 | grep UpperDir

得到UpperDir，然后进入UpperDir，即可在tmp子目录中看到容器修改后的/tmp目录的内容。 

老版本Ubuntu：

/var/log/upstart/docker.log

使用Systemd的：

sudo journalctl -fu docker.service

CentOS：

/var/log/daemon.log | grep docker

DOCKER_OPTS=" -H 10.0.0.1:2376 -H unix:///var/run/docker.sock"
# 测试 docker -H 10.0.0.1:2376 ps

要让启动的容器自动设置代理环境变量，可以：

{
    "proxies": {
        "default": {
                "httpProxy": "http://10.0.0.1:8087",
                "httpsProxy": "http://10.0.0.1:8087",
                "noProxy": "localhost,127.0.0.1,172.21.*,172.17.*,172.27.*,192.168.*,10.0.*"
            }
        }
    }
}

然后启动容器，你就可以看到对应的环境变量了.

docker pull等操作是发生在守护进程中的，需要按此节的说明设置

必须配置Docker的配置文件，命令行直接设置代理无效：

# Ubuntu适用
export http_proxy="http://10.0.0.1:8088"
export https_proxy="http://10.0.0.1:8088"

如果使用Fedora，则：

mkdir -p /etc/systemd/system/docker.service.d

[Service]
Environment="HTTP_PROXY=http://10.0.0.1:8088/"

 刷出变更并重启服务：

systemctl daemon-reload
systemctl restart docker

可能原因是没有登陆到私服

报错信息：certificate has expired or is not yet valid docker

如果测试wget/curl等命令没问题，可能是由于Docker使用的代理导致。

由于NAT（Docker端口映射）导致。默认情况下Docker使用用于空间代理docker-proxy来处理NAT，性能较低。可以设置dockerd参数禁用：

dockerd ... --userland-proxy=false

Mac OS下可能存在此问题，解决方案：

docker run -v /Users/alex/project:/project:cached alpine command

进行docker login时出现此错误，可以把目标仓库的证书拷贝到

/etc/docker/certs.d/

如果使用Let's Encrypt签名的证书，务必使用完整证书链。

在CentOS下，启动firewalld后，新创建Docker容器并进行端口映射会出现此错误。重启Docker即可。

如果无法在宿主机上通过

ip netns list

ln -s /var/run/docker/netns  /var/run/netns  

从1.12开始支持，该参数可以直接传递sysctl变量：

docker run --sysctl net.ipv4.ip_forward=1

用于配置命名空间化的内核参数（namespaced kernel parameters）。 

注意，仅仅被Docker加入白名单的内核参数可以调整，否则你会收到错误：sysctl '***' is not whitelisted。白名单包括：

1. kernel.sem、kernel.shmall、kernel.shmmax、kernel.shmmni、kernel.shm_rmid_forced
2. fs.mqueue.***
3. net.***

此外，被调整的内核参数还必须是：

1. 在容器中可见，例如net.core.rmem_max
2. 支持命名空间化，有些配置是全局的，不支持命名空间化

如果使用--net=host，则使用宿主机的网络栈，直接使用宿主机的内核参数，不需要特殊操作。

sudo rm /var/lib/docker/aufs -rf

原因未知，可能和Docker的NAT存在问题，重启Docker后解决。

访问某通过LVS暴露的接口，20%几率出现Connection Reset By Peer。进一步检查发现：

1. 此问题和Docker本身无关，但凡客户端通过NAT访问的，都有几率出现
2. curl测试，有几率出现卡死，但是目标接口速度很快

当卡死时，最终提示：curl: (56) Recv failure: Connection timed out，Docker宿主机抓包如下：

可以看到发送HTTP请求后，出现重传，随后即RST。LVS发来的TCP Dup ACK中的SLE、SRE（选择性ACK时，已经Ack的字节范围，提示对方不再传输这些范围的数据）很不正常。在客户端禁用SACK后，问题消失：

net.ipv4.tcp_sack = 0
net.ipv4.tcp_dsack = 0
net.ipv4.tcp_fack = 0 

值得注意的是：在NATed的客户端来看，是服务器主动RST，在NAT设备来看，是它主动RST，并谎报给NATed客户端说服务器进行了重置。

可能是DNS配置错误导致的，执行以下步骤修复： 

1. 修改/etc/default/docker，设置正确的Docker守护程序选项，例如：

   DOCKER_OPTS="--dns 178.79.131.110 --dns 8.8.8.8"

    
2. 重启Docker守护程序：

   sudo service docker restart

    
3. 重新构建，指定no-cache选项，强制Docker镜像重新获取DNS：

   docker build --no-cache=true ...

     

RUN rm /etc/localtime && ln -s /usr/share/zoneinfo/Asia/Shanghai /etc/localtime

部分基础镜像没有/usr/share/zoneinfo目录，需要手工拷贝/etc/localtime文件

两个简单原则：

1. 能够处理挂断信号。需要注意，docker stop / docker kill只会向PID为1的容器进程发送信号
2. 能够阻止脚本退出

示例：

#!/usr/bin/env bash

# 捕获挂断信号，执行清理
sighdl() {
    service myservice stop
    TERM_FLAG=1
}
trap sighdl HUP INT PIPE QUIT TERM

# 启动服务
service myservice start

# 防止脚本退出的命令
while [ "$TERM_FLAG" != "1" ] ; do :; done

如果防止脚本退出的命令调用了其它程序，例如：

tail -f /var/log/myservice.log

一个生产环境中入口点脚本的例子：Kurento的入口点脚本

层次过多的文件系统，不但访问效率较低，而且占用更大的磁盘空间。可以export容器并import为镜像，这样产生的镜像只有一个层次：

docker export container-name | docker import - image:tag 

在管理节点上预先登录到Docker Hub或者私服，然后：

docker service create --with-registry-auth   # 添加该选项
  --replicas 10 --network overlay --name ping docker.gmem.cc/ubuntu:14.04 ping 10.0.0.1

有些情况下，因为配置错误，容器启动后立即退出。如果想通过Shell交互式的查问题，可以：

# 提交为临时镜像
docker commit mongo-c6 tempimg

# 使用Bash作为入口点进入
docker run --entrypoint=bash -it --rm  tempimg

# 解决完问题后，删除临时镜像
docker rmi tempimg

# 列出孤儿卷
docker volume ls -qf dangling=true

# 删除所有孤儿卷
docker volume rm $(docker volume ls -qf dangling=true)

使用

docker -v

1. 自动以root身份创建不存在的目录
2. 容器中目录的所有者为root，即使目录本来存在（而被覆盖）且所有者不是root

这种行为会导致潜在的无权访问的问题。

解决办法：容器中的用户，和宿主机的用户，以ID对应。因此，你可以预先创建宿主机目录，并chown给容器中需要使用此目录的用户的ID。 

最好确保你的应用程序的PID为1，如果Entrypoint Spawn的子进程中运行应用程序，则Entrypoint必须能够捕获信号并执行适当的命令来停止应用程序进程。

无法捕获信号的常见原因：

1. 使用了Shell风格的Entrypoint，这种情况下，入口点变为/bin/sh的子进程，无法收到信号。你需要：
   

   # 不要用这种形式
   ENTRYPOINT "/entrypoint.sh" arg1 arg2
   # 用下面的形式
   ENTRYPOINT ["/entrypoint.sh", "arg1", "arg2"]

2. 入口点调用了应用程序，但是没有替换当前进程。你需要以exec方式调用目标应用程序，例如：
   

   exec /jdk/bin/java $JAVA_OPTS -cp app.jar $JAVA_MAIN_CLASS $JAVA_MAIN_ARGS

3. 虽然使用exec替换进程，但是不是替换入口点进程。例如引入了管道：

   # 这会导致在子Shell中进行
   exec java | grep ... 

4. 可能没有捕获信号并正确处理

报错：OCI runtime create failed: container_linux.go:348: starting container process caused "process_linux.go:297: copying bootstrap data to pipe caused \"write init-p: broken pipe\"": unknown

解决办法：

sudo apt-get install docker-ce=18.06.1~ce~3-0~ubuntu

以Alpine作为基础镜像，运行动态链接的Go应用程序，出现此报错。

原因是，应用程序动态链接到了 GNU libc。Alpine的musl libc库提供了对GNU libc的部分兼容性，可用于尝试解决此问题：

apk add libc6-compat

Docker配置信息可能位于：

1. /usr/lib/systemd/system/docker.service

Docker服务相关命令：

systemctl daemon-reload
systemctl restart docker 

apt-get install software-properties-common

The post Docker学习笔记 appeared first on 绿色记忆.

Hypervisor，即虚拟机监管程序（virtual machine monitor ，VMM）。它可以是电脑上的软件、固件或者硬件，用于建立和执行虚拟机。拥有Hypervisor后，你可以执行一个或者多个虚拟机。这些虚拟机称为客户机（guest machine），相应的Hypervisor所在机器称为宿主机（host machine）。

传统的虚拟化技术都是基于Hypervisor的，它们被分为两类：

1. bare-metal Hypervisor：裸机监管程序，直接运行在硬件上
2. Hosted Hypervisor：被宿主监管程序，Hypervisor运行在操作系统之上，就像一个应用程序一样

X86处理器定义了定义了0-3个特权级，数字越小，权限越高。

对于Linux来说，在没有虚拟化的情况下，内核态对应了0级，用户态对应3级。

传统的虚拟化技术都是在宿主机、客户机之间加一个Hypervisor。因此，当在Linux上运行Linux虚拟机时，两个内核都需要运行在0级。根据解决此冲突（对于Host来说整个Client是用户程序）的方式的不同，虚拟化被分为3种类型：

KVM，即基于内核的虚拟机（Kernel-based Virtual Machine），是构建于支持虚拟化扩展（Intel VT 或者 AMD-V）的x86平台、Linux操作系统之上的，完整虚拟化解决方案。使用KVM，你可以运行多个Linux或者Windows系统镜像，这些虚拟机拥有私有的虚拟化设备，包括网卡、磁盘、显卡等。

KVM主要包含两个内核组件：

1. 可加载的内核模块 kvm.ko，负责核心的虚拟化基础功能
2. 针对处理器的模块：kvm-intel.ko或者kvm-amd.ko

从2.6.20版本的Linux内核开始，KVM的内核组件就被包含在其中。从QEMU 1.3开始，KVM的用户空间组件被包含在其中。要查看你的机器是否支持KVM，可以执行：

lsmod | grep kvm

QEMU是一个基于通用目的开源仿真器/虚拟器软件。它可以模拟：

1. CPU
2. Intel e1000 PCI等网卡
3. 基于PCI IDE接口的硬盘、光驱
4. 软驱
5. 串口
6. AC97兼容声卡以及其它声卡
7. PS/2 键盘鼠标
8. VGA显卡

等多种外围设备。QEMU最多支持255 CPU的SMP。

当作为仿真器（Emulator，模拟器）使用时，它可以在真实机器（例如你的x86_64台式机）上模拟一台机器 + 操作系统 + 程序，而这台模拟的机器的体系结构（例如ARM板）与宿主机器不同。

而作为虚拟器（Virtualizer）使用时，它可以在宿主机器上直接执行客户机（虚拟机）的代码，因而虚拟机的性能接近于宿主机。QEMU通过下列方式之一来支持虚拟化：

1. 在XEN监管程序（Hypervisor）之上执行
2. 在支持KVM的Linux操作系统下运行。使用KVM时QEMU可以虚拟化x86、PowerPC、S390客户机

注意Emulator和Virtualizer的区别，最重要的一点是客户机的代码是直接执行（意味着宿主和客户机体系结构兼容），还是模拟执行，后者的效率要低得多。很多同学喜欢在PC上玩街机游戏，这也是通过模拟器（例如Winkawaks）实现的。

和Vmware、VirtualBox 之类的虚拟机管理软件不同，QEMU不提供图形化的管理界面。你可以使用第三方的图形前端，例如qtemu，但是命令行的丰富性让QEMU更适合在服务器上使用。

单纯靠QEMU来模拟一系列硬件，因为存在指令转译，性能一般很差。而KVM可以基于Intel-VT、AMD-V实现硬件辅助的CPU虚拟化，客户机指令直接在真实CPU上运行。因此结合KVM可以很好的提高QEMU的CPU性能。另一方面KVM仅仅提供CPU的虚拟化，它无法构建一台完整的虚拟机。因此QEMU和KVM整合的需求就很明显了。

qemu-kvm项目就是来整合QEMU和KVM的，此项目在1.3.0版本开始正式合并到QEMU项目的master上。qemu-kvm（qemu-system-***）利用ioctl调用/dev/kvm，将有关CPU的部分交由KVM去做。

如果KVM内核模块存在、且CPU支持，你可以通过下面的选项启用KVM支持：

# 启用基于KVM的虚拟化加速
-enable-kvm

CPU的性能问题解决了，但是QEMU模拟的其它硬件也存在同样的低效问题，于是Virtio被引入了。

Virtio是libvirt的一部分，它是一个关于网络、磁盘等设备的虚拟化标准，在此标准中客户机的设备驱动知道自己运行在虚拟化环境中，因而这些驱动可以和Hypervisor进行直接交互，获得接近于Native驱动的性能。

较新版本的Linux发行版都已经把Virtio编译进内核，因而客户机可以直接使用Virtio驱动。

KVM和XEN都是基于Hypervisor的虚拟化技术。它们的区别包括：

1. Xen是裸机监管程序，而KVM某种程度上把Linux内核变成了Hosted Hypervisor
2. Xen的整体性能高于KVM，但是I/O略差
3. KVM要求CPU必须支持虚拟化技术，但Xen则没有此限制。这个限制在当前的硬件条件下，基本不是问题
4. KVM的优势是它对Linux内核的整合程度，KVM本质上就是一个内核模块，因此你可以很容易的升级内核

VirtualBox是标准的2类Hypervisor，KVM与它的区别包括：

1. VirtualBox它与商用软件Vmware Workstation一样，都以图形界面为主，适合个人用户。但是在商用环境下，大部分虚拟机都是Headless的（不需要图形界面），此时VirtualBox的GUI则是劣势，GUI浪费了资源
2. VirtualBox支持大量的宿主操作系统，例如Windows、Linux、Mac OS X。而KVM显然仅支持Linux
3. 一般情况下，轻量级的KVM的性能要比VirtualBox好的多

LXC即Linux容器（Containers），这是一种操作系统层（传统虚拟机是硬件层）虚拟化技术，要由liblxc库及其多语言绑定、一系列控制容器的工具组成。LXC将整个应用，包括：软件本身代码、所需库、支撑软件，打包为一个“容器”。通过Linux内核的特性，可以实现容器与系统之间的隔离，这些特性包括：

1. 内核命名空间（IPC、uts、mount、pid、network、user）
2. Apparmor（限制每个应用程序访问的资源）和SELinux配置
3. Seccomp（提供应用程序沙盒机制）策略
4. Chroots（通过pivot_root调用）
5. cgroups，即控制组（control groups），用来限制、控制、分离进程组的资源（CPU、内存、磁盘等），此特性最初的名字就叫“进程容器”

通过LXC，你可以创建尽可能接近标准Linux的环境，同时不需要独立的内核。

基于LXC的虚拟化技术和KVM相比，区别如下：

1. LXC的优势在于轻量化和高性能，但是隔离性不高
2. LXC支持任何体系结构，例如x86、ARM、PowerPC等

LXD基于LXC，可以认为是一个Container的Hypervisor，LXD一般创建自包含的操作系统用户空间。也就是说，LXD容器内运行的是一个操作系统，虽然存在用户空间和内核空间隔离，但是这个操作系统和宿主系统共享一个内核。

有测试数据表明：LXD相比KVM可以减少50+%的延迟；LXD启动实例的速度比KVM块90+%

近年来非常流行的容器软件，与LXD最大的不同是，Docker打包应用程序+自包含的文件系统，而不是操作系统用户空间。每个Docker容器，仅仅包含一个应用程序。曾经Docker也是基于lxc技术的，但是现在它使用自己的库ibcontainer。

Docker中的文件系统、网络都是抽象的，而LXD直接使用宿主机的文件系统、网络，LXD可以方便的设置IP地址。

Docker比起LXD更加轻量，可以实现更高的部署密度。

大部分的Linux发行版已经内置了KVM内核模块以及用户空间工具，使用这些内置组件是最容易、推荐的方式：

1. KVM内核模块现在是Linux内核的一部分，除非你使用的是精简过的内核
2. 用户空间组件，软件包名称一般是qemu-kvm或者kvm，例如：
   1. Ubuntu下可以执行

      apt-get install qemu-kvm

       安装
   2. CentOS下可以执行

      yum install kvm

      安装
3. 客户机驱动：Linux客户机的驱动包含在内核中；Windows客户机的驱动需要下载

安装QEMU的依赖包：

sudo apt-get install gcc libsdl1.2-dev zlib1g-dev libasound2-dev linux-kernel-headers pkg-config libgnutls-dev libpci-dev

下载用户空间组件： 

1. QEMU 1.3或者更老版本的，在Sourceforge下载
2. 新版本，在QEMU官网下载

注意：2.6.29以上版本的内核，可以和任何版本的qemu-kvm搭配使用。

tar xzf qemu-kvm-release.tar.gz
cd qemu-kvm-release
./configure --prefix=/usr/local/kvm
make
sudo make install

如果你使用旧版本内核，或者内核精简了KVM，则需要此步骤：

tar xjf kvm-kmod-release.tar.bz2
cd kvm-kmod-release 
./configure
make 
sudo make install

# 对于Intel CPU
sudo /sbin/modprobe kvm-intel
# 对于AMD CPU
sudo /sbin/modprobe kvm-amd

从3.0.0开始QEMU的版本大跃进，每年major版本增加1，目前已经是5.x版本。

wget https://download.qemu.org/qemu-5.1.0.tar.xz
tar xvJf qemu-5.1.0.tar.xz 
cd qemu-5.1.0/
./configure
make

./configure --help

# 方括号中是默认值

Standard options:
  --prefix=PREFIX          install in PREFIX [/usr/local]
  --interp-prefix=PREFIX   where to find shared libraries, etc.
                           use %M for cpu name [/usr/gnemul/qemu-%M]
  # 目标列表，默认所有
  # xxx-softmmu 生成qemu-system-xxx，用于运行xxx架构下的虚拟机
  # xxx-linux-user 生成qemu-xxx，用于模拟运行xxx架构下的应用程序，可以配合binfmt_misc和Docker联用
  --target-list=LIST       set target list (default: build everything)
                           Available targets: aarch64-softmmu alpha-softmmu 
                           arm-softmmu avr-softmmu cris-softmmu hppa-softmmu 
                           i386-softmmu lm32-softmmu m68k-softmmu 
                           microblazeel-softmmu microblaze-softmmu 
                           mips64el-softmmu mips64-softmmu mipsel-softmmu 
                           mips-softmmu moxie-softmmu nios2-softmmu 
                           or1k-softmmu ppc64-softmmu ppc-softmmu 
                           riscv32-softmmu riscv64-softmmu rx-softmmu 
                           s390x-softmmu sh4eb-softmmu sh4-softmmu 
                           sparc64-softmmu sparc-softmmu tricore-softmmu 
                           unicore32-softmmu x86_64-softmmu xtensaeb-softmmu 
                           xtensa-softmmu aarch64_be-linux-user 
                           aarch64-linux-user alpha-linux-user armeb-linux-user 
                           arm-linux-user cris-linux-user hppa-linux-user 
                           i386-linux-user m68k-linux-user 
                           microblazeel-linux-user microblaze-linux-user 
                           mips64el-linux-user mips64-linux-user 
                           mipsel-linux-user mips-linux-user 
                           mipsn32el-linux-user mipsn32-linux-user 
                           nios2-linux-user or1k-linux-user 
                           ppc64abi32-linux-user ppc64le-linux-user 
                           ppc64-linux-user ppc-linux-user riscv32-linux-user 
                           riscv64-linux-user s390x-linux-user sh4eb-linux-user 
                           sh4-linux-user sparc32plus-linux-user 
                           sparc64-linux-user sparc-linux-user 
                           tilegx-linux-user x86_64-linux-user 
                           xtensaeb-linux-user xtensa-linux-user
  --target-list-exclude=LIST exclude a set of targets from the default target-list

Advanced options (experts only):
  --cross-prefix=PREFIX    use PREFIX for compile tools []
  --cc=CC                  use C compiler CC [cc]
  --iasl=IASL              use ACPI compiler IASL [iasl]
  --host-cc=CC             use C compiler CC [cc] for code run at
                           build time
  --cxx=CXX                use C++ compiler CXX [c++]
  --objcc=OBJCC            use Objective-C compiler OBJCC [cc]
  --extra-cflags=CFLAGS    append extra C compiler flags QEMU_CFLAGS
  --extra-cxxflags=CXXFLAGS append extra C++ compiler flags QEMU_CXXFLAGS
  --extra-ldflags=LDFLAGS  append extra linker flags LDFLAGS
  --cross-cc-ARCH=CC       use compiler when building ARCH guest test cases
  --cross-cc-flags-ARCH=   use compiler flags when building ARCH guest tests
  --make=MAKE              use specified make [make]
  --install=INSTALL        use specified install [install]
  --python=PYTHON          use specified python [/usr/bin/python3]
  --sphinx-build=SPHINX    use specified sphinx-build []
  --smbd=SMBD              use specified smbd [/usr/sbin/smbd]
  --with-git=GIT           use specified git [git]
  --static                 enable static build [no]
  --mandir=PATH            install man pages in PATH
  --datadir=PATH           install firmware in PATH/qemu
  --docdir=PATH            install documentation in PATH/qemu
  --bindir=PATH            install binaries in PATH
  --libdir=PATH            install libraries in PATH
  --libexecdir=PATH        install helper binaries in PATH
  --sysconfdir=PATH        install config in PATH/qemu
  --localstatedir=PATH     install local state in PATH (set at runtime on win32)
  --firmwarepath=PATH      search PATH for firmware files
  --efi-aarch64=PATH       PATH of efi file to use for aarch64 VMs.
  --with-confsuffix=SUFFIX suffix for QEMU data inside datadir/libdir/sysconfdir [/qemu]
  --with-pkgversion=VERS   use specified string as sub-version of the package
  --enable-debug           enable common debug build options
  --enable-sanitizers      enable default sanitizers
  --enable-tsan            enable thread sanitizer
  --disable-strip          disable stripping binaries
  --disable-werror         disable compilation abort on warning
  --disable-stack-protector disable compiler-provided stack protection
  --audio-drv-list=LIST    set audio drivers list:
                           Available drivers: oss alsa sdl pa
  --block-drv-whitelist=L  Same as --block-drv-rw-whitelist=L
  --block-drv-rw-whitelist=L
                           set block driver read-write whitelist
                           (affects only QEMU, not qemu-img)
  --block-drv-ro-whitelist=L
                           set block driver read-only whitelist
                           (affects only QEMU, not qemu-img)
  --enable-trace-backends=B Set trace backend
                           Available backends: dtrace ftrace log simple syslog ust
  --with-trace-file=NAME   Full PATH,NAME of file to store traces
                           Default:trace-<pid>
  --disable-slirp          disable SLIRP userspace network connectivity
  --enable-tcg-interpreter enable TCG with bytecode interpreter (TCI)
  --enable-malloc-trim     enable libc malloc_trim() for memory optimization
  --oss-lib                path to OSS library
  # 为指定CPU构建
  --cpu=CPU                Build for host CPU [x86_64]
  --with-coroutine=BACKEND coroutine backend. Supported options:
                           ucontext, sigaltstack, windows
  --enable-gcov            enable test coverage analysis with gcov
  --gcov=GCOV              use specified gcov [gcov]
  --disable-blobs          disable installing provided firmware blobs
  --with-vss-sdk=SDK-path  enable Windows VSS support in QEMU Guest Agent
  --with-win-sdk=SDK-path  path to Windows Platform SDK (to build VSS .tlb)
  --tls-priority           default TLS protocol/cipher priority string
  --enable-gprof           QEMU profiling with gprof
  --enable-profiler        profiler support
  --enable-debug-stack-usage
                           track the maximum stack usage of stacks created by qemu_alloc_stack
  --enable-plugins
                           enable plugins via shared library loading
  --disable-containers     don't use containers for cross-building
  --gdb=GDB-path           gdb to use for gdbstub tests [/usr/bin/gdb]

Optional features, enabled with --enable-FEATURE and
disabled with --disable-FEATURE, default is enabled if available:

  system          all system emulation targets
  user            supported user emulation targets
  linux-user      all linux usermode emulation targets
  bsd-user        all BSD usermode emulation targets
  docs            build documentation
  guest-agent     build the QEMU Guest Agent
  guest-agent-msi build guest agent Windows MSI installation package
  pie             Position Independent Executables
  modules         modules support (non-Windows)
  module-upgrades try to load modules from alternate paths for upgrades
  debug-tcg       TCG debugging (default is disabled)
  debug-info      debugging information
  sparse          sparse checker
  safe-stack      SafeStack Stack Smash Protection. Depends on
                  clang/llvm >= 3.7 and requires coroutine backend ucontext.

  gnutls          GNUTLS cryptography support
  nettle          nettle cryptography support
  gcrypt          libgcrypt cryptography support
  auth-pam        PAM access control
  sdl             SDL UI
  sdl-image       SDL Image support for icons
  gtk             gtk UI
  vte             vte support for the gtk UI
  curses          curses UI
  iconv           font glyph conversion support
  vnc             VNC UI support
  vnc-sasl        SASL encryption for VNC server
  vnc-jpeg        JPEG lossy compression for VNC server
  vnc-png         PNG compression for VNC server
  cocoa           Cocoa UI (Mac OS X only)
  virtfs          VirtFS
  mpath           Multipath persistent reservation passthrough
  xen             xen backend driver support
  xen-pci-passthrough    PCI passthrough support for Xen
  brlapi          BrlAPI (Braile)
  curl            curl connectivity
  membarrier      membarrier system call (for Linux 4.14+ or Windows)
  fdt             fdt device tree
  kvm             KVM acceleration support
  hax             HAX acceleration support
  hvf             Hypervisor.framework acceleration support
  whpx            Windows Hypervisor Platform acceleration support
  rdma            Enable RDMA-based migration
  pvrdma          Enable PVRDMA support
  vde             support for vde network
  netmap          support for netmap network
  linux-aio       Linux AIO support
  linux-io-uring  Linux io_uring support
  cap-ng          libcap-ng support
  attr            attr and xattr support
  vhost-net       vhost-net kernel acceleration support
  vhost-vsock     virtio sockets device support
  vhost-scsi      vhost-scsi kernel target support
  vhost-crypto    vhost-user-crypto backend support
  vhost-kernel    vhost kernel backend support
  vhost-user      vhost-user backend support
  vhost-vdpa      vhost-vdpa kernel backend support
  spice           spice
  rbd             rados block device (rbd)
  libiscsi        iscsi support
  libnfs          nfs support
  smartcard       smartcard support (libcacard)
  libusb          libusb (for usb passthrough)
  live-block-migration   Block migration in the main migration stream
  usb-redir       usb network redirection support
  lzo             support of lzo compression library
  snappy          support of snappy compression library
  bzip2           support of bzip2 compression library
                  (for reading bzip2-compressed dmg images)
  lzfse           support of lzfse compression library
                  (for reading lzfse-compressed dmg images)
  zstd            support for zstd compression library
                  (for migration compression and qcow2 cluster compression)
  seccomp         seccomp support
  coroutine-pool  coroutine freelist (better performance)
  glusterfs       GlusterFS backend
  tpm             TPM support
  libssh          ssh block device support
  numa            libnuma support
  libxml2         for Parallels image format
  tcmalloc        tcmalloc support
  jemalloc        jemalloc support
  avx2            AVX2 optimization support
  avx512f         AVX512F optimization support
  replication     replication support
  opengl          opengl support
  virglrenderer   virgl rendering support
  xfsctl          xfsctl support
  qom-cast-debug  cast debugging support
  tools           build qemu-io, qemu-nbd and qemu-img tools
  bochs           bochs image format support
  cloop           cloop image format support
  dmg             dmg image format support
  qcow1           qcow v1 image format support
  vdi             vdi image format support
  vvfat           vvfat image format support
  qed             qed image format support
  parallels       parallels image format support
  sheepdog        sheepdog block driver support
  crypto-afalg    Linux AF_ALG crypto backend driver
  capstone        capstone disassembler support
  debug-mutex     mutex debugging support
  libpmem         libpmem support
  xkbcommon       xkbcommon support
  rng-none        dummy RNG, avoid using /dev/(u)random and getrandom()
  libdaxctl       libdaxctl support

要创建虚拟机，首先要创建一个虚拟磁盘，然后从光驱启动此虚拟机：

mkdir -p ~/Vmware/KVM

# 以qcow2格式创建一个16G的虚拟磁盘，注意，默认不会预先分配空间
qemu-img create -f qcow2 ~/Vmware/KVM/centos7-base.img 16G

# 指定光盘镜像，从光驱启动虚拟机
# -hda 第一块硬盘的镜像
# -cdrom 光驱的镜像，你可以把宿主的/dev/cdrom传入，这样可以使用物理光驱
# -boot 指定启动顺序，d表示第一个光驱，c表示第一块硬盘
# -m 为虚拟机分配多少内存，默认单位M，默认128M
qemu-system-x86_64 -enable-kvm -hda ~/Vmware/KVM/centos7-base.img  -boot d -m 512
                   -cdrom ~/Software/OS/CentOS-7-x86_64-Minimal-1503-01.iso

上述命令执行完毕之后，会弹出一个窗口，该窗口相当于虚拟机的显示器。你可以在其中完成操作系统的安装。安装完毕后，执行下面的命令，即可启动虚拟机：

qemu-system-x86_64 -enable-kvm -hda ~/Vmware/KVM/centos7-base.img -m 512

后续几个章节，我们深入学习客户机硬件的定制，以满足不同应用场景的需要、提高客户机的性能。

使用选项

-cpu

qemu-system-x86_64 -cpu help

你可以这样配置一个CPU：

-cpu SandyBridge,+erms,+smep,+fsgsbase,+pdpe1gb,+rdrand,+f16c,+osxsave,+dca,+pcid,+pdcm,\
     +xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme

+表示启用CPU特性，如果要禁用CPU特性，可以使用

-

所谓对称多处理（Symmetrical Multi-Processing） ，是指在一个计算机上汇集了一组处理器，各处理器共享内存子系统以及总线结构。在PC机上QEMU最多可以模拟255个CPU。

你可以这样配置SMP：

-smp 1,sockets=1,cores=1,threads=1

你可以在宿主机上创建一个磁盘镜像文件，然后供客户机使用。客户机磁盘I/O都将针对此文件。镜像文件可以有几种格式。

这种镜像的特点是格式简单，性能较好。

你的文件系统（例如Ext3）必须支持稀疏文件（sparse file），才能避免不必要的磁盘空间占用。稀疏文件是一种高效使用磁盘空间的技术，当文件大小很大，而其绝大部分块都是空白（未使用）的时，可以基于文件元数据来表示那些空白的块（而不是真实的硬盘空间）。

创建Raw镜像：

qemu-img create -f raw hda.img 1G

# 查看镜像信息
qemu-img info hda.img 
# image: hda.img
# file format: raw
# virtual size: 1.0G (1073741824 bytes)
# disk size: 0

你也可以使用dd命令产生Raw镜像，例如：

# 产生非稀疏文件：块大小1MB，写入1024个块，虚拟大小1G，实际大小1G
dd if=/dev/zero of=hda.img bs=1024k count=1024
# 产生稀疏文件：块大小1MB，写入0个块，虚拟大小1G，实际大小0
dd if=/dev/zero of=hda.img bs=1024k count=0 seek=1024

qcow2镜像的动态增长的，即使文件系统不支持稀疏文件，它也会尽可能的小。qcow2支持Copy-on-write、镜像、压缩、加密。 

正是由于qcow2支持Copy-on-write，我们才可以使用backing file——用一个镜像保存针对另外一个镜像的改变，而后面那个镜像不需要被改动。这是多虚拟机公用一个Base镜像，以及Snapshot的基础。

qcow2镜像文件的结构如下图所示：

qcow2镜像文件由一个头、几张表、数据簇组成。所有数据都存放在数据簇（Data Clusters）中，每个数据簇是512字节的扇区。为了方便管理这些数据簇，qcow2建立了两级表：L1、L2。其中L1表的条目指向L2表，而L2表的条目指向数据簇。

要定位数据，需要3个偏移量构成的数组：

1. 通过位于Header中的L1表指针  +offset[0]，得到L2表的指针
2. L2表指针 + offset[1]，得到数据簇指针
3. 数据簇指针 + offset[2]，得到目标数据的指针

你可以这样创建一个qcow2镜像：

qemu-img create -f qcow2 hda-back.img 16G

然后，在未来某个时刻把它作为backing file使用：

qemu-img create -f qcow2 -o backing_file=hda-back.img hda.img

镜像hda.img在一开始是空白的，所有数据都是从hda-back.img中获取，一旦发生写入操作，hda.img就开始有数据而hda-base.img保持不变。

使用下面的命令可以压缩一个qcow2镜像：

qemu-img convert -c -f qcow2 -O qcow2 hda.img hda.compressed.img

使用下面的命令可以为一个qcow2镜像设加密：

qemu-img convert -o encryption -f qcow2 -O qcow2  hda.img hda.encrypted.img
# 提示输入密码

使用压缩镜像启动虚拟机时，必须在Monitor中输入密码才可以。

使用下面的命令，可以扩展一个qcow2镜像的大小：

qemu-img resize hda.img +10G

注意：扩大得到的空间，不会被分区或者格式化。 

要移除镜像中的spare space，直接qcow2-to-qcow2转换即可，压缩（-c）可选：

qemu-img convert -O qcow2 source.qcow2 shrunk.qcow2

rebase操作用于改变一个镜像的backing镜像：

# -u 表示unsafe模式，在此模式下，仅仅改变backing文件的路径，不对文件内容进行检查
#    用于backing文件移动的情况
# -p 表示safe模式，在此模式下，执行真正的rebase操作。backing文件的内容可能和之前
#    不同，qemu-img会小心处理，确保VM可见的内容不变。为达成这一点，新旧backing
#    文件的差异，会合并到被改变镜像中
                    # 格式
qemu-img rebase -u  -f qcow2   
  # 新的backing文件位置                                      新backing文件格式
  -b /home/alex/Vmware/libvirt/images/sdd/xenial-base.qcow2 -F qcow2 
  # 被处理镜像文件
  /home/alex/Vmware/libvirt/images/sdd/xenial-100.qcow2

你可以把一个镜像的格式在Raw和qcow2之间进行转换：

# 把Raw格式的hda.img转换为qcow2格式的hda.qcow2
qemu-img convert -f raw -O qcow2 hda.img hda.qcow2

快照（Snapshot）是Copy-on-write的一种应用。QEMU支持两种快照：

1. 内部快照（internal snapshot）：在qcow2镜像的snapshot table中维护的快照，所有快照都存放在一个镜像文件中
2. 外部快照（external snapshot）：与Backing file很类似，在外部文件中创建新的镜像，原先的镜像只读

内部快照的原理是：

1. 创建一个Snapshot后，在Snapshot Table中新增一项，复制L1 Table
2. 当L2 Table或者Data Cluster发生改变，则把改变前的数据复制一份（Copy-on-write），由新创建的Snapshot的L1 Table来管理
3. L2 Table或者Data Cluster的变化，直接写到原始位置
4. 要删除快照，很简单，直接把Snapshot Table对应项、以及复制的L1-L2-DS删除即可
5. 要加载快照，则需要依据L1-L2-DS信息，将其合并到镜像的L1-L2-DS信息中

可以使用Monitor来创建、加载、删除内部快照：

# 保存一个内部快照
(qemu) savevm snapshot-1

qemu-img info hda.img
# 输出如下：
#Snapshot list:
#ID        TAG                 VM SIZE                DATE       VM CLOCK
#1         snapshot-1             112M 2016-09-07 18:05:48   00:00:21.536
#Format specific information:
#    compat: 1.1
#    lazy refcounts: false

# 加载内部快照
(qemu) loadvm snapshot-1

# 删除内部快照
(qemu) delvm snapshot-1

外部快照与内部快照相反：内部快照是原数据变化，外部快照则是新文件变化。

可以使用Monitor来管理外部快照：

snapshot_blkdev ide0-hd0 snapshot.img qcow2

有了磁盘镜像文件后，你需要为qemu-system-*指定参数，给客户机增加磁盘。有几种不同的配置方式：

# 最简单的方式
-hda hda.img 

# 使用-drive配置块设备，可以指定if为virtio来提升性能
-drive file=hda.img,index=0,media=disk,if=virtio

# 使用-device配置通用设备
-drive file=hda.img,if=none,id=virtio-disk0,format=qcow2,cache=none 
# 可以指定virtio-blk-pci来提升性能
-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=virtio-disk0,bootindex=1

QEMU中的网络，包含两部分的内容：

1. 客户机使用的虚拟网络设备
2. 和上述虚拟设备通信的网络后端，这些后端负责把虚拟设备的数据包发到宿主机的网络中

要创建一个网络后端，可以指定如下选项：

# TYPE为后端类型：user、tap、bridge、socket、vde等
# id为一个标识符，将虚拟网络设备和网络后端关联在一起
# 如果客户机有多个虚拟网络设备，则每一个都需要自己的网络后端
-netdev TYPE,id=NAME,...

QEME支持多种网络后端。

如果没有指定网络选项，QEMU默认会模拟单张Intel e1000 PCI网卡，该网卡基于user后端（SLIRP）连接到宿主机：

# 不指定网络
qemu 
# 等价配置。自0.12开始废弃的配置方式 -net nic相当于-device DEVNAME；-net TYPE相当于-netdev TYPE
qemu -hda disk.img -net nic -net user
# 等价配置。-netdev指定网络后端，-device指定虚拟网络设备，后者通过netdev字段引用后端的ID
qemu -netdev user,id=network0 -device e1000,netdev=network0

在客户机看来：

1. 本身的IP地址被分配为 10.0.2.15+
2. 分配IP的虚拟DHCP为 10.0.2.2
3. 虚拟DNS服务器为 10.0.2.3
4. 虚拟Samba服务器为 10.0.2.4，客户机可以通过此服务器访问宿主机的文件系统

用户模式网络可以很方便的访问网络资源。但是它有很多限制：

1. 默认的，它运作方式类似于防火墙，且不允许任何入站流量。这个限制可以通过端口重定向解决
2. 仅仅支持TCP、UDP协议，对于ICMP则不支持
3. 性能比较差

为了支持入站请求，你可以使用端口重定向（Redirecting ports）——把针对宿主机某个端口的请求转发给客户机的某个端口。映射后，客户机可以对外提供SSH、HTTP等服务：

# 把宿主机的7080端口重定向到客户机的80端口；把宿主机的7022端口重定向到客户机的22端口
qemu-system-x86_64 -redir tcp:7080::80 -redir tcp:7022::22 -hda ~/Vmware/KVM/centos7-base.img -m 512 

# 从宿主机SSH到客户机
ssh root@127.0.0.1 -p 7022

你可以不使用默认的10.0.2网段：

-netdev user,id=network0,net=192.168.5.0/24,dhcpstart=192.168.5.9 

依据客户机安装的操作系统，可能需要进行一些配置，才能正常使用网络。以CentOS 7 Minimal + 用户模式网络为例，需要修改以下配置文件：

NETWORKING=yes
# 如果不使用IPV6
NETWORKING_IPV6=no

# 如果不使用IPV6
IPV6INIT=no
# 开机启动此网卡，默认不启动
ONBOOT=yes

网关、DNS不需要设置。修改完这些配置文件后，重启客户机网络：

/etc/init.d/network restart

yum update

QEMU的TAP后端利用宿主机的TAP设备，为客户机提供完整的桥接网络支持，如果外部需要使用标准端口连接到客户机， 或者多个客户机需要相互通信，可以使用该方式。 TAP后端还具有以下优势：

1. 非常好的性能
2. 可以配置以支持各种网络拓扑

但是，你需要在宿主机上进行网络拓扑的配置，而且各种系统的配置不同。

使用TAP后端前，你需要确认你的宿主机的内核支持TAP网络接口：

/dev/net/tun

sudo mkdir /dev/net
sudo mknod /dev/net/tun c 10 200
sudo /sbin/modprobe tun

如果你想创建几个客户机之间的私有网络，可以使用该方式。未参与进来的客户机、真实网络无法看到此网络。

如果你不是root，则你需要

/dev/kvm

首先，添加一个以太网桥设备：

sudo ip link add br0 type bridge
# 也可以使用：sudo brctl addbr br0添加网桥
# 要删除网桥，执行： ip link delete br0
# 注意：网桥会在重启后消失

# 启用此网桥
sudo ip link set br0 up

# 为网桥分配IP地址
sudo ip addr add 10.0.0.1 dev br0

# 在宿主机添加一条直接路由，便于它能和客户机通信
sudo ip route add 10.0.0.0/8 dev br0

创建一个创建TAP设备并桥接到网桥的脚本：

#!/bin/sh

switch=br0

if [ -n "$1" ];then
        # tunctl -u `whoami` -t $1
        # 添加一个tap设备，在我的机器上不需要，原因见下面
        # ip tuntap add $1 mode tap user `whoami`
        # 不知道从什么时候开始，QEMU会在执行此脚本之前就创建好tap设备，因此会报下面的错误
        # ioctl(TUNSETIFF): Device or resource busy
        # 启动tap设备
        ip link set $1 up
        # brctl addif $switch $1
        # 将网桥和tap设备进行桥接
        ip link set $1 master $switch
        exit 0
else
        echo "Error: no interface specified"
        exit 1
fi

创建一个生成随机MAC地址的脚本：

#!/bin/bash
# generate a random mac address for the qemu nic
printf 'DE:AD:BE:EF:%02X:%02X\n' $((RANDOM%256)) $((RANDOM%256))

启动客户机的脚本：

#!/bin/bash
# $1 base name of virtual disk
# $2 memory size
# $3 tap device id

mac=`/usr/bin/qemu-genmac`
src=/usr/bin/qemu-ifup
sudo qemu-system-x86_64 -enable-kvm -device e1000,netdev=$3,mac=$mac -netdev tap,id=$3,script=$src,downscript=no \
                        -hda ~/Vmware/KVM/$1.img -m $2

为上面的脚本文件添加可执行权限：

sudo chmod +x /usr/bin/qemu-ifup-br0
sudo chmod +x /usr/bin/qemu-genmac
sudo chmod +x /usr/bin/qemu-start-br0

执行下面的命令，启动一台客户机（或者更多虚拟机，但是命令中的tap0要更换为不同的名字）：

/usr/bin/qemu-start centos7-base 512 tap0

修改客户机的IP地址，使用10.0.0.0/8网段：

TYPE=Ethernet
BOOTPROTO=static
DEFROUTE=yes
PEERDNS=yes
PEERROUTES=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=no
NAME=ens3
UUID=d9f47102-b177-4a27-ae98-86f6939d6680
DEVICE=ens3
ONBOOT=yes
IPADDR=10.0.0.10
PREFIX=8
GATEWAY=10.0.0.1

好了，你现在可以互相ping客户机和宿主机，应该可以正常连通了。 

上一节介绍的这种基于TAP的私有桥接网络，可以让客户机、宿主机相互连通，但是客户机无法访问互联网。

要解决此问题，你可以选择以下方法之一：

1. 让客户机通过宿主机暴露的HTTP/SOCKS代理上网
2. 配置宿主机的路由规则，设置好源地址转换即可：
   

   # 宿主机需要启用IP转发功能，这样它就可以像路由器那样中转IP封包了
   sudo sysctl -w net.ipv4.ip_forward=1 
   # 对客户机网段进行源地址转换
   sudo iptables -t nat -A POSTROUTING  -s 10.0.0.0/255.0.0.0 ! -d 10.0.0.0/255.0.0.0 -j MASQUERADE 

此方式和私有桥接网络类似，主要区别是，除了TAP设备桥接到网桥之外，以太网卡（例如eth0）也桥接到网桥（例如br1）。

你可以通过发行版的配置文件来配置网桥：

# 注意网络管理器组件的影响
# 去掉 auto eth0，改为：
auto br1

# 配置br1
iface br1 inet dhcp
    bridge_ports    eth0
    bridge_stp      off
    bridge_maxwait  0
    bridge_fd       0
    # 这里附加上原来属于eth0的配置

或者基于脚本来配置： 

sudo ip link add br1 type bridge
sudo ip link set br1 up
sudo ip link set eth0 master br1 

# DHCP
sudo killall dhclient && sudo ip addr flush dev eth0
sudo dhclient br1

无论用哪种方式，都应该注意到eth0的IP地址需要转移给br1，这样才能确保网络正常运作——br1必须在链路层接收到相关ARP请求，并决定是否需要转发给客户机，eth0没有这种转发能力。

如果eth0所在网络是基于DHCP的，那么客户机配置为DHCP后，会自动获取公共IP地址。否则，需要手工设置客户机的IP地址。 

现在QEMU支持自动桥接TAP设备到宿主机的一个网桥，因此你不再需要编写脚本，修改网络后端为bridge即可：

-netdev bridge,id=tap0,br=br0

注意，使用上述选项时，QEMU需要读取配置文件/etc/qemu/bridge.conf，你只需在此文件中添加一行代码：

allow br0

你可以编写如下脚本自动创建网桥、配置iptables规则。示例：

# Create private bridge link for QEMU
/sbin/ip link add br0 type bridge
/sbin/ip link set br0 up
/sbin/ip addr add 10.0.0.1 dev br0
/sbin/ip route add 10.0.0.0/8 dev br0
# NAT for 10.0.0.0/8
/sbin/iptables -t nat -A POSTROUTING  -s 10.0.0.0/255.0.0.0 ! -d 10.0.0.0/255.0.0.0  -j MASQUERADE


# Create public bridge link for QEMU
/sbin/ip link add br1 type bridge
/sbin/ip link set br1 up
/sbin/ip link set eth0 master br1 
/usr/bin/killall dhclient && /sbin/ip addr flush dev eth0
/sbin/dhclient br1

建议和libvirt一起使用macvtap。 

在使用libvirt时，客户机（Domain）的网络接口配置可以简化为：

<interface type='bridge'>
    <mac address='DE:AD:BE:EF:F1:00'/>
    <source bridge='br0'/>
    <target dev='tap0'/>
    <model type='virtio'/>
</interface>

可以使用libvrit的虚拟局域网，这样宿主机上不会为客户机创建专门的tap设备，那些手工编写的脚本也全都不需要了。虚拟网络配置示例：

<network>
  <name>default</name>
  <uuid>9bae4de8-ca58-48c5-ba58-109aebf8b954</uuid>
  <forward mode='nat'>
  </forward>
  <bridge name='virbr0' stp='on' delay='0'/>
  <ip address='10.0.0.1' netmask='255.0.0.0'>
    <dhcp>
      <range start='10.0.0.100' end='10.0.0.200'/>
    </dhcp>
  </ip>
</network>

客户机（Domain）的网络接口配置示例：

<interface type='network'>
    <mac address='DE:AD:BE:EF:F1:00'/>
    <source network='default'/>
    <model type='virtio'/>
</interface>

另外，libvirt的虚拟网络提供了DHCP功能，因此客户机的IP地址不需要静态设置。

SMBIOS即DMI表，存放了X86系统硬件信息，这个表依据DMI type分为数十个段，type0是BIOS、type1是系统信息、type2是主板信息……

QEMU支持模拟这些信息，例如：

# 设置客户机的type1信息
-smbios type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=2011,serial=8059dfb4,uuid=1f8ee7f308

要设置客户机的内存容量，可以使用

-m

客户机没必要占据着空闲的内存不用，因此我们一般启用内存实际大小的动态调整功能，例如：

-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5

在本文的第一章，谈到周围硬件性能的时候，我们提及了virtio——它是规定了虚拟设备的前端驱动与宿主机硬件的后端驱动之间通信接口的标准，并且知道目前的很多Linux发行版已经把virtio驱动编译进内核了。前面的章节我们也使用了很多virtio驱动，包括磁盘、网络、内存相关的。

基于virtio驱动的虚拟设备，我们成为“半虚拟化设备”，因为这些设备驱动知道自己工作在虚拟化模式下。为客户机配置半虚拟化设备，可以提高内存、硬盘、网络方面的性能，由其对于网络，性能提升很明显。

除了virtio，Vmware Tools也属于半虚拟化驱动，QEMU客户机也可以利用Vmware Tools（例如-vga指定vmware）。virtio驱动的具体实现包括：virtio-blk、virtio-net、virtio-pci、virtio-balloon、virtio-console等。

半/全虚拟化的区别如下：

1. 在全虚拟化状态下，Guest OS不知道自己是虚拟机，于是像发送普通的IO一样发送数据，被Hypervisor拦截，转发给真正的硬件。
2. 在半虚拟化状态下，Guest OS知道自己是虚拟机（需安装半虚拟化驱动），所以数据直接发送给半虚拟化设备，经过特殊处理，发送给真正的硬件

这是一个特殊的半虚拟化设备，它能够动态（不需要重启客户机）的调整客户机的内存大小。如果你指定了-m参数，则不能调整的比-m更大。使用选项

-balloon virtio

要基于半虚拟化来访问磁盘，可以使用选项：

-drive file=vda.qcow2,if=virtio

可以使用驱动virtio-blk-data-plane进一步提高性能（I/O性能较virtio-blk能提高10-20%），此驱动自QEMU 1.4开始引入。与传统的virtio-blk不同的是，virtio-blk-data-plane为每个块设备独立分配一个线程用于I/O处理，此线程不需要和QEMU执行线程同步、竞争锁。此驱动基于宿主机的原生AIO响应客户机的请求。启用此驱动的选项示例：

-drive if=none,id=drive0,cache=none,aio=native,format=raw,file=vda.img
-device virtio-blk-pci,drive=drive0,scsi=off,x-data-plane=on

但是，启用virtio-blk-data-plane后，存储迁移（storage migration）、热拔插、I/O限流（throttling） 等功能无法使用。而且该驱动仅支持Raw格式的磁盘。

要基于半虚拟化来访问网络，可以使用选项：

-device virtio-net-pci,netdev=network0

宿主机网卡的某些特性可能会影响virtio的性能，例如：

1. TSO（TCP Segmentation Offload）：通过网络设备进行TCP段的分割，从而来提高网络性能
2. GSO（Generic Segmentation Offload）：类似，用TCPv6、UDP等传输层协议

你可以开关这些特性来测试对客户机网络性能的影响。要检查宿主机网卡是否支持、开启这些特性，可以执行命令：

ethtool -k eth0

网络块设备（Network Block Device）是一种把虚拟块设备通过TCP/IP暴露出去，供远程共享访问的技术。

你可以通过UNIX套接字来暴露：

qemu-nbd -t -k /home/alex/Vmware/KVM/.images/fedora-108 fedora-108/hda.img

 也可以通过普通套接字来暴露：

qemu-nbd  -p 1025 fedora-108/hda.img 

甚至是把镜像直接挂载到宿主机的NBD设备中：

# 在宿主机上启用NBD内核模块，最多16个分区：
sudo modprobe nbd max_part=16
# 查看NBD设备文件
ls /dev/nbd*
# 输出/dev/nbd0 ... /dev/nbd15

# 挂载
sudo qemu-nbd -c /dev/nbd0 fedora-108/hda.img

# 查看nbd0的分区情况
sudo fdisk -l /dev/nbd0
#  Device Boot Start End Blocks Id System
#  /dev/nbd0p1 * 2048 1026047 512000 83 Linux
#  /dev/nbd0p2 1026048 33554431 16264192 8e Linux LVM

客户机可以直接使用NBD作为磁盘：

# 使用UNIX套接字：
qemu-system-x86_64 -hda nbd:unix:/home/alex/Vmware/KVM/.images/fedora-108
# 使用普通套接字
qemu-system-x86_64 -hda nbd:10.0.0.1:1025

QEMU支持离线或者在线的迁移，你可以在Monitor中使用迁移命令。当迁移完毕后，虚拟机会在目标主机上继续运行。

AMD和Intel宿主机之间可以随意的迁移虚拟机，64位虚拟机只能迁移到64位宿主机上，32位则没有限制。某些老旧的Intel CPU不支持NX（禁止执行比特位），这种CPU处于启用NX的宿主机群中，会导致问题，你需要禁止客户机的NX：

-cpu qemu64,-nx

QEMU的迁移功能具有以下特性：

1. 极短暂的客户机停机时间
2. 如果迁移成功，则客户机在目标主机上运行；如果迁移失败，则客户机继续在源主机上运行
3. 几乎对硬件没有依赖

使用共享存储时，QEMU迁移会很便利，因为不牵涉到磁盘映像的移动。共享存储包括：NFS、NBD、SAN等。 我们以NBD为例说明：

1. 启动供源、目的虚拟机共享的NBD服务：

   qemu-nbd -p 1025 --share=2 fedora-108/hda.img

    
2. 确保源、目的虚拟机的配置，它们要具有相同的网络环境
3. 启动源虚拟机：
   

   sudo qemu-system-x86_64 -netdev bridge,id=tap0,br=br0 -device virtio-net-pci,netdev=tap0,mac=DE:AD:BE:EF:F1:08 
                           -hda nbd:10.0.0.1:1025 -monitor stdio -enable-kvm  

4. 源虚拟机运作一段时间后，其宿主机的硬件需要维护，因此准备迁移。在另外一台宿主机上启动目的虚拟机，并监听migration端口：
   

   # qemu选项同源虚拟机，附加：
   -incoming tcp:0:4444

    注意，这个监听端口是开在宿主机上的。实际上，以-incoming启动目的虚拟机后，虚拟机是处于Stopped状态的

5. 登录到源虚拟机，确认它与目的虚拟机的宿主机之间的网络是畅通的
6. 在源虚拟机的Monitor中，发起迁移命令：

   (qemu) migrate -d tcp:10.0.0.1:4444

    
7. 在迁移过程中，可以通过

   info migrate

    查看迁移状态，完毕后会显示Migration status: completed，并列出迁移消耗的时间、停机时间
8. 迁移完成后，源虚拟机变为Stopped，而目的虚拟机开始运行，获得源虚拟机的全部瞬时状态

这种情况下，源虚拟机的磁盘镜像需要拷贝到目标宿主机中。因而需要更长的时间、更多的网络带宽消耗。步骤如下：

1. 查看源虚拟机的磁盘镜像信息：

   qemu-img info fedora-108/hda.img

    
2. 在目的机器上创建与之大小（Virtual size）一致的空磁盘镜像：

   qemu-img create -f qcow2 fedora-108-m/hda.img 16G

    
3. 使用与共享存储一样的步骤进行迁移，只是源、目的虚拟机使用各自的磁盘镜像

前面的章节我们已经多次使用QEMU的监控功能，通过使用QEMU的HMI（Monitor）可以在(qemu)提示符下进行各种监控操作，包括查看虚拟机信息、动态添加设备、执行迁移等等。在《QEMU命令与快捷键》一章我们会详细的讲解HMI命令，本章主要介绍监控相关的QEMU配置

你可以通过多种方式使用Monitor：

1. 默认的，可以在QEMU的虚拟机窗口中，按Ctrl + Alt + 2切换到Monitor
2. 可以使用

   -monitor stdio

    ，让Monitor重定向到启动虚拟机的Terminal
3. 可以启动一个TCP监听

   -monitor tcp::4444,server,nowait

    ，这样你可以

   telnet hostip:4444

    访问Monitor
4. 可以通过字符设备：

   -chardev stdio,id=x -monitor chardev=x

    访问Monitor

非交互式监控时，QEMU监控协议（QEMU Monitor Protocol）是更好的选择，这是一个基于JSON格式的协议。要启用QMP，你可以：

1. 基于stdio：

   -qmp stdio

    
2. 基于TCP：

   -qmp tcp:localhost:4444,server

    
3. 基于UNIX Socket：

   -qmp unix:./qmp-sock,server

    

以下列出一些应用基于QEMU/KVM的虚拟化方案时的最佳实践：

1. 使用半虚拟化驱动virtio
   1. 性能好：延迟低、吞吐量高
   2. 纯虚拟设备的劣势：需要高吞吐能力的设备在硬件方面会有特殊的实现，这些纯虚拟设备是没法利用的
   3. 网络、块设备、内存，都可以使用virtio
   4. 兼容性较差
2. 虚拟机最好直接使用块设备做存储
   1. 性能好、无需管理宿主机的文件系统、无需管理稀疏文件
   2. I/O 缓存以4K为边界
   3. 如果没有条件使用块设备，只能使用镜像文件
   4. 宿主机最好使用ext3文件系统，ext4的barrier会影响性能
   5. Raw格式镜像的性能优于qcow2
   6. 选择正确的缓存策略，缓存模式推荐none，I/O调度器推荐Deadline I/O scheduler
3. CPU配置
   1. 每个客户机相当于一个进程，而每个客户机的虚拟CPU相当于一个线程。因此超配CPU是可行的
   2. CPU超配可能带来额外的上下文切换，影响性能
   3. 要保证客户机获得足够的时间片，可以利用cgroup的cpu.cfs_period_us、cpu.cfs_quota_us来干预CFS调度器的行为
   4. Pin CPU：可以将虚拟CPU Pin到一个物理CPU，或者一组共享缓存的物理CPU，便于缓存共享。缺点是Pin导致其它空闲CPU可能得不到利用
4. 内存配置
   1. 使用内核特性KSM（Kernel Same Page Merging），KSM通过扫描将相同的内存区域设置为共享，并且Copy-on-write。共享内存节约可以内存空间，但是内存扫描同时影响性能
   2. 尽量避免使用swap，可以设置/proc/sys/vm/swappiness=0
5. 网络配置
   1. 使用tap类型的网络后端
   2. 启用PCI passthough可以提高性能，但是影响迁移

HMI即 Human Monitor Interface，是QEMU在运行客户机时提供的一个console（下面我们称此console为Monitor），它让你可以和运行中的虚拟机进行交互，你可以获得内存Dump、列出虚拟设备树、获取屏幕截图等操作。

默认情况下QEMU使用SDL来显示客户机的视频输出，此所谓图形模式。如果启用-nographic选项则会禁用图形模式。

在图形模式下，你可以使用以下方式之一访问HMI：

1. 在客户机的虚拟控制台（客户机弹窗）访问HMI，按Ctrl + Alt + 2可以切换到Monitor，在其中你可以调用HMI命令
2. 指定-monitor stdio，则启动虚拟机的Terminal变为Monitor

在基于-nographic的非图形模式下，Monitor、虚拟串口都被重定向到stdio，你可以Ctrl + a c来切换。你可以同时把虚拟串口配置为系统控制台，这样你可以通过单个窗口完成客户机登录、HMI操作

info kvm           # 显示KVM支持情况
info pci           # 显示PCI信息
info qtree         # 显示QEMU系统总线树
info network       # 显示网络设备信息
info block         # 显示块设备信息
info blockstatus   # 显示块设备读写统计信息
info snapshots     # 显示快照信息
info migrate       # 显示迁移状态

sendkey ctrl-alt-f1

savevm blankos

loadvm blankos

info block
# ide0-hd0: /home/alex/Vmware/KVM/fedora-108/hda.img (qcow2)
snapshot_blkdev_internal  ide0-hd0 blankos

snapshot_blkdev ide0-hd0 blankos.img

该命令即QEMU模拟器，使用它可以指定硬件设备，并从虚拟磁盘镜像启动一台客户机。

-machine [type=]name[,prop=value[,...]]

qemu-system-x86_64 -machine help

qemu-system-x86_64 -cpu help

-smp [cpus=]n[,cores=cores][,threads=threads][,sockets=sockets][,maxcpus=maxcpus]

-global driver.prop=value

-global ide-drive.physical_block_size=4096

-boot [order=drives][,once=drives][,menu=on|off][,splash=sp_name]
      [,splash-time=sp_time][,reboot-timeout=rb_timeout][,strict=on|off]

-soundhw card1[,card2,...]
# 或者
-soundhw all

# 显示可用硬件列表
qemu-system-x86_64 -soundhw help
# 示例
qemu-system-x86_64 -soundhw ac97 disk.img

# 禁用balloon设备
-balloon none
# 启用balloon设备，可以指定一个PCI地址
-balloon virtio[,addr=addr]

-device driver[,prop[=value][,...]]

-device help

-device driver,help

bus=pci.x

addr=0xM.0xN

# 添加e1000网卡，以network0为后端
-device e1000,netdev=network0
# 添加基于Virtio的网卡，等价于 -net nic,model=virtio ...
-device virtio-net-pci,netdev=network0,id=net0,mac=DE:AD:BE:EF:F1:08,bus=pci.0,addr=0x3

# 启用virtio balloon设备（收回客户机空闲内存），等价于-balloon ...
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5

# 添加基于Virtio的硬盘（前端）
-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0

-drive option[,option[,option[,...]]]

-drive file=file,index=2,media=cdrom

-drive file=file,index=0,media=disk
-drive file=file,index=1,media=disk
-drive file=file,index=2,media=disk
-drive file=file,index=3,media=disk

-vnc 0.0.0.0:10

-g widthxheight[xdepth]

-net nic[,vlan=n][,macaddr=mac][,model=type] [,name=name][,addr=addr][,vectors=v] 

-net nic,model=help

-netdev user,id=id[,option][,option][,...]
-net user[,option][,option][,...]

-netdev tap,id=id[,fd=h][,ifname=name][,script=file][,downscript=dfile][,helper=helper]
-net tap[,vlan=n][,name=name][,fd=h][,ifname=name][,script=file][,downscript=dfile][,helper=helper]

-netdev bridge,id=id[,br=bridge][,helper=helper]
-net bridge[,vlan=n][,name=name][,br=bridge][,helper=helper]

allow br0

-chardev backend ,id=id [,mux=on|off] [,options]

-chardev vc ,id=id [[,width=width] [,height=height]] [[,cols=cols] [,rows=rows]] 

-chardev ringbuf ,id=id [,size=size]

-chardev pipe ,id=id ,path=path

-chardev file ,id=id ,path=path

-chardev serial ,id=id ,path=path

-nographic

-display none

在图形化模拟期间，你可以使用快捷键：

 如果你使用了-nographic，则可以使用以下快捷键：

用于创建QEMU网络块设备（Network Block Device）服务器，即通过NBD协议把磁盘镜像暴露出去。 命令格式：

qemu-nbd [OPTION]... diskimgfile

常用选项如下表：

报错信息：'virtio-9p-pci' is not a valid device model name

解决办法：参考下面的脚本构建QEMU：

apt install libattr1-dev
configure --prefix=/usr --enable-virtfs
make && make install

报错信息：qemu-system-x86_64: -sdl: SDL support is disabled

解决办法：参考下面的脚本构建QEMU：

sudo apt install libsdl2-dev
./configure --prefix=/usr --enable-virtfs --enable-sdl

报错信息：Image is corrupt; cannot be opened read/write

解决办法：

qemu-img check -r all /media/alex/v12n2/libvirt/images/xenial-23

The post KVM和QEMU学习笔记 appeared first on 绿色记忆.

libvirt是广泛使用的、通用虚拟化管理工具，它提供多种命令行工具、多种语言的编程API。

libvirt的目标是：提供一个通用、稳定的抽象层，来安全有效的远程管理一个节点（node）之上的域（domains），因此它需要提供全套的API来完成管理，这些API必须完成Domain的创建、修改、配置、监控、迁移、停止。

libvirt可以管理的虚拟化机制（hypervisor或container）包括：KVM/QEMU、Xen、LXC、OpenVZ、VirtualBox、VMware ESX/GSX、VMware Workstation/Player、Microsoft Hyper-V、IBM PowerVM。

libvirt的二进制组件可能已经随操作系统安装，如果没有，你可以：

sudo apt-get install libvirt-bin

可以安装virt-install，这是一个用来创建基于KVM、XEN或者Linux容器的客户机的工具：

sudo apt-get install virtinst

可以安装virt-manager，它提供了基于libvirt的图形化管理工具：

sudo apt-get install virt-manager

可以安装virt-viewer，它用于连接到虚拟机的Graphical Console：

# 安装
sudo apt-get install virt-viewer
# 使用
virt-viewer -c qemu:///system

virsh是libvirt提供的一个命令行工具，利用它你可以通过命令行，交互式的管理你的虚拟机（Domain）。使用此命令，你可以创建、暂停、关闭domain，可以列出当前的domain。

libvirt会在宿主机上运行一个libvirtd守护进程，此进程可以被本地/远程的virsh调用。libvirtd则可以直接调用qemu-kvm来操控客户机。大部分virsh命令需要libvirtd处于运行状态才可用。

使用virsh的define、edit、start、shutdown|destroy、reboot、suspend、resumen、undefined子命令，分别可以定义、编辑、启动、关闭、暂停、唤醒、删除Domain。这些命令比较简单，参考virsh命令详解一节。

快照可以分为三个级别：

1. 卷管理器（Volume Manager） 级别，例如LVM的Snapsot功能
2. 文件系统级别，常用的Ext3不支持，OCFS2支持
3. 文件级别，Raw格式的镜像不支持快照，qcow2格式则支持，且快照分为两类：
   1. 内部快照：保存在qcow2文件内部的快照：
      1. 虚拟机状态快照（VM State snapshot）：整个虚拟机的状态，不仅仅是磁盘
      2. 磁盘状态快照（Disk State snapshot）：仅仅针对磁盘的快照
   2. 外部快照：将原先（Backing）的qcow2镜像设置为只读，新的改变保存到另外的qcow2文件

使用virsh save / virsh restore命令，可以仅仅将Domain的内存状态保存，然后停止Domain，最后恢复。恢复时假设磁盘没有任何改动：

# 保存内存快照
virsh save fedora-10 fedora-10.vmstate

# 恢复内存快照
virsh restore fedora-10.vmstate

内部快照、外部快照使用同一组命令来管理的。这些快照默认包含内存、磁盘、设备等全部状态。内部快照示例：

# 创建一个快照
virsh snapshot-create fedora-10
# Domain snapshot 1473667716 created

# 列出Domain的快照
virsh snapshot-list fedora-10
#  Name                 Creation Time             State
# ------------------------------------------------------------
#  1473667716           2016-09-12 16:08:36 +0800 running

# 创建的是内部快照，可以使用底层命令查看
qemu-img info ~/Vmware/KVM/fedora-10/hda.img

注意，一旦创建了快照，Domain就不能被undefine。

要删除内部快照，可以执行：

virsh snapshot-delete fedora-10 1473667716
# Domain snapshot 1473667716 deleted

执行下面的命令创建一个外部快照： 

# 这里我们仅针对vda磁盘创建了快照，内存状态没有做快照
snapshot-create-as fedora-10 blankos "Initial snapshot" 
    --diskspec=vda,file=/home/alex/Vmware/KVM/fedora-10/blankos.vda.qcow2 --disk-only --atomic

现在查看客户机关联的块设备：

virsh domblklist fedora-10
# Target     Source
# ------------------------------------------------
# vda        /home/alex/Vmware/KVM/fedora-10/blankos.vda.qcow2

可以发现关联性转移到外部快照上了，原先的磁盘镜像成为Backing file。注意：Domain的后续写操作都发生在新创建的磁盘上

要删除外部快照，执行：

virsh snapshot-delete fedora-10 --metadata blankos

我们来创建三个快照：

DIR=/home/alex/Vmware/KVM/fedora-10
virsh snapshot-create-as fedora-10 snap0 "snap0" --diskspec=vda,file=$DIR/snap0.vda.qcow2 --disk-only --atomic
virsh snapshot-create-as fedora-10 snap1 "snap1" --diskspec=vda,file=$DIR/snap1.vda.qcow2 --disk-only --atomic
virsh snapshot-create-as fedora-10 snap2 "snap2" --diskspec=vda,file=$DIR/snap2.vda.qcow2 --disk-only --atomic

查看当前快照：

# 默认的，新创建的快照作为当前快照
virsh snapshot-current fedora-10 --name

查看快照链（Backing chain）：

virsh snapshot-list fedora-10 --tree
# vda.qcow2 是base
# snap0
#   |
#   +- snap1
#       |
#       +- snap2    这个是top

libvrit支持多种方式来管理磁盘的快照链：

方式一：基于blockcommit，合并到base镜像

我们可以清理快照链条，将snap2、snap1、snap0中的变更都提交到vda.qcow2中

# 必须在Domain运行着的情况下执行命令
virsh blockcommit fedora-10 vda --base $DIR/vda.qcow2 --top $DIR/snap2.vda.qcow2 --wait --verbose
# 目前带--delete参数会导致 error: unsupported flags (0x2) in function qemuDomainBlockCommit

提交后，可以安全的删除快照及其元数据（snapshot-delete --metadata），libvrit是分开管理backing链和snapshot列表的。 

方式二：基于blockpull，合并到top镜像

也可以反过来，把base一直pull到top位置（必须是叶子节点）的snapshot，然后此snapshot就成为完整的磁盘镜像了（不依赖backing镜像）： 

virsh blockpull fedora-10 --path $DIR/snap2.vda.qcow2 --base $DIR/vda.qcow2 --wait –verbose

方法三：基于blockcopy，可以在线迁移磁盘

首先，需要取消Domain定义，将其变为transient的：

# 导出Domain配置
virsh dumpxml --inactive fedora-10 $DIR/domain.xml
# 取消定义
virsh undefine fedora-10

然后执行拷贝：

# --shallow 浅拷贝，copy.vda.qcow2与snap2.vda.qcow2将具有相同的backing chain即base ⇦ snap0 ⇦ snap1
# --pivot  操作完成后，此Domain改用copy
virsh blockcopy --domain fedora-10 vda $DIR/copy.vda.qcow2 --wait --verbose --shallow --pivot

拷贝完成后，瞬时的Domain使用copy继续运行：

virsh domblklist fedora-10
# Target     Source
# ------------------------------------------------
# vda        /home/alex/Vmware/KVM/fedora-10/copy.vda.qcow2 

而原先的磁盘可以迁移走了。

要通过virsh来访问远程宿主机上的Domain时，需要提供URI。URI的格式如下：

driver[+transport]://[username@][hostname][:port]/[path][?extraparameters]

URI各部分说明如下：

要连接到远程宿主机，可以使用-c选项或者connect子命令：

virsh -c qemu+ssh://root@zircon.local/system

使用该transport时，需要注意配置文件：

# 这些项都是默认值
unix_sock_group = "libvirtd"
unix_sock_ro_perms = "0777"
unix_sock_rw_perms = "0770"

也就是说，用户必须加入到libvirtd组，才可以使用unix传输，否则会报错：error: Failed to connect socket to '/var/run/libvirt/libvirt-sock': Permission denied。执行下面的命令添加用户到组：

sudo usermod -a -G libvirtd alex

注意：连接到qemu时，不指定主机名默认使用unix socket。

在目标宿主机上，修改配置文件：

# 启用TCP监听
libvirtd_opts="-d -l"

然后再修改配置文件：

# 默认TCP监听是禁用的
listen_tcp = 1
# 可以修改监听地址和端口
listen_addr = "0.0.0.0"
tcp_port = "16509"
# 可以不启用验证，但是缺乏安全性，所有流量都是明文
auth_tcp = "none"

最后重启libvirtd即可。  

相关文章：Linux知识集锦 - cgroup

libvirt基于cgroup来限制客户机对宿主机资源的访问。libvirt不会尝试加载任何controllers，它只会检测哪些controllers被mount。

QEMU驱动支持cpuset, cpu, memory, blkio, devices这几个controller，修改配置文件/etc/libvirt/qemu.conf可以针对QEMU禁用某些controller。

LXC驱动支持 cpuset, cpu, cpuacct, freezer, memory, blkio,devices 这几个controller， 其中cpuacct, devices, memory是必须的，如果这几个controller没有被mount则容器不会被启动。

libvrit引入两个概念，以方便cgroups管理：

1. partitions：不包含任何进程的cgroup，仅仅包含资源控制规则，它可以包含多个子目录，这些子目录要么是partition要么是consumers
2. consumers：是包含了单个虚拟机/容器进程的cgroup

对于不使用systemd的宿主机，consumers命名规则为

$VMNAME.libvirt-{qemu,lxc}

ls /sys/fs/cgroup/cpu/machine
# fedora-10.libvirt-qemu  ...

直到cgroups布局后，你就可以直接读写cgroups文件系统，来控制客户机的资源访问。但是virsh也提供了一些命令在运行时控制资源访问。

1. 对于CPU访问控制，可以使用virsh schedinfo命令
2. 对于块设备的访问控制，可以使用virsh blkiotune命令
3. 对于网卡流量的控制，可以使用domiftune或者tc命令

该命令最常见的调用形式为：

virsh [OPTION]... <command> <domain> [ARG]...

1. command 是一个virsh子命令
2. domain 是操控的虚拟机的名称、ID或者UUID
3. ARG是针对特定子命令的参数
4. OPTION为一般性选项

# 列出子命令列表
virsh help
# 显示一个子命令的用法
virsh help define

dumpxml

virsh domblkstat fedora-10 vda

virsh domifstat fedora-10 tap0

virsh domiftune fedora-10 tap0

# 发送右侧Ctrl + C到fedora-10
virsh send-key fedora-10 KEY_RIGHTCTRL KEY_C
# 发送Ctrl + Alt + Del
virsh send-key debian-20 KEY_LEFTCTRL KEY_LEFTALT KEY_DELETE
# 发送TAB，按下1秒
virsh send-key fedora-10 --holdtime 1000 0xf 

virsh # domblklist debian-20
# Target     Source
# ------------------------------------------------
# vda        /home/alex/Vmware/KVM/debian-20/vda.qcow2
# hdd        /home/alex/Software/OS/debian-8.6.0-amd64-netinst.iso

change-media debian-20 --eject --live

这些子命令用来管理Domain的快照，快照是Domain的磁盘、内存、设备在某一个时刻的状态，这些状态可以在未来恢复。每个快照由唯一性的名字来识别。

vol-create default definitions/volumes/fedora-10.xml

virsh vol-create-as v12n1 centos7-base 128G --format qcow2

vol-delete --pool default fedora-10.qcow2

vol-dumpxml --pool default coreos.qcow2

vol-list default

模拟器QEMU和hypervisor KVM可以被libvirt管理。

如果driver检测到/usr/bin/qemu-system-*则QEMU可用；如果driver检测到设备节点/dev/kvm和可执行文件/usr/bin/qemu-kvm则支持KVM全虚拟化和客户机硬件加速。

QEMU的驱动是一个多实例驱动，包含一个系统级别的特权驱动（system实例）和多个用户级别的非特权驱动。驱动的URI的协议名为qemu，URI示例：

# 本地访问per-user的实例
qemu:///session
# 本地访问per-user的实例
qemu+unix:///session
# 本地访问系统级实例
qemu:///system
# 本地访问系统级实例
qemu+unix:///system 
# 基于 TLS/x50的远程访问
qemu://example.com/system 
# 基于SSH隧道远程访问
qemu+ssh://root@example.com/system

virsh domxml-from-native

1. 将QEMU命令行保存到文件qemu.cmd：

   /usr/bin/qemu-system-x86_64 -name fedora-10 -enable-kvm -cpu Haswell -daemonize -display none -m 512 -drive file=/home/alex/Vmware/KVM/fedora-10/hda.img,index=0,media=disk,if=virtio -netdev bridge,id=tap0,br=br0 -device virtio-net-pci,netdev=tap0,mac=DE:AD:BE:EF:F1:00

    
2. 执行命令：

   virsh domxml-from-native qemu-argv ~/Vmware/KVM/fedora-10/qemu.cmd ~/Vmware/KVM/fedora-10/domain.xml

    

生成的配置文件内容如下：

<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
  <name>fedora-10</name>
  <uuid>51480ab5-864e-4eb7-9e1c-55b56105139e</uuid>
  <memory unit='KiB'>524288</memory>
  <currentMemory unit='KiB'>524288</currentMemory>
  <vcpu placement='static'>1</vcpu>
  <os>
    <type arch='x86_64' machine='pc'>hvm</type>
  </os>
  <features>
    <acpi/>
  </features>
  <cpu mode='custom' match='exact'>
    <model fallback='allow'>Haswell</model>
  </cpu>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</on_crash>
  <devices>
    <emulator>/usr/bin/qemu-system-x86_64</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw'/>
      <source file='/home/alex/Vmware/KVM/fedora-10/hda.img'/>
      <target dev='vda' bus='virtio'/>
    </disk>
    <controller type='usb' index='0'/>
    <controller type='pci' index='0' model='pci-root'/>
    <input type='mouse' bus='ps2'/>
    <input type='keyboard' bus='ps2'/>
    <graphics type='sdl'/>
    <video>
      <model type='cirrus' vram='9216' heads='1'/>
    </video>
    <memballoon model='virtio'/>
  </devices>
  <qemu:commandline>
    <qemu:arg value='-daemonize'/>
    <qemu:arg value='-display'/>
    <qemu:arg value='none'/>
    <qemu:arg value='-netdev'/>
    <qemu:arg value='bridge,id=tap0,br=br0'/>
    <qemu:arg value='-device'/>
    <qemu:arg value='virtio-net-pci,netdev=tap0,mac=DE:AD:BE:EF:F1:00'/>
  </qemu:commandline>
</domain>

可以看到，很多QEMU选项没有对应到常规的Domain配置元素，而是使用qemu:commandline的形式，在启动客户机的时候直接传递给QEMU了。因此，新建客户机时，不要使用这种导入配置的方法，而应调用libvirt API或者手工创建Domain的XML配置。

注意：virsh自动导入得到XML配置存在不少错误，需要调整后才能使用。上例修改后的配置如下：

<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
    <name>fedora-10</name>
    <memory unit='KiB'>524288</memory>
    <currentMemory unit='KiB'>524288</currentMemory>
    <vcpu placement='static'>1</vcpu>
    <os>
        <type arch='x86_64' machine='pc'>hvm</type>
    </os>
    <features>
        <acpi/>
    </features>
    <cpu mode='custom' match='exact'>
        <model fallback='allow'>SandyBridge</model>
    </cpu>
    <clock offset='utc'/>
    <on_poweroff>destroy</on_poweroff>
    <on_reboot>restart</on_reboot>
    <on_crash>destroy</on_crash>
    <devices>
        <emulator>/usr/bin/qemu-system-x86_64</emulator>
        <disk type='file' device='disk'>
            <driver name='qemu' type='qcow2'/> <!-- 镜像格式要设置对 -->
            <source file='/home/alex/Vmware/KVM/fedora-10/hda.img'/>
            <target dev='vda' bus='virtio'/>
            <boot order='1'/>  <!-- 要指定启动顺序，否则不会从此硬盘启动系统 -->
        </disk>
        <controller type='usb' index='0'/>
        <controller type='pci' index='0' model='pci-root'/>
        <!-- 把基于qemu:commandline的网络配置改为标准的Domain配置方式 -->
        <interface type='bridge'>
            <mac address='DE:AD:BE:EF:F1:00'/>
            <source bridge='br0'/>
            <target dev='tap0'/>
            <model type='virtio'/>
        </interface> 
        <!-- 添加串口控制台配置，去掉视频相关配置 -->
        <serial type='pty'>
            <target port='0'/>
        </serial>
        <console type='pty'>
            <target type='serial' port='0'/>
        </console>
        <input type='mouse' bus='ps2'/>
        <input type='keyboard' bus='ps2'/>
        <memballoon model='virtio'/>
    </devices>
</domain> 

类似的，可以把Domain配置文件转换为QEMU命令行：

virsh domxml-to-native qemu-argv ~/Vmware/KVM/fedora-10/domain.xml

libvirt使用XML文件描述一个Domain的全部配置信息：

<!--
任何Domain配置的根元素都是domin，它有两个属性：
    type 驱动（hypervisor）的类型，可选值：xen | kvm | qemu | lxc | kqemu
    id 正在运行的Domain的唯一标识，整数。非活动Domain没有id
-->
<domain type='kvm' id='1'>
    <!-- 在单个node下唯一的虚拟机名字 -->
    <name>fedora-10</name>
    <!-- RFC 4122兼容的、虚拟机的全局唯一标识，如果在定义/创建虚拟机时不指定，则会自动生成一个  -->
    <uuid>4dea22b31d52d8f32516782e98ab3fa0</uuid>
    <!-- 虚拟机的简短描述，可以多行 -->
    <title>A short description</title>
    <!-- 虚拟机的描述-->
    <description>Some human readable description</description>
    <!-- 元数据：由应用程序使用，子树必须使用应用程序自己的名字空间 -->
    <metadata>
        <app1:foo xmlns:app1="http://app1.org/app1/">..</app1:foo>
        <app2:bar xmlns:app2="http://app1.org/app2/">..</app2:bar>
    </metadata>
</domain>

下面介绍如何配置Domain各方面的细节。

虚拟机可以不同的方式启动，各有其优缺点。

对于全虚拟化的hypervisor可以选择通过BIOS启动，BIOS定义启动优先级，来确定从软盘、硬盘、光驱还是网络获取启动镜像（boot image）。配置示例：

<os>
    <type>hvm</type>
    <loader readonly='yes' secure='no' type='rom'>/usr/lib/xen/boot/hvmloader</loader>
    <nvram template='/usr/share/OVMF/OVMF_VARS.fd'>/var/lib/libvirt/nvram/guest_VARS.fd</nvram>
    <boot dev='hd'/>
    <boot dev='cdrom'/>
    <bootmenu enable='yes' timeout='3000'/>
    <smbios mode='sysinfo'/>
    <bios useserial='yes' rebootTimeout='0'/>
</os>

各子元素的说明如下：

当启动基于容器虚拟化的Domain时，需要指定一个init程序：

<os>
    <type arch='x86_64'>exe</type>
    <!-- init binary -->
    <init>/bin/systemd</init>
    <!-- argumsnts -->
    <initarg>--unit</initarg>
    <initarg>emergency.service</initarg>
</os>

如果你要启用user namespace映射，可以：

<idmap>
    <!-- start容器内第1个用户的ID，target容器内第1个用户映射到宿主机的用户的ID，count容器最多映射宿主机多少用户-->
    <uid start='0' target='1000' count='10'/>
    <gid start='0' target='1000' count='10'/>
</idmap>

<os>
    <smbios mode='sysinfo'/>
</os>
<!-- type属性必须，它的值决定子元素第布局-->
<sysinfo type='smbios'>
    <bios>
        <entry name='vendor'>LENOVO</entry>
    </bios>
    <system>
        <entry name='manufacturer'>Fedora</entry>
        <entry name='product'>Virt-Manager</entry>
        <entry name='version'>0.9.4</entry>
    </system>
    <baseBoard>
        <entry name='manufacturer'>LENOVO</entry>
        <entry name='product'>20BE0061MC</entry>
        <entry name='version'>0B98401 Pro</entry>
        <entry name='serial'>W1KS427111E</entry>
    </baseBoard>
</sysinfo>

配置示例如下：

<vcpu placement='static' cpuset="1-4,^3,6" current="1">2</vcpu>
<vcpus>
    <vcpu id='0' enabled='yes' hotpluggable='no' order='1'/>
    <vcpu id='1' enabled='no' hotpluggable='yes'/>
</vcpus>

此元素定义客户机最大的虚拟CPU的数量，有效值的范围是1-hypervisor支持的最大数量。属性说明如下：

此元素控制每个单独虚拟CPU的状态，每个vcpu子元素对应一个虚拟CPU，vcpu子元素的属性说明如下：

cputune元素可以对Domain的虚拟CPU进行微调，配置示例如下：

<cputune>
    <vcpupin vcpu="0" cpuset="1-4,^2"/>
    <vcpupin vcpu="1" cpuset="0,1"/>
    <vcpupin vcpu="2" cpuset="2,3"/>
    <vcpupin vcpu="3" cpuset="0,4"/>
    <emulatorpin cpuset="1-3"/>
    <iothreadpin iothread="1" cpuset="5,6"/>
    <iothreadpin iothread="2" cpuset="7,8"/>
    <shares>2048</shares>
    <period>1000000</period>
    <quota>-1</quota>
    <emulator_period>1000000</emulator_period>
    <emulator_quota>-1</emulator_quota>
    <iothread_period>1000000</iothread_period>
    <iothread_quota>-1</iothread_quota>
    <vcpusched vcpus='0-4,^3' scheduler='fifo' priority='1'/>
    <iothreadsched iothreads='2' scheduler='batch'/>
</cputune>

各子元素说明如下：

IO线程是一种专门的事件循环线程，用于提高磁盘Block I/O的scalability，这些线程会分配给支持的磁盘设备。每个物理CPU只有1-2个IO线程，每个IO线程也可能分配给多个磁盘设备。配置示例：

<!-- 分配给Domain使用的IO线程数-->
<iothreads>4</iothreads>

<!-- 定义每个IO线程的ID -->
<iothreadids>
    <iothread id="2"/>
    <iothread id="4"/>
    <iothread id="6"/>
    <iothread id="8"/>
</iothreadids>

配置示例如下：

<maxMemory slots='16' unit='KiB'>1524288</maxMemory>
<memory unit='KiB'>524288</memory>
<currentMemory unit='KiB'>524288</currentMemory>

各元素说明如下：

memoryBacking元素控制虚拟内存页如何映射到宿主机的内存页，配置示例：

<memoryBacking>
    <hugepages>
        <!-- 为了除4之外的numa节点分配1G的巨页 -->
        <page size="1" unit="G" nodeset="0-3,5"/>
        <page size="2" unit="M" nodeset="4"/>
    </hugepages>
    <nosharepages/>
    <locked/>
</memoryBacking>

子元素说明如下：

memtune提供Domain的内存微调参数，如果不设置这些参数，则使用OS提供的默认值。对于QEMU/KVM，这些参数限制包含QEMU进程本身的内存消耗

<memtune>
    <hard_limit unit='G'>1</hard_limit>
    <soft_limit unit='M'>128</soft_limit>
    <swap_hard_limit unit='G'>2</swap_hard_limit>
    <min_guarantee unit='bytes'>67108864</min_guarantee>
</memtune>

子元素说明如下：

numatune元素通过控制针对Domain进程的numa策略来影响宿主机的性能，配置示例如下：

<numatune>
    <memory mode="strict" nodeset="1-4,^3"/>
    <memnode cellid="0" mode="strict" nodeset="1"/>
    <memnode cellid="2" mode="preferred" nodeset="2"/>
</numatune>

子元素说明如下：

blkiotune元素能够微调Domain的Blkio cgroup可调整参数，如果不指定此元素，则使用OS默认值。配置示例如下：

<blkiotune>
    <weight>800</weight>
    <device>
        <path>/dev/sda</path>
        <weight>1000</weight>
    </device>
    <device>
        <path>/dev/sdb</path>
        <weight>500</weight>
        <read_bytes_sec>10000</read_bytes_sec>
        <write_bytes_sec>10000</write_bytes_sec>
        <read_iops_sec>20000</read_iops_sec>
        <write_iops_sec>20000</write_iops_sec>
    </device>
</blkiotune>

子元素说明如下：

对CPU型号、特性的要求，以及它的拓扑结构的要求，可以使用如下方式配置：

<cpu match='exact'>
    <model fallback='allow'>core2duo</model>
    <vendor>Intel</vendor>
    <topology sockets='1' cores='2' threads='1'/>
    <feature policy='disable' name='lahf_lm'/>
</cpu>

<cpu mode='host-model'>
    <model fallback='forbid'/>
    <topology sockets='1' cores='2' threads='1'/>
</cpu>

<cpu mode='host-passthrough'>
    <feature policy='disable' name='lahf_lm'/>
</cpu>

cpu元素是描述客户机CPU需求的容器元素，它的属性如下：

<numa>
    <cell id='0' cpus='0-3' memory='512000' unit='KiB'/>
    <cell id='1' cpus='4-7' memory='512000' unit='KiB' memAccess='shared'/>
</numa>

你可能需要覆盖某些事件发生时采取的动作，注意并非所有hypervisors支持所有事件和动作。使用

virsh reboot

virsh shutdown

<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>restart</on_crash>
<on_lockfailure>poweroff</on_lockfailure>

 事件类型采用元素表示：

这几种事件都支持的动作包括：

1. destroy，终止Domain并释放一切相关资源
2. restart，Domain被终止，并以相同的配置再次启动
3. preserve，Domain被终止但是其资源被保留供分析
4. rename-restart，以另外一个名字重启Domain

on_crash支持额外的动作：

1. coredump-destroy，崩溃Domain的core被dump出来，然后destroy
2. coredump-restart，崩溃Domain的core被dump出来，然后重启

仅QEMU支持，强制启用/禁止客户机BIOS的电源管理功能：

<pm>
    <!-- 是否启用ACPI的S4睡眠状态 -->
    <suspend-to-disk enabled='no'/>
    <!-- 是否启用ACPI的S3睡眠状态 -->
    <suspend-to-mem enabled='yes'/>
</pm>

Hypervisor能够启用/禁用一些CPU/机器特性。配置示例：

<features>
    <pae/> <!-- 物理地址扩展，允许32位客户机访问超过4GB内存 -->
    <acpi/> <!-- 对于电源管理有用，例如可以优雅的关闭KVM客户机 -->
    <apic/> <!-- 支持可编程的中断请求管理 -->
    <hap/>  <!-- 根据state=on|off，启禁硬件辅助paging -->
    <privnet/> <!-- 总是创建私有的网络命名空间，如果任何网络接口设备被添加，则自动设置。仅和容器虚拟化相关 -->
    <hyperv> <!-- 调整Windows客户机的性能，仅QEMU2.x -->
        <relaxed state='on'/>
        <vapic state='on'/>
        <spinlocks state='on' retries='4096'/>
        <vpindex state='on'/>
        <runtime state='on'/>
        <synic state='on'/>
        <reset state='on'/>
        <vendor_id state='on' value='KVM Hv'/>
    </hyperv>
    <kvm>
        <hidden state='on'/> <!-- 从标准的MSR发现中隐藏KVM的Hypervisor -->
    </kvm>
    <pvspinlock state='on'/>  <!-- 通知客户机，宿主机支持半虚拟化的自旋锁 -->
</features>

客户机的时间通常是基于宿主机时间来初始化的，大部分OS期望硬件中存储的是UTC时间，然而Windows期望的则是“本地时间”。

配置示例：

<clock offset='localtime'>
    <timer name='rtc' tickpolicy='catchup' track='guest'>
        <catchup threshold='123' slew='120' limit='10000'/>
    </timer>
    <timer name='pit' tickpolicy='delay'/>
</clock>

clock的offset属性控制客户机的时间如何与宿主机同步：

1. utc，客户机启动时总是基于UTC时间来同步
2. localtime，客户机启动时基于宿主机的timezone配置来同步时间
3. timezone，客户机基于指定的时区来同步
4. variable，客户机的时钟相对于UTC或者localtime（由basis属性指定，默认utc）具有一定的偏移，偏移量单位秒，由adjustment指定

提供给客户机的所有设备，都在

<devices>

可以使用下面的元素来指定模拟器全限定的路径：

<devices>
    <emulator>/usr/lib/xen/bin/qemu-dm</emulator>
</devices>

capabilities的XML配置指明了特定Domain类型-体系结构组合对应的最佳模拟器。

任何软盘、硬盘、光盘或者半虚拟化的驱动器，都是通过

disk

<devices>
    <!-- 后端支持是文件的磁盘，使用外部快照 -->
    <disk type='file' snapshot='external'>
        <!-- xen的驱动微调 -->
        <driver name="tap" type="aio" cache="default"/>
        <!-- 磁盘的源——文件的位置 -->
        <source file='/var/lib/xen/images/fv0' startupPolicy='optional'>
            <seclabel relabel='no'/>
        </source>
        <!-- 磁盘在客户机中的期望设备名，总线类型 -->
        <target dev='hda' bus='ide'/>
        <!-- IO节流阀 -->
        <iotune>
            <total_bytes_sec>10000000</total_bytes_sec>
            <read_iops_sec>400000</read_iops_sec>
            <write_iops_sec>100000</write_iops_sec>
        </iotune>
        <!-- 该磁盘可以作为启动盘，顺序2 -->
        <boot order='2'/>
        <!-- 启用磁盘加密 -->
        <encryption type='...'>
            ...
        </encryption>
        <shareable/><!-- 磁盘可以被多个Domain共享-->
        <serial>...</serial><!-- 指定磁盘序列号 -->
    </disk>
    <!-- 该磁盘的源位于网络上 -->
    <disk type='network'>
        <!-- QEMU驱动微调，指定AIO基于pthread -->
        <driver name="qemu" type="raw" io="threads" ioeventfd="on" event_idx="off"/>
        <!-- 基于sheepdog的网络源 -->
        <source protocol="sheepdog" name="image_name">
            <host name="hostname" port="7000"/><!-- 磁盘源所在的主机 -->
        </source>
        <target dev="hdb" bus="ide"/>
        <boot order='1'/>
        <transient/>
        <address type='drive' controller='0' bus='1' unit='0'/>
    </disk>
    <disk type='network'>
        <driver name="qemu" type="raw"/>
        <source protocol="rbd" name="image_name2">
            <host name="hostname" port="7000"/>
            <snapshot name="snapname"/>
            <config file="/path/to/file"/>
        </source>
        <target dev="hdc" bus="ide"/>
        <!-- 提供网络身份验证信息 -->
        <auth username='myuser'>
            <secret type='ceph' usage='mypassid'/>
        </auth>
    </disk>
    <!-- 定义一个光驱设备 -->
    <disk type='block' device='cdrom'>
        <driver name='qemu' type='raw'/>
        <target dev='hdd' bus='ide' tray='open'/>
    </disk>
    <!-- 定义一个光驱设备，使用ISO镜像文件 -->
    <disk type='file' device='cdrom'>
        <driver name='qemu' type='raw'/>
        <!-- 使用镜像文件 -->
        <source file='/home/alex/Vmware/KVM/coreos.iso'/>
        <target dev='hdd' bus='ide'/>
        <readonly/>
    </disk>
    <!-- 从libvirt管理的存储池中取得源 -->
    <disk type='volume' device='disk'>
        <driver name='qemu' type='qcow2'/>
        <source pool="default" volume="coreos.qcow2" />
        <target dev='vda' bus='virtio'/>
        <boot order='1'/>
    </disk>
    <!-- 来自iscsi池的源 -->
    <disk type='network' device='disk'>
        <driver name='qemu' type='raw'/>
        <source protocol='iscsi' name='iqn.gmem.cc.example:iscsi-nopool/2'>
            <host name='example.com' port='3260'/>
        </source>
        <auth username='myuser'>
            <secret type='iscsi' usage='libvirtiscsi'/>
        </auth>
        <target dev='vda' bus='virtio'/>
    </disk>
    <!-- 来自iscsi池的源，lun与disk不同的是，客户机的请求直接pass through到物理设备 -->
    <disk type='network' device='lun'>
        <driver name='qemu' type='raw'/>
        <source protocol='iscsi' name='iqn.gmem.cc.example:iscsi-nopool/1'>
            <host name='example.com' port='3260'/>
        </source>
        <auth username='myuser'>
            <secret type='iscsi' usage='libvirtiscsi'/>
        </auth>
        <target dev='sdb' bus='scsi'/>
    </disk>
    <disk type='file' device='disk'>
        <driver name='qemu' type='qcow2'/>
        <source file='/var/lib/libvirt/images/domain.qcow'/>
        <!-- 多级嵌套的backing store -->
        <backingStore type='file'>
            <format type='qcow2'/>
            <source file='/var/lib/libvirt/images/snapshot.qcow'/>
            <backingStore type='block'>
                <format type='raw'/>
                <source dev='/dev/mapper/base'/>
                <backingStore/>
            </backingStore>
        </backingStore>
        <target dev='vdd' bus='virtio'/>
    </disk>
</devices>

 指定磁盘的来源（source），其包含的属性依赖于disk的type属性：

source子元素可以包含以下子元素：

紧跟着source元素，用于指定磁盘使用的backing store ，backing store是构成磁盘的逻辑成分（类似于QEMU的backing file）。如果不指定此元素，则意味着source是自包含的。backingStore元素的属性列表如下：

backingStore可以有下列子元素：

此子元素控制虚拟磁盘在什么总线/设备下暴露给客户机。属性如下：

针对单块磁盘进行IO微调，与 blkiotune 功能类似，但是后者针对Domain全局。

目前可设置的微调项都是针对QEMU的IO throttling微调，这些微调由子元素指定，取值0表示无限制。子元素列表：

与hypervisor驱动相关的更多细节配置，属性列表：

用于指定该磁盘是可启动的，order属性指定其启动顺序。

指定卷如何被加密。

指定此磁盘不能被客户机修改，对于device=cdrom的设备默认true。

假设hypervisor和OS支持的话，指示此设备可以被多个Domain共享。指定此元素，应当同时禁用磁盘的缓存。

指示当客户机退出时，对磁盘的所有修改将回退。对于某些hypervisor，把磁盘标记为transient会禁止快照与迁移。

指定磁盘的序列号。

指定磁盘的世界范围名称（World Wide Name），此值必须唯一，由16位16进制数字组成。

指定磁盘的生产厂商，不超过8个可打印字符

指定磁盘的产品名称，不超过16个可打印字符

很多设备可以提供一个address 子元素，来指明设备挂载客户机虚拟总线的什么位置上。如果不指定address，libvirt会生成一个合适的地址。该子元素的属性列表如下：

对于disk.type=network，且protocol为rbd、iscsi的磁盘，可以指定此子元素，提供访问磁盘源时使用的凭据。

用于QEMU/KVM，覆盖块设备的属性。属性列表：

使用filesystem元素可以把宿主机上的目录直接暴露给客户机访问，配置示例：

<devices>
    <filesystem type='template'>
        <source name='my-vm-template'/><!-- OpenVZ模板名称 -->
        <target dir='/'/>
    </filesystem>
    <filesystem type='mount' accessmode='passthrough'>
        <driver type='path' wrpolicy='immediate'/>
        <source dir='/export/to/guest'/> <!-- 指定宿主机目录 -->
        <target dir='/import/from/host'/>
        <readonly/>
    </filesystem>
    <filesystem type='file' accessmode='passthrough'>
        <driver name='loop' type='raw'/>
        <driver type='path' wrpolicy='immediate'/>
        <source file='/export/to/guest.img'/>
        <target dir='/import/from/host'/>
        <readonly/>
    </filesystem>
</devices>

filesystem元素的属性列表：

子元素列表：

有几种方式（type）来指定客户机能够看到的网络接口，网络接口的容器元素是

interface

对于基于动态地址分配/无线网络的宿主机获得连接性的虚拟机，推荐此方式。

虚拟网络提供一个其详细信息由一个命名网络定义（named network definition）所描述的连接。依据虚拟网络的转发模式（forward mode）设置，它可能是：

1. 完全隔离的，不配置

   <forward>

    元素
2. NAT到一个指定的网络设备或者默认路由，配置

   <forward mode='nat'>

    
3. 不基于NAT来路由，配置

   <forward mode='route'/>

    
4. 直接连接到宿主机的网络接口（通过macvtap）或桥接设备，配置

   <forward mode='bridge|private|vepa|passthrough'/>

    

对于转发模式设置为bridge | private | vepa | passthrough的网络，宿主机在libvirt管理范围之外应拥有必要的DNS、DHCP服务。对于转发模式设置为isolated | nat |routed的网络，libvirt提供的虚拟网络中包含了DHCP和DNS。虚拟网络自动分配的IP地址范围可以通过命令

virsh net-dumpxml [networkname]

得到。一个开箱即用的、称为default的虚拟网络NAT到宿主机默认路由，其IP地址范围是192.168.122.0/24，在宿主机中你可以ifconfig看到一个名为virbr0的网络接口，与这个default虚拟网络有关。要自定义虚拟网络，需要修改其它类型（network XML）的配置文件L。

每个客户机会有一个命名为

vnetN

类似于direct类型的接口，network类型的接口可以指定一个virtualport子元素，用于将配置信息转发给vepa（802.1Qbg）或 802.1Qbh兼容的交换机，或Open vSwich虚拟交换机。

配置示例：

<devices>
    <interface type='network'>
        <!-- 如果接口的source是一个网络，则可以设置soure元素的portgroup属性，一个网络可能定义了多个portgroup，
             每个portgroup包含些许不同的配置信息，用于不同类别的网络连接 -->
        <source network='default'/>
    </interface>
    <interface type='network'>
        <!-- -->
        <source network='default' portgroup='engineering'/>
        <target dev='vnet7'/>  <!-- 设置虚拟网卡的名称 -->
        <mac address="00:11:22:33:44:55"/><!-- 设置虚拟网卡的MAC地址 -->
        <virtualport>
            <parameters instanceid='09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f'/>
        </virtualport>
    </interface>
</devices>

对于基于静态地址的有线网络的宿主机获得连接性的虚拟机，推荐此方式。

该方式将虚拟机直接桥接到宿主机所在的局域网，libvirt假设宿主机上的网桥设备enslaved了1-N个物理网卡。客户机的IP地址范围与宿主机局域网的IP地址范围一样。

在Linux系统中，网桥通常是标准的Linux主机网桥（host bridge）。如果主机支持Open vSwitch，则可以添加

<virtualport type='openvswitch'/>

每个客户机会有一个命名为

vnetN

配置示例：

<interface type='bridge'>
    <!-- 桥接到宿主机的br0网桥 -->
    <source bridge='br0'/>
</interface>
<interface type='bridge'>
    <source bridge='br1'/>
    <!-- 设置客户机中虚拟网卡的名称和MAC -->
    <target dev='vnet7'/>
    <mac address="00:11:22:33:44:55"/>
</interface>
<interface type='bridge'>
    <source bridge='ovsbr'/>
    <!-- 连接到Open vSwitch -->
    <virtualport type='openvswitch'>
        <!-- interfaceid是此虚拟网卡的唯一标识，如果不指定自动生成；profileid作为虚拟网卡的port-profile发送给vSwitch -->
        <parameters profileid='menial' interfaceid='09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f'/>
    </virtualport>
</interface>

提供一个虚拟局域网并NAT到外面的世界，此虚拟网络使用10.0.2.x网段。默认路由10.0.2.2，DNS服务器10.0.2.3，客户机地址从10.0.2.15开始。此网络仅仅用于没有特权的宿主机用户。配置示例：

<interface type='user'/>
<interface type='user'>
    <mac address="00:11:22:33:44:55"/>
</interface>

如果hypervisor支持，则可以设置虚拟网卡的型号。示例：

<interface type='network'>
    <model type='ne2k_pci'/>
</interface>

QEMU支持的型号包括 ne2k_isa i82551 i82557b i82559er ne2k_pci pcnet rtl8139 e1000 virtio。

可以设置网卡是启用还是断开的：

<interface type='network'>
    <link state='down'/>
</interface>

网络设备、具有网络特性的hostdev设备可以配置一个或者多个IP地址，某些hypervisor会忽略这些配置。配置示例：

<devices>
    <interface type='network'>
        <source network='default'/>
        <target dev='vnet0'/>
        <ip address='192.168.122.5' prefix='24'/>
        <!-- peer指定点对点连接中对端的IP地址 -->
        <ip address='192.168.122.5' prefix='24' peer='10.0.0.10'/>
        <!-- route仅用于LXC -->
        <route family='ipv4' address='192.168.122.0' prefix='24' gateway='192.168.122.1'/>
        <route family='ipv4' address='192.168.122.8' gateway='192.168.122.1'/>
    </interface>
    <hostdev mode='capabilities' type='net'>
        <source>
            <interface>eth0</interface>
        </source>
        <ip address='192.168.122.6' prefix='24'/>
        <route family='ipv4' address='192.168.122.0' prefix='24' gateway='192.168.122.1'/>
        <route family='ipv4' address='192.168.122.8' gateway='192.168.122.1'/>
    </hostdev>
</devices> 

配置图形（Graphical）设备，可以让你与客户机进行图形化的交互。客户机通常提供一个framebuffer或者text console，作为人机接口。配置示例：

<!-- 基于SDL的图形接口，弹出QEMU的图形化控制台窗口 -->
<graphics type='sdl' display=':0' xauth='/home/alex/.Xauthority'/>
<!-- 基于VNC的图形接口 -->
<graphics type='vnc' port='-1' autoport='yes' listen='0.0.0.0' sharePolicy='allow-exclusive'>
    <listen type='address' address='0.0.0.0'/>
</graphics>

<graphics type='rdp' autoport='yes' multiUser='yes'/>
<graphics type='desktop' fullscreen='yes'/>
<graphics type='spice'>
    <listen type='network' network='rednet'/>
</graphics>

根据强制属性type的取值，grpahics的属性、子元素有所差异：

<channel name='main' mode='secure'/>
<channel name='record' mode='insecure'/>

<image compression='auto_glz'/> 

<streaming mode='filter'/>

<clipboard copypaste='no'/> 

<mouse mode='client'/>

<filetransfer enable='no'/>

<gl enable='yes'/>

用于指明在何处监听客户机连接。

video是描述视频设备的容器，为了向后兼容，如果配置了graphics却没有配置video，libvirt会根据客户机的类型自动添加一个video。配置示例：

<!-- 默认第一个配置video是主视频设备，可以用primary属性覆盖 -->
<video primary='yes'>
    <model type='vga' vram='16384' heads='1'>
        <acceleration accel3d='yes' accel2d='yes'/>
    </model>
</video>
<video>
   <!-- 下面的配置是KVM客户机的默认值 -->
   <model type='cirrus' vram='16384' heads='1' />
</video>

子元素说明如下：

libguestfs是一组工具集，用来（在不启动客户机的情况下）访问、修改虚拟机的磁盘文件，通过libguestfs你可以好对磁盘进行以下操作：

1. 查看或者修改文件
2. 创建虚拟磁盘
3. 改变虚拟磁盘大小
4. 执行磁盘备份、克隆等操作

libguestfs支持多种虚拟磁盘格式，包括Vmware、Hyper-V。日常工作中我们主要使用libguestfs提供的命令行guestfish。libguestfs不依赖于libvirt。

与libguestfs类型工具包括：

1. kpartx 需要root权限，并且将文件系统挂载到宿主机的内核中。相比之下libguestfs把文件系统隔离在appliance中，安全性高
2. vdfuse 该工具类似于kpartx，但是仅仅针对VirtualBox虚拟磁盘
3. qemu-nbd  用QEMU提供的工具，基于QEMU支持的磁盘格式（raw、qcow2）构建网络块服务器。libguestfs可以与之配合使用：
   

   guestfish -a nbd://remote

执行下面的命令安装libguestfs：

sudo apt-get install libguestfs-tools

在Ubuntu下，需要执行：

sudo chmod 0644 /boot/vmlinuz* 

否则在使用过程中你会遇到cp: cannot open '/boot/vmlinuz-4.4.0-38-generic' for reading: Permission denied错误。

执行下面的命令，以编辑一个虚拟磁盘：

# 附加-v参数，可以看到很多调试信息，例如appliance的启动过程日志
guestfish -a vda.qcow2

# 出现提示符
><fs> 

# 添加一个磁盘，只能在run之前执行
# add-drive filename [readonly:true|false] [format:..] [iface:..] [name:..] [label:..] [protocol:..] [server:..]
add-drive vdb,qcow2 format:qcow2

# 执行run命令，一个appliance（类似于微型虚拟机）会被启动
><fs> run

# 列出设备
><fs> list-devices
# 输出：/dev/sda

# 列出分区
><fs> list-partitions
# 输出：
# /dev/sda1
# /dev/sda2

# 显示各分区详细信息
><fs> part-list /dev/sda
# [0] = {
#   part_num: 1
#   part_start: 1048576
#   part_end: 525336575
#   part_size: 524288000
# }
# [1] = {
#   part_num: 2
#   part_start: 525336576
#   part_end: 17179869183
#   part_size: 16654532608
# }
# 测试第一个分区是否可启动
><fs> part-get-bootable /dev/sda 1
# 其它分区相关命令： part-add，part-del，part-disk，part-get-bootable，part-get-gpt-type，part-get-mbr-id，
#                 part-get-name，part-get-parttype，part-init，part-list，part-set-bootable，part-set-gpt-type，
#                 part-set-mbr-id，part-set-name，part-to-dev，part-to-partnum

# 操作LVM
# 显示物理卷详细信息
pvs-full 
# 显示逻辑卷组详细信息
vgs-full
# 其它LVM相关命令：
# lvcreate, lvcreate-free, lvm-canonical-lv-name, lvm-clear-filter, lvm-remove-all, lvm-set-filter, 
# lvremove, lvrename, lvresize, lvresize-free, lvs, lvs-full, lvuuid, pvcreate, pvremove, pvresize, 
# pvresize-size, pvs, pvs-full, pvuuid, vg-activate, vg-activate-all, vgchange-uuid, vgchange-uuid-all, 
# vgcreate, vglvuuids, vgmeta, vgpvuuids, vgremove, vgrename, vgs, vgs-full, vgscan, vguuid
# 列出文件系统
><fs> list-filesystems
# 输出：
# /dev/sda1: ext4
# /dev/fedora_bogon/root: xfs
# /dev/fedora_bogon/swap: swap

# 挂载文件系统
><fs> mount /dev/fedora_bogon/root /

# 列出目录
><fs> ls /
# 创建新目录
><fs> mkdir /temp
# 其它支持的文件系统命令包括：cp chown chmod cp

# 下载文件到当前目录
download /root/.bash_history test
# 上传文件到虚拟磁盘
upload test /temp/test

# 查看文件内容
cat /temp/test

# 退出
><fs> quit

执行run子命令后，需要等待一会，这时libguestfs在启动一个 appliance。再此appliance中会运行一个Linux内核，LVM、ext2等用户空间工具，以及一个守护程序guestfsd。宿主机进程基于RPC与这个守护进程通信，完成对磁盘镜像的操作。

该命令可以把虚拟磁盘挂载到宿主机的目录上：

# 创建挂载点
mkdir vda
# 挂载一个文件系统
guestmount -a vda.qcow2 --rw -m /dev/fedora_bogon/root vda
# 现在你可以在宿主机中修改虚拟磁盘中的文件
# 操作完毕后，取消挂载
guestunmount vda

该命令可以用来快速的创建虚拟机磁盘镜像：

# 列出所有支持的客户机类型
virt-builder --list
# 创建一个Fedora 24的虚拟磁盘镜像，第一次使用某个客户机类型，需要从网络上下载镜像文件
virt-builder fedora-24 
    -o fedora-24.qcow2 --format qcow2 --size 20G 
    --hostname fedora-24-01   # 设置主机名
    --root-password file:/tmp/pswd  # 设置root密码，密码从文件中读取
    --install "apache2"  # 安装软件
    --firstboot  /tmp/fb.sh  # 第一次启动时执行的脚本

virt-ls -a vda.qcow2 /

virt-cat -a vda.qcow2 /root/.bashrc

virt-copy-in -a vda.qcow2 hello /root/

virt-copy-out -a vda.qcow2 /root/hello .

通过配置libvirt的虚拟局域网，可以简化Domain的网络接口配置，比QEMU的脚本方式好很多。此外虚拟局域网还提供DHCP服务。

libvirt引入了virtual network switch的概念，这是运行在宿主机上的软件。客户机可以“插入”到这个交换机上并传递流量。在Linux宿主机上，这个交换机表现为网络接口——默认情况下名字为virbr0，这个接口实质上是一个网桥。

默认情况下虚拟网络交换机工作在NAT模式下，实质上是基于宿主机的iptables设置IP遮掩（不使用SNAT/DNAT），客户机对外通信时，使用宿主机的IP地址。

与NAT不同，这种模式直接转发客户机的IP封包，不进行NAT转换。这需要物理网络的路由器配置适当的路由，让客户机子网的流量流向所在的宿主机。

这种模式下，虚拟网络交换机不把客户机的IP封包转发到真实网络上去。只有宿主机、各客户机之间可以进行通信。

每个虚拟网络交换机可以设置一个用于动态分配的IP地址范围，供连接到此交换机的客户机使用，客户机可以通过DHCP服务自动获得IP地址。

libvirt基于dnsmasq实现DHCP和DNS，对于每个需要DHCP的虚拟网络交换机，libvirt在宿主机上启动一个dnsmasq实例。

除了简单的DNS请求转发，dnsmasq可以做更多的事情：

1. 它可以读取宿主机的 /etc/hosts 中条目，来应答DNS查询请求

一个可能的虚拟网络架构的逻辑图如下：

对应的物理拓扑如下：

其中：

1. VLAN 1，这个虚拟局域网通过网桥virbr0与eth1进行桥接，并基于NAT连接到真实局域网lan2
2. VLAN 2，这个虚拟局域网桥接到virbr0，但是与真实局域网完全隔离
3. Guest A，该虚拟机的：
   1. eth0桥接到宿主机的网桥eth0，后者直接连接到真实网卡pth0，从而与lan1互联
   2. eth1桥接到virbr0，可以基于NAT受限访问lan2
4. Guest B，基于NAT、隔离网络
5. Guest C，基于隔离网络

# 列出所有活动的虚拟局域网，libvrit默认创建一个桥接到virbr0的vlan，名为default
virsh net-list
#  Name                 State      Autostart     Persistent
# ----------------------------------------------------------
#  default              active     yes           yes

# 列出所有虚拟局域网
virsh net-list --all

# 显示一个虚拟局域网的详细信息
net-info default
# Name:           default
# UUID:           e9e308a3-dea9-46dc-bc92-fad27f2a970a
# Active:         yes
# Persistent:     yes
# Autostart:      yes
# Bridge:         virbr0

# 导出一个虚拟局域网的XML
virsh net-dumpxml default

# 定义一个新的虚拟局域网
virsh net-define /home/alex/Vmware/KVM/vlans/default.xml
# 解除虚拟局域网定义
virsh net-undefine default

# 关闭一个虚拟局域网
virsh net-destroy default

# 将一个虚拟局域网标记为自动启动
net-autostart default

# 启动虚拟局域网，启动后，宿主机上可能出现一个网桥设备
net-start default

类似于Domain，虚拟局域网的配置也是存放在XML文件中的。每个虚拟局域网对应一个XML配置文件，根元素为network。包括属性：

包含以下基本子元素：

以下子元素用于配置VLAN的连通性：

<bridge name='br'/>

<virtualport type='openvswitch'/>

<interface dev='eth0' />

# sudo iptables -t nat -L -nv

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in  out     source         destination         
    0     0 MASQUERADE  tcp  --  *   wlan0   10.0.0.0/16   !10.0.0.0/16   masq ports: 1024-65535
    0     0 MASQUERADE  udp  --  *   wlan0   10.0.0.0/16   !10.0.0.0/16   masq ports: 1024-65535
    0     0 MASQUERADE  all  --  *   wlan0   10.0.0.0/16   !10.0.0.0/16

<!-- 桥接到物理网络，基于macvtap -->
<network connections='1'>
  <name>default</name>
  <uuid>519cbf63-8ec0-4893-ba9c-0747430bdecd</uuid>
  <forward dev='eth0' mode='bridge'>
    <interface dev='eth0' connections='1'/>
  </forward>
</network>

<!-- NAT转发，创建VLAN -->
<network connections='1'>
  <name>default</name>
  <uuid>9bae4de8-ca58-48c5-ba58-109aebf8b954</uuid>
  <forward mode='nat' dev="wlan0">
    <nat>
      <port start='1024' end='65535'/>
    </nat>
  </forward>
  <bridge name='virbr0' stp='off' delay='0'/>
  <mac address='de:ad:be:ef:00:00'/>
  <ip address='10.0.0.1' netmask='255.0.0.0'>
    <dhcp>
      <range start='10.0.0.100' end='10.0.0.200'/>
      <host mac='DE:AD:BE:EF:00:02' ip='10.0.0.2'/>
    </dhcp>
  </ip>
</network>

<bandwidth>
    <inbound average='1000' peak='5000' burst='5120'/>
    <outbound average='128' peak='256' burst='256'/>
</bandwidth>

<!-- 子网10.0.0.0/8，网桥地址10.0.0.1 -->
<ip address='10.0.0.1' netmask='255.0.0.0'>

<dhcp>
    <!-- 自动分配的地址范围 -->
    <range start='10.0.0.100' end='10.0.0.200'/>
    <!-- 对于给定的MAC地址，总是绑定到某个IP、机器网络名 -->
    <host mac="DE:AD:BE:EF:F1:10" name="fedora-10" ip="10.0.0.10" />
</dhcp>

<!-- 如果enable为no，则libvirt不会启动DNS服务 -->
<dns enable="yes">
    <!--
        每个forwarder元素定义一个备选DNS服务器：
        如果指定domain属性，则仅针对该domain下的子域名的查询请求转发给addr对应的DNS服务器
    -->
    <forwarder addr="8.8.8.8"/>
    <forwarder domain='example.com' addr="8.8.4.4"/>
    <forwarder domain='www.example.com'/>
    <!-- 静态DNS映射 -->
    <host ip='10.0.0.10'>
        <hostname>fedora-10</hostname>
        <hostname>fedora-10.local</hostname>
    </host>
</dns>

<mac address='DE:AD:BE:EF:F1:00'/>

当你创建一个新的虚拟网络后，libvrit会在

/etc/libvirt/qemu/networks

基于NAT转发，启用DHCP，静态映射MAC到IP地址的例子：

<network>
  <name>default</name>
  <forward mode='nat'>
  </forward>
  <bridge name='virbr0' stp='off' delay='0'/>
  <mac address='DE:AD:BE:EF:F1:00'/>
  <ip address='10.0.0.1' netmask='255.0.0.0'>
    <dhcp>
      <range start='10.0.0.100' end='10.0.0.200'/>
      <host mac="DE:AD:BE:EF:F1:10" ip="10.0.0.10" />
      <host mac="DE:AD:BE:EF:F1:11" ip="10.0.0.11" />
    </dhcp>
  </ip>
</network>

使用宿主机既有网桥的例子： 

<network>
    <name>default</name>
    <forward mode="bridge"/>
    <!-- br1是宿主机上既有的网桥，它可能直接连接到物理网络 -->
    <bridge name="br1"/>
</network>

macvtap直连，需要 2.6.34+内核、仅支持QEMU/KVM。通过macvtap可以通过一组物理网络接口（不需要网桥）之一，直接连接到物理网络。客户机将直接具有物理网络的子网IP地址，并且与物理网络中其它机器互联互通。示例：

<network>
    <name>direct-macvtap</name>
    <forward mode="bridge">
        <interface dev="eth0"/>
        <interface dev="eth1"/>
    </forward>
</network>

通过存储池，libvirt集中管理物理机器上的存储资源，供客户机使用。存储池被划分为卷（volume），卷则可以作为块设备分配给客户机使用。

libvirt支持以下类型的存储池后端：

通常存储管理员负责维护存储设备，例如NFS服务器。而宿主机的管理员定义存储池，存储池包含了NFS shares到挂载目录的映射。当存储池启动时，libvirt会自动执行挂载操作。一旦存储池启动完毕，NFS share中的文件被当作卷看待，你可以在客户机的Domain配置文件中引用卷的路径，作为块设备的source。

使用NFS时，基于libvirt的API可以在池中创建/删除卷（即NFS上的文件），但是不能超过池的尺寸限制（NFS share有容量控制）。注意不是所有类型的池支持卷的创建/删除操作。 

你可以通过XML文件来定义存储池，使用virsh命令可以定义、启动、停止、解除定义池，就像操作Domain、虚拟网络一样。你的配置文件被libvrit修改后，存放在

/etc/libvirt/storage/

<!-- 基于本地目录的存储池 -->
<pool type="dir">
    <name>virtimages</name>
    <target>
        <path>/var/lib/virt/images</path>
    </target>
</pool>

<!-- 基于iscsi的存储池 -->
<pool type="iscsi">
    <name>virtimages</name>
    <source>
        <host name="iscsi.example.com"/>
        <device path="iqn.2013-06.com.example:iscsi-pool"/>
        <auth type='chap' username='myuser'>
            <secret usage='libvirtiscsi'/>
        </auth>
    </source>
    <target>
        <path>/dev/disk/by-path</path>
    </target>
</pool>

<!-- 基于本地文件系统的池 -->
<pool type="fs">
    <name>sda</name>
    <source>
        <!-- 使用的文件系统 -->
    	<device path="/dev/sda3"/>
  	</source>
    <target>
    	<!-- 指定挂载点 -->
        <path>/home/alex/Vmware/libvirt/images/sda</path>
        <permissions>
            <mode>0777</mode>
        </permissions>
    </target>
</pool>

一个存储池配置的根元素为pool，最基础的配置项如下：

<pool type="iscsi">
    <name>virtimages</name>
    <uuid>3e3fce45-4f53-4fa7-bb32-11f34168b82b</uuid>
    <allocation>10000000</allocation>
    <capacity>50000000</capacity>
    <available>40000000</available>
</pool>

属性和子元素说明如下：

存储池具有最多一个（某些类型的池后端没有）source子元素，用于描述池的来源。source包含的内容取决于池的type。 配置示例：

<!-- disk池配置 -->
<source>
    <device path='/dev/mapper/mpatha' part_separator='no'/>
    <format type='gpt'/>
</source>

<!-- SCSI池配置 -->
<source>
    <adapter type='scsi_host' name='scsi_host1'/>
</source>
<source>
    <adapter type='scsi_host'>
        <parentaddr unique_id='1'>
            <address domain='0x0000' bus='0x00' slot='0x1f' addr='0x2'/>
        </parentaddr>
    </adapter>
</source>

各子元素说明如下：

对于dir, fs, netfs, logical, disk, iscsi, scsi, mpath类型池后端，可以具有单个target子元素。该元素描述如何映射存储池的source到宿主机的文件系统命名空间。配置示例：

<target>
    <path>/dev/disk/by-path</path>
    <permissions>
        <owner>107</owner>
        <group>107</group>
        <mode>0744</mode>
        <label>virt_image_t</label>
    </permissions>
    <timestamps>
        <atime>1341933637.273190990</atime>
        <mtime>1341930622.047245868</mtime>
        <ctime>1341930622.047245868</ctime>
    </timestamps>
    <encryption type='...'></encryption>
</target>

各子元素说明如下：

存储卷，通常对应一个文件或者设备节点。注意：当创建了存储池后，池中的镜像文件会被libvirt自动识别，并创建相应的卷定义。

配置示例：

<!-- 基于文件的卷 -->
<volume type='file'>
    <name>fedora-10.qcow2</name>
    <capacity unit='GiB'>16</capacity>
    <target>
        <path>/home/alex/Vmware/libvirt/images/fedora-10.qcow2</path>
        <format type='qcow2'/>
        <permissions>
            <mode>0666</mode>
        </permissions>
    </target>
    <backingStore>
        <path>/home/alex/Vmware/libvirt/images/fedora-base.qcow2</path>
        <format type='qcow2'/>
        <permissions>
            <mode>0666</mode>
        </permissions>
    </backingStore>
</volume>
<!-- 使用LUKS加密的卷-->
<volume>
    <name>MyLuks.img</name>
    <capacity unit="G">5</capacity>
    <target>
        <path>/var/lib/virt/images/MyLuks.img</path>
        <format type='raw'/>
        <encryption format='luks'>
            <secret type='passphrase' uuid='f52a81b2-424e-490c-823d-6bd4235bc572'/>
        </encryption>
    </target>
</volume>

一个卷配置的根元素是volume，最基础的配置项如下：

<volume type='file'>
    <name>sparse.img</name>
    <key>/var/lib/xen/images/sparse.img</key>
    <allocation>0</allocation>
    <capacity unit="T">1</capacity>
</volume>

 属性和子元素说明如下：

volume包含一个target子元素，指定卷如何映射到宿主机的文件系统中：

volume可能包含一个backingStore子元素，用来描述卷的copy-on-write后端存储，配置示例：

<backingStore>
    <path>/var/lib/virt/images/master.img</path>
    <format type='raw'/>
    <permissions>
        <owner>107</owner>
        <group>107</group>
        <mode>0744</mode>
        <label>virt_image_t</label>
    </permissions>
</backingStore> 

在不同宿主机之间迁移客户机是比较复杂的问题，为了应对不同的需求，libvirt实现了多种解决方案。

从数据传输的角度来看，libvirt支持两种类型的迁移：

从通信控制路径角度来看，libvirt支持三种类型的迁移：

迁移时，客户机的内存需要完整的在网络上传输，这可能导致客户机中的敏感信息被嗅探。

如果宿主机有多个网络接口，或者交换机支持Tagged虚拟局域网，最好将客户机的网络流量和迁移/管理网络流量隔离开来。

某些场景下，仅仅依靠网络隔离不能满足安全性需要，这时，需要使用libvirt的tunnelled传输，启用数据加密。

所谓离线迁移，就是把源主机的Domain状态设置为inactive，并且在迁移完毕后，Domain在源主机上继续运行，在目标主机上保持inactive状态。目前离线迁移不支持拷贝非共享存储。

开发虚拟机固件（Open Virtual Machine Firmware）是一个为虚拟机提供UEFI支持的项目。从Linux 3.9开始，配合最近版本的QEMU，能够支持PCI设备直通，例如将显卡直接分配给虚拟机，这样虚拟机就获得接近原生显卡的性能。

对于Intel CPU，除了CPU需要支持VT-x之外，还需要支持VT-d（Intel Virtualization Technology for Directed I/O ）。此技术改善系统的安全性、可靠性，同时支持提升虚拟化环境下的IO性能。

Intel的VT-d和AMD的AMD-Vi，通称IOMMU。IOMMU特性不但要求CPU支持，主板、BIOS也需要配合。开启IOMMU能够实现PCI直通、内存保护（免于被恶意、缺陷设备错误修改）。

intel_iommu=on iommu=pt

设置iommu=pt能够防止内核触碰不能直通的设备。

重启后，使用下面的命令确认IOMMU已经正确启用： 

dmesg | grep -i -e DMAR -e IOMMU
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.8.0-45-generic root=UUID=66acedc4-69d6-48b2-888c-9516089e004a ro quiet splash net.ifnames=0 biosdevname=0 intel_iommu=on iommu=pt vt.handoff=7
[    0.010062] ACPI: DMAR 0x0000000073AE3000 0000C8 (v01 INTEL  CML      00000002 INTL 01000013)
[    0.223797] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.8.0-45-generic root=UUID=66acedc4-69d6-48b2-888c-9516089e004a ro quiet splash net.ifnames=0 biosdevname=0 intel_iommu=on iommu=pt vt.handoff=7
# IOMMU被启用
[    0.223929] DMAR: IOMMU enabled
[    0.546449] DMAR: Host address width 39
[    0.546450] DMAR: DRHD base: 0x000000fed90000 flags: 0x0
[    0.546455] DMAR: dmar0: reg_base_addr fed90000 ver 1:0 cap 1c0000c40660462 ecap 19e2ff0505e
[    0.546456] DMAR: DRHD base: 0x000000fed91000 flags: 0x1
[    0.546459] DMAR: dmar1: reg_base_addr fed91000 ver 1:0 cap d2008c40660462 ecap f050da
[    0.546460] DMAR: RMRR base: 0x0000007372c000 end: 0x0000007374bfff
[    0.546461] DMAR: RMRR base: 0x00000078000000 end: 0x0000007c7fffff
[    0.546462] DMAR: RMRR base: 0x00000073792000 end: 0x00000073811fff
[    0.546464] DMAR-IR: IOAPIC id 2 under DRHD base  0xfed91000 IOMMU 1
[    0.546465] DMAR-IR: HPET id 0 under DRHD base 0xfed91000
[    0.546465] DMAR-IR: Queued invalidation will be enabled to support x2apic and Intr-remapping.
[    0.549640] DMAR-IR: Enabled IRQ remapping in x2apic mode
[    4.330593] iommu: Default domain type: Passthrough (set via kernel command line)
[    4.510270] DMAR: No ATSR found
[    4.510351] DMAR: dmar0: Using Queued invalidation
[    4.510354] DMAR: dmar1: Using Queued invalidation
# PCI设备被加入到的分组信息
[    4.510868] pci 0000:00:00.0: Adding to iommu group 0
[    4.510888] pci 0000:00:01.0: Adding to iommu group 1
[    4.510901] pci 0000:00:02.0: Adding to iommu group 2
[    4.510911] pci 0000:00:04.0: Adding to iommu group 3
[    4.510928] pci 0000:00:12.0: Adding to iommu group 4
[    4.510950] pci 0000:00:14.0: Adding to iommu group 5
[    4.510963] pci 0000:00:14.2: Adding to iommu group 5
[    4.510975] pci 0000:00:14.3: Adding to iommu group 6
[    4.510997] pci 0000:00:15.0: Adding to iommu group 7
[    4.511008] pci 0000:00:15.1: Adding to iommu group 7
[    4.511031] pci 0000:00:16.0: Adding to iommu group 8
[    4.511042] pci 0000:00:16.3: Adding to iommu group 8
[    4.511087] pci 0000:00:1b.0: Adding to iommu group 9
[    4.511121] pci 0000:00:1b.4: Adding to iommu group 9
[    4.511161] pci 0000:00:1c.0: Adding to iommu group 10
[    4.511197] pci 0000:00:1c.5: Adding to iommu group 10
[    4.511226] pci 0000:00:1d.0: Adding to iommu group 11
[    4.511265] pci 0000:00:1f.0: Adding to iommu group 12
[    4.511277] pci 0000:00:1f.3: Adding to iommu group 12
[    4.511290] pci 0000:00:1f.4: Adding to iommu group 12
[    4.511301] pci 0000:00:1f.5: Adding to iommu group 12
[    4.511316] pci 0000:00:1f.6: Adding to iommu group 12
[    4.511321] pci 0000:01:00.0: Adding to iommu group 1
[    4.511325] pci 0000:01:00.1: Adding to iommu group 1
[    4.511330] pci 0000:01:00.2: Adding to iommu group 1
[    4.511335] pci 0000:01:00.3: Adding to iommu group 1
[    4.511350] pci 0000:02:00.0: Adding to iommu group 9
[    4.511363] pci 0000:03:00.0: Adding to iommu group 9
[    4.511373] pci 0000:04:00.0: Adding to iommu group 10
[    4.511383] pci 0000:05:00.0: Adding to iommu group 10
[    4.511392] pci 0000:05:01.0: Adding to iommu group 10
[    4.511399] pci 0000:05:02.0: Adding to iommu group 10
[    4.511409] pci 0000:05:04.0: Adding to iommu group 10
[    4.511435] pci 0000:06:00.0: Adding to iommu group 10
[    4.511458] pci 0000:3a:00.0: Adding to iommu group 10
[    4.511471] pci 0000:6e:00.0: Adding to iommu group 10
[    4.511484] pci 0000:6f:00.0: Adding to iommu group 11
# VT-d被启用
[    4.511850] DMAR: Intel(R) Virtualization Technology for Directed I/O
[    4.711749]     intel_iommu=on

使用下面的脚本可以更加清楚的看到PCI设备是如何并映射到IOMMU分组的：

#!/bin/bash
shopt -s nullglob
for g in `find /sys/kernel/iommu_groups/* -maxdepth 0 -type d | sort -V`; do
    echo "IOMMU Group ${g##*/}:"
    for d in $g/devices/*; do
        echo -e "\t$(lspci -nns ${d##*/})"
    done;
done;

输出如下： 

IOMMU Group 0:
	00:00.0 Host bridge [0600]: Intel Corporation Device [8086:9b44] (rev 02)
# Nvidia显卡被分配在组1
IOMMU Group 1:
	00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor PCIe Controller (x16) [8086:1901] (rev 02)
	01:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU104GLM [Quadro RTX 5000 Mobile / Max-Q] [10de:1eb5] (rev a1)
	01:00.1 Audio device [0403]: NVIDIA Corporation TU104 HD Audio Controller [10de:10f8] (rev a1)
	01:00.2 USB controller [0c03]: NVIDIA Corporation TU104 USB 3.1 Host Controller [10de:1ad8] (rev a1)
	01:00.3 Serial bus controller [0c80]: NVIDIA Corporation TU104 USB Type-C UCSI Controller [10de:1ad9] (rev a1)
# Intel集成显卡被分配在组2
IOMMU Group 2:
    #                                                                  设备ID
	00:02.0 VGA compatible controller [0300]: Intel Corporation Device [8086:9bf6] (rev 05)
IOMMU Group 3:
	00:04.0 Signal processing controller [1180]: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem [8086:1903] (rev 02)
IOMMU Group 4:
	00:12.0 Signal processing controller [1180]: Intel Corporation Comet Lake PCH Thermal Controller [8086:06f9]
IOMMU Group 5:
	00:14.0 USB controller [0c03]: Intel Corporation Comet Lake USB 3.1 xHCI Host Controller [8086:06ed]
	00:14.2 RAM memory [0500]: Intel Corporation Comet Lake PCH Shared SRAM [8086:06ef]
# 无线网卡被分到组6
IOMMU Group 6:
	00:14.3 Network controller [0280]: Intel Corporation Wi-Fi 6 AX201 [8086:06f0]
IOMMU Group 7:
	00:15.0 Serial bus controller [0c80]: Intel Corporation Comet Lake PCH Serial IO I2C Controller #0 [8086:06e8]
	00:15.1 Serial bus controller [0c80]: Intel Corporation Comet Lake PCH Serial IO I2C Controller #1 [8086:06e9]
IOMMU Group 8:
	00:16.0 Communication controller [0780]: Intel Corporation Comet Lake HECI Controller [8086:06e0]
	00:16.3 Serial controller [0700]: Intel Corporation Device [8086:06e3]
# 指纹识别器、三星硬盘被分到组9
IOMMU Group 9:
	00:1b.0 PCI bridge [0604]: Intel Corporation Comet Lake PCI Express Root Port #17 [8086:06c0] (rev f0)
	00:1b.4 PCI bridge [0604]: Intel Corporation Comet Lake PCI Express Root Port #21 [8086:06ac] (rev f0)
	02:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller SM981/PM981/PM983 [144d:a808]
	03:00.0 Non-Volatile memory controller [0108]: Silicon Motion, Inc. Device [126f:2262] (rev 03)
# 雷电、读卡器被分到组10
IOMMU Group 10:
	00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:06b8] (rev f0)
	00:1c.5 PCI bridge [0604]: Intel Corporation Device [8086:06bd] (rev f0)
	04:00.0 PCI bridge [0604]: Intel Corporation JHL7540 Thunderbolt 3 Bridge [Titan Ridge 4C 2018] [8086:15ea] (rev 06)
	05:00.0 PCI bridge [0604]: Intel Corporation JHL7540 Thunderbolt 3 Bridge [Titan Ridge 4C 2018] [8086:15ea] (rev 06)
	05:01.0 PCI bridge [0604]: Intel Corporation JHL7540 Thunderbolt 3 Bridge [Titan Ridge 4C 2018] [8086:15ea] (rev 06)
	05:02.0 PCI bridge [0604]: Intel Corporation JHL7540 Thunderbolt 3 Bridge [Titan Ridge 4C 2018] [8086:15ea] (rev 06)
	05:04.0 PCI bridge [0604]: Intel Corporation JHL7540 Thunderbolt 3 Bridge [Titan Ridge 4C 2018] [8086:15ea] (rev 06)
	06:00.0 System peripheral [0880]: Intel Corporation JHL7540 Thunderbolt 3 NHI [Titan Ridge 4C 2018] [8086:15eb] (rev 06)
	3a:00.0 USB controller [0c03]: Intel Corporation JHL7540 Thunderbolt 3 USB Controller [Titan Ridge 4C 2018] [8086:15ec] (rev 06)
	6e:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS525A PCI Express Card Reader [10ec:525a] (rev 01)
IOMMU Group 11:
	00:1d.0 PCI bridge [0604]: Intel Corporation Comet Lake PCI Express Root Port #9 [8086:06b0] (rev f0)
	6f:00.0 Non-Volatile memory controller [0108]: Silicon Motion, Inc. Device [126f:2262] (rev 03)
# 有线网卡被分到组12
IOMMU Group 12:
	00:1f.0 ISA bridge [0601]: Intel Corporation Device [8086:068e]
	00:1f.3 Multimedia audio controller [0401]: Intel Corporation Comet Lake PCH cAVS [8086:06c8]
	00:1f.4 SMBus [0c05]: Intel Corporation Comet Lake PCH SMBus Controller [8086:06a3]
	00:1f.5 Serial bus controller [0c80]: Intel Corporation Comet Lake PCH SPI Controller [8086:06a4]
	00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet Connection (10) I219-LM [8086:0d4e] 

需要注意，IOMMU组是直通的最小调度单元。也就是说，你可能被迫将多个设备一起直通给虚拟机，或者将设备放到其他PCI插槽。

为了将设备分配给虚拟机，它和它所在分组的所有其他设备的驱动，必须更换为一个占位符驱动（stub 或 VFIO驱动）。这样，宿主机就不会和该设备进行交互。大部分设备，可以在启动虚拟机之前，即席的完成驱动更换操作。

对于显卡，没有这么方便。GPU驱动通常对动态rebinding支持的不好，不能将宿主机上正在使用的GPU透明的直通给虚拟机。因此，我们需要在宿主机启动时，尽早将占位符驱动bind给GPU。这样，除非驱动被换回，或者虚拟机claim该GPU，它会保持inactive状态。

之所以要求尽早，是因为Linux现有的驱动机制是每个驱动在初始化时，自行去寻找没有初始化的，自己关注的硬件。因此驱动的初始化顺序非常关键。如果慢了，物理驱动就会抢先绑定设备。

从内核4.1开始，VFIO驱动vfio-pci被包含其中。可以用来代替pci-stub。

修改内核参数：

pci-stub.ids=8086:9bf6

pci-stub根据ID来识别设备，也就是说，我们需要提供用于直通的PCI设备的ID。对于上面的输出中，Intel显卡的ID是8086:9bf6。

如果要绑定多个设备，ID需要用逗号分隔。 

随后我们需要执行下面的命令并重启：

sudo update-grub

内核总是先初始化所有内建的驱动，然后才逐个初始化外部模块。 在外部模块中，我们可以通过softdep来增加模块间的依赖关键： 例如我们可以把vfio-pci列为nvidia的依赖，那么vfio-pci总会被在nvidia之前初始化，而确保能抢占到硬件。

我们首先需要弄清楚，需要直通的硬件，当前是被什么驱动所绑定：

lspci -nnv

00:02.0 VGA compatible controller [0300]: Intel Corporation Device [8086:9bf6] (rev 05) (prog-if 00 [VGA controller])
	DeviceName: Onboard IGD
	Subsystem: Hewlett-Packard Company Device [103c:8780]
	Flags: bus master, fast devsel, latency 0, IRQ 221
	Memory at df000000 (64-bit, non-prefetchable) [size=16M]
	Memory at a0000000 (64-bit, prefetchable) [size=256M]
	I/O ports at 4000 [size=64]
	Expansion ROM at 000c0000 [virtual] [disabled] [size=128K]
	Capabilities: <access denied>
    # 当前使用的驱动
	Kernel driver in use: i915
	Kernel modules: i915

i915是内核builtin的驱动，无法通过修改softdep，改变驱动加载顺序。解决此问题，有两种方案：

1. 将i915从内核剥离出来，编译为模块
2. 将vfio-pci编译进内核

如果选择方案2，则使用内核参数：

vfio-pci.ids=8086:9bf6

libvirt提供钩子（Hooks）功能，你可以添加自定义的脚本，存放在/etc/libvirt/hooks目录下，以便在：

1. libvirt守护程序启动、停止、reload时（对应daemon子目录）
2. QEMU客户机启动、停止时（对应qemu子目录）
3. 一个虚拟网络启动、停止时，或者一个网络接口接入、断开网络时（对应network子目录）

执行特定的逻辑。Hooks可以基于Bash或者Python编写。

报错：The virtual machine's operating system has attempted to enable promiscuous mode on adapter 'Ethernet0'.

要解决此问题，需要在宿主机上执行：

# vmnet0改为实际使用的Vmware虚拟网络
sudo chmod a+rw /dev/vmnet0

报错信息：error: unsupported configuration: Domain requires KVM, but it is not available. Check that virtualization is enabled in the host BIOS, and host configuration is setup to load the kvm modules.

解决办法：VM ⇨ Settings，弹出的对话框中，选择Processors，在面板右侧勾选Virtualize Intel VT-X/EPT or AMD-V/RVI

报错信息：error: internal error: cannot load AppArmor profile 'libvirt-cf9a1d56-306d-4a6f-8b0e-79ac070aa8fe'

这个错误与安全模块AppArmor有关，你可以简单的禁用libvirt的QEMU驱动的安全驱动来规避：

# 添加
security_driver = "none"

并执行：

sudo touch /etc/apparmor.d/disable/usr.sbin.libvirtd

然后重启libvirtd：

sudo service libvirt-bin restart

报错信息：
error: internal error: process exited while connecting to monitor: failed to open /dev/net/tun: Operation not permitted
failed to launch bridge helper
qemu-system-x86_64: -netdev bridge,id=tap0,br=br0: Device 'bridge' could not be initialized

解决办法：

# 添加如下几行 

user = "root"
group = "root"
cgroup_device_acl = [
        "/dev/null", "/dev/full", "/dev/zero",
        "/dev/random", "/dev/urandom",
        "/dev/ptmx", "/dev/kvm", "/dev/kqemu",
        "/dev/rtc", "/dev/hpet", "/dev/net/tun"
]
clear_emulator_capabilities = 0

报错信息：error: internal error: process exited while connecting to monitor

解决办法：从Domain配置文件中去掉

<qemu:arg value='-daemonize'/>

症状：无法启动成功，配置SDL则可以启动，但是需要Headless的服务器。

解决办法：配置一个graphics，类型为VNC。

这导致虚拟机无法启动，QEMU的SDL窗口不出现。

报错信息：error: internal error: process exited while connecting to monitor: Could not initialize SDL(No available video device) - exiting

解决办法：

1. 首先在宿主机执行

   env | egrep "DISPLAY|XAUTH"

    ，获取两个环境变量的值
2. 然后修改Domain配置文件，把type=sdl的graphics元素的display和xauth属性修改为上面命令输出的环境变量值：
   

   <graphics type='sdl' display=':0' xauth='/home/alex/.Xauthority'/>

报错信息：

Booting from Hard Disk...
Boot failed: not abootable disk
No bootable device.

报错原因：可能是Domain配置文件搞错了镜像文件的格式。

解决办法：修改为正确的镜像格式，例如：

<driver name='qemu' type='qcow2'/>

报错信息：error: internal error: cannot find character device <null>

解决办法：可能是你的Domain配置中缺少Console和串口的配置，添加：

<serial type='pty'>
    <target port='0'/>
</serial>
<console type='pty'>
    <target type='serial' port='0'/>
</console>

要退出从virsh console进入的控制台，可以按组合键

Ctrl+]

问题现象：光标在Escape character is ^]下面一行闪烁，但是按任何键都没有反应。

问题原因：客户机没有进行适当的配置。

解决办法： 通过其它方式登录到客户机，修改配置。

以Fedora为例：

1. 修改/etc/sysconfig/grub（该文件是指向/etc/default/grub的符号链接）：
   

   # 修改这一行，在命令行尾部添加console=...这个内核参数
   GRUB_CMDLINE_LINUX="... console=ttyS0,115200"

2. 更新GRUB：

   grub2-mkconfig > /boot/grub2/grub.cfg

     
3. 执行命令

   echo ttyS0 >> /etc/securetty

    并重启客户机

现在你可以使用virsh console连接到客户机，并执行Shell命令了。

当通过串口（上面的方式）连接到Linux时，缺乏协商机制（Negotiate About Window Size ，NAWS），Linux也不知道你的（通过串口连接的）控制台屏幕屏幕大小。

在这种情况下，通常会使用

stty -a

你可以在.bashrc中增加

/usr/bin/resize > /dev/null

报错信息：unsupported configuration: deletion of 1 external disk snapshots not supported yet

解决办法：目前libvirt无法删除外部快照的磁盘文件，因此我们仅仅需要删除它的元数据，调用snapshot-delete时添加--metadata参数。磁盘文件可以手工删除。

问题现象：无法ping通网桥，无法ping通外网，Vmware无法桥接到libvirt创建的网桥

原因分析：

在我的机器上，外网是通过Wifi连接的。如果设置虚拟局域网为net-autostart，则虚拟局域网启动时Wifi可能尚未连接，这会导致客户机无法连通外网的情况，原因未知。

将Vmware workstation中的虚拟机也桥接到virbr0时，提示无法连接。出现这种现象的原因也未知，但是先启动一个libvirt管理的客户机“激活”一下VLAN，然后启动Vmware就没事了。

解决办法：在Wifi连接后，启动VLAN、一台libvirt管理的虚拟机，然后再启动Vmware。

设置NFS导出时，要启用no_root_squash选项，让NFS客户端（QEMU宿主机）以root权限访问NFS：

/home/alex/Vmware/libvirt/images/default  10.0.0.0/8(rw,no_root_squash) 

然后，参考本文针对问题《AppArmor导致无法启动QEMU虚拟机》、 《无法启动桥接的QEMU虚拟机》的解决方案。

可能是因为虚拟局域网配置错误：

<network>
  <name>default</name>
  <forward mode="bridge">
    <interface dev="eth0"/> <!-- 必须和宿主机的以太网设备名称一致 -->
  </forward>
</network> 

在Domain配置文件中指定宿主机集群中通用的机器类型，避免此问题：

<os>
    <type arch='x86_64' machine='pc-i440fx-2.0'>hvm</type>
</os>

报错信息：

unable to connect to server at 'Zircon:49152': Connection refused 
unable to connect to server at 'centos.local:49152': No route to host

报错原因：默认情况下，迁移的源使用目的主机的主机名来建立迁移连接，出现此错误说明源无法正确连接到目标主机——Zircon，可以ping验证一下

解决方案：

1. 修改目的主机libvirt的QEMU配置：
   

   # 指向目的主机可被迁移源访问的IP地址或者DNS名称
   migration_host = "zircon.local"

2.  老版本的libvirt可能不支持上述配置，这时可以配置DNS服务器或者迁移源的/etc/hosts文件

3. No route to host错误可能是因为目标主机的防火墙导致，注意检查设置

问题现象：迁移进度到达100%报如上错误。这个报错很笼统，详细的错误信息可以在目的宿主机的客户机运行日志（

/var/log/libvirt/qemu/$VM.log

qemu: warning: error while loading state for instance 0x0 of device 'cpu'
load of migration failed
2016-10-19 01:47:45.913+0000: shutting down

可能是因为卷所在的物理磁盘空间不足。

The post libvirt学习笔记 appeared first on 绿色记忆.