1 - 配置NFS
标准配置
在 pve 控制页面上打开 Datacenter, 进入 Storge, 在 “Add” 下拉框中选择 “NFS”:
这个方案在正常 pve 集群下没有问题，但是我这里因为机器都是按需启动，不会7x24小时在线，因此 pve 集群的最小法定人数经常无法达到，导致集群不可用。
如果用上面的方案，那么不同机器都会新建 nfs 存储，会导致都指向同一个 nfs 远程目录，这样应该会造成混乱。
个人实践（受限不能使用集群功能）
ID分段使用 nfs 存储
一番尝试之后发现，标准的 nfs 存储只要处理好 ID 分段，不同的 pve 节点使用不同的 ID 范围，就可以正常使用的（前提：有多台 pve 机器又不愿意建立集群）。
建立 nfs 存储的方式和标准方式一样，只是 Content 只选了三个： Disk image, ISO image 和 VZDump backup file。
ID 分段规则：
- local： 从 100 到 999
- nfs-fast： skyserver1-6六台机器，分段分别为 1000-1099 / 2000-2099 / 3000-3099 / 4000-4099 / 5000-5099 / 6000-6099
- template： 10000 开始
nfs 文件存储位置
服务器端
在 export 文件中，服务器端 export 的目录是 /mnt/data/pve-share
ls
dump images template
template/iso目录： 存放上传的 iso 文件dump目录： 存放虚拟机和模板的备份文件，可以用于恢复。
客户端
在 pve 页面上用 nfs-fast 为 ID 建立的 nfs 存储，在本地磁盘上挂载的路径为 /mnt/pve/nfs-fast
共享模板
由于模板是只读的，因此适合跨pve节点共享，但是按照 pve 标准的恢复方式，从 dump 文件恢复后存放在 nfs 存储中的模板虚拟机，只保存在执行恢复操作的这一台 pve 机器上，其他 pve 机器只能在 “VM Disk” 看到这些模板的镜像文件，但是在虚拟机列表中无法列出。
ssh 登录操作模板恢复的 pve 节点，可以看到恢复的虚拟机模板：
cd /etc/pve/qemu-server
ls
10000.conf 10001.conf
这里遵守前面定制的规则：虚拟机模板的 id 从 10000 开始，确保不会和本地存储上的虚拟机ID重叠。
先把配置文件下载到本地作为备份：
cd /media/d/backup/pve/qemu-server
scp root@192.168.99.38:/etc/pve/qemu-server/10000.conf /media/d/backup/pve/qemu-server/
scp root@192.168.99.38:/etc/pve/qemu-server/10001.conf /media/d/backup/pve/qemu-server/
然后将这些模板的配置文件复制到其他 pve 节点：
# skyserver
scp /media/d/backup/pve/qemu-server/10000.conf root@192.168.99.18:/etc/pve/qemu-server
scp /media/d/backup/pve/qemu-server/10001.conf root@192.168.99.18:/etc/pve/qemu-server
# skyserver2
scp /media/d/backup/pve/qemu-server/10000.conf root@192.168.99.28:/etc/pve/qemu-server
scp /media/d/backup/pve/qemu-server/10001.conf root@192.168.99.28:/etc/pve/qemu-server
# skyserver4
scp /media/d/backup/pve/qemu-server/10000.conf root@192.168.99.48:/etc/pve/qemu-server
scp /media/d/backup/pve/qemu-server/10001.conf root@192.168.99.48:/etc/pve/qemu-server
# skyserver5
scp /media/d/backup/pve/qemu-server/10000.conf root@192.168.99.58:/etc/pve/qemu-server
scp /media/d/backup/pve/qemu-server/10001.conf root@192.168.99.58:/etc/pve/qemu-server
比较麻烦一点的是以后模板文件有变化（增加/修改/删除）时，需要用这个方式手工同步各个 pve 节点机器（毕竟没有集群管理）。
好在模板一般数量有限，更新频率也不会太高，先这么对付着用，不行就写个脚本简化一下操作。
模板和虚拟机恢复的最佳实践
实际操作中，有一些发现：
-
从 dump 出来的备份文件恢复模板，速度是非常快的
不管是恢复到 nfs 存储还是某台 pve 节点的 local 本地存储，大概一分钟这个级别
-
从模板文件 clone 到虚拟机，速度非常慢
恢复 pve 节点的 local 本地存储，大概三五分钟这个级别。
-
clone 时如果选择 “Linked clone”，速度非常快。
10秒级别， 毕竟这种情况下无需复制整个模板的文件（10-20G级别）
因此，总结出来的最佳实现应该是这样：
- 坚持以模板为基础来实现虚拟机的备份和版本控制：模板是只读的，对内容的一致性有保障
- 以pve备份的方式对模板进行备份，得到 dump 文件，用于离线冷备份和不同机器之间分发
- dump 文件倒入到 nfs 存储中，全局一份
- 模板默认恢复一份到 nfs 存储中，同样全局只有一份：使用时直接在 nfs 上 “Linked clone”，用完即删
- 对于使用频率非常高的模板，直接恢复到 pve 节点的 local 本地存储：后续根据使用时间长短区分，长期使用的希望隔离性好的，用 “Full clone”。短期使用用完就删的用 “linked clone”
2 - [废弃]通过NFS复制
背景
scp 命令的速度，只能达到 300-400MB,无法发挥出网络和硬盘的速度。
nfs 会快一些，实际测试可以达到 2000 - 3000 MB （主要瓶颈在ssd写入速度）。
准备工作
准备 nfs 服务器端
在 skydev 机器上开通 nfs，然后将 4t 的 pcie 4.0 ssd 以 nfs 的方式共享出来
nfs 地址为： 192.168.99.100 ， export 地址为 /mnt/data/share。
准备 nfs 客户端
pve 节点上安装 nfs 客户端。
mount nfs 到 pve 节点
在pve 节点上执行命令：
mkdir -p /mnt/nfs-fast
# on skywork
sudo mount 192.168.100.1:/mnt/data/share /mnt/nfs-fast
# on skyserver
mount 192.168.99.100:/mnt/data/share /mnt/nfs-fast
为了方便，
vi ~/.zshrc
增加一个 alias :
# on skywork
alias mount-nfs-fast='sudo mount 192.168.100.1:/mnt/data/share /mnt/nfs-fast'
# on skyserver
alias mount-nfs-fast='mount 192.168.99.100:/mnt/data/share /mnt/nfs-fast'
复制虚拟机和模板
复制虚拟机或者模板文件到 pve 的 dump 目录:
cd /mnt/nfs-fast/pve-share/templates/ubuntu20.04
cp *.vma *.vma.notes /var/lib/vz/dump
同样为了方便，
vi ~/.zshrc
增加一个 alias :
alias copy-pve-dump='cp *.vma *.vma.notes /var/lib/vz/dump/'
恢复虚拟机或者模板
在 pve 管理页面操作，打开 local，“Backups” 。
总结
这个方案中，nfs 只是作为一种快速的远程源文件复制方式，从 nfs 服务器端将虚拟机或者模板文件复制到 pve 本地存储，然后通过标准的 pve 虚拟机恢复方式来恢复虚拟机或者模板。之后虚拟机或者模板就存放在 pve 本地存储上了，再进行各种 clone 操作也就方便了。
缺点就是完全绕开了 pve, 需要 ssh + 命令手工执行。
3 - [废弃]通过 NFS 进行 dump 和恢复
背景
前面纯 nfs 的方案还是手工操作太多。
考虑采用 pve 的 nfs storage，但是只存放 dump 出来的虚拟机或者模板文件，不涉及到 vm id，不会造成冲突。
准备工作
准备 nfs 服务器端
在 skydev 机器上开通 nfs，额外增加一个 export 地址，为 /mnt/data/pve-dump。
新建 nfs 存储
打开 pve 管理页面，在 “datacenter” -》 “storage” 下，“Add” 一个名为 “nfs-fast-dump” 的 NFS 存储， export 选择 /mnt/data/pve-dump。“content” 只选择 “VZDump backup file”。
此时 pve 会自动在 /mnt/data/pve-dump 目录下新建一个名为 “dump” 的子目录，将之前备份的 vma 等文件，复制到 /mnt/data/pve-dump/dump/ 目录。
刷新 “nfs-fast-dump” 存储的 “Backups” 就可以看到之前备份的 dump 文件，然后就可以用 pve 标准的恢复功能将他们恢复为虚拟机或者模板。
实践了一下, 8G 的模板恢复时间为 66 秒：
restore vma archive: vma extract -v -r /var/tmp/vzdumptmp101735.fifo /mnt/pve/nfs-fast-dump/dump/vzdump-qemu-107-2023_07_26-02_23_55.vma /var/tmp/vzdumptmp101735
CFG: size: 667 name: qemu-server.conf
DEV: dev_id=1 size: 540672 devname: drive-efidisk0
DEV: dev_id=2 size: 549755813888 devname: drive-scsi0
CTIME: Wed Jul 26 02:23:55 2023
Formatting '/var/lib/vz/images/101/vm-101-disk-0.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off preallocation=metadata compression_type=zlib size=540672 lazy_refcounts=off refcount_bits=16
new volume ID is 'local:101/vm-101-disk-0.qcow2'
Formatting '/var/lib/vz/images/101/vm-101-disk-1.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off preallocation=metadata compression_type=zlib size=549755813888 lazy_refcounts=off refcount_bits=16
new volume ID is 'local:101/vm-101-disk-1.qcow2'
map 'drive-efidisk0' to '/var/lib/vz/images/101/vm-101-disk-0.qcow2' (write zeros = 0)
map 'drive-scsi0' to '/var/lib/vz/images/101/vm-101-disk-1.qcow2' (write zeros = 0)
progress 1% (read 5497618432 bytes, duration 1 sec)
progress 2% (read 10995171328 bytes, duration 3 sec)
progress 3% (read 16492724224 bytes, duration 6 sec)
progress 4% (read 21990277120 bytes, duration 7 sec)
......
progress 99% (read 544258785280 bytes, duration 66 sec)
progress 100% (read 549756338176 bytes, duration 66 sec)
total bytes read 549756403712, sparse bytes 541771325440 (98.5%)
space reduction due to 4K zero blocks 5.08%
rescan volumes...
Convert to template.
TASK OK
20G 的模板恢复时间为 115 秒：
restore vma archive: vma extract -v -r /var/tmp/vzdumptmp103025.fifo /mnt/pve/nfs-fast-dump/dump/vzdump-qemu-102-2023_07_26-01_23_50.vma /var/tmp/vzdumptmp103025
CFG: size: 637 name: qemu-server.conf
DEV: dev_id=1 size: 540672 devname: drive-efidisk0
DEV: dev_id=2 size: 549755813888 devname: drive-scsi0
CTIME: Wed Jul 26 01:23:50 2023
Formatting '/var/lib/vz/images/102/vm-102-disk-0.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off preallocation=metadata compression_type=zlib size=540672 lazy_refcounts=off refcount_bits=16
new volume ID is 'local:102/vm-102-disk-0.qcow2'
Formatting '/var/lib/vz/images/102/vm-102-disk-1.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off preallocation=metadata compression_type=zlib size=549755813888 lazy_refcounts=off refcount_bits=16
new volume ID is 'local:102/vm-102-disk-1.qcow2'
map 'drive-efidisk0' to '/var/lib/vz/images/102/vm-102-disk-0.qcow2' (write zeros = 0)
map 'drive-scsi0' to '/var/lib/vz/images/102/vm-102-disk-1.qcow2' (write zeros = 0)
progress 1% (read 5497618432 bytes, duration 5 sec)
progress 2% (read 10995171328 bytes, duration 6 sec)
......
progress 98% (read 538761232384 bytes, duration 108 sec)
progress 99% (read 544258785280 bytes, duration 109 sec)
progress 100% (read 549756338176 bytes, duration 115 sec)
total bytes read 549756403712, sparse bytes 529814392832 (96.4%)
space reduction due to 4K zero blocks 2.65%
rescan volumes...
Convert to template.
TASK OK
速度只能说还凑合，模板恢复的速度太慢了。
总结
这个方案中，使用到了 pve nfs 存储的功能，但是为了避免在多个 pve 机器（不是一个 cluster） 之间出现冲突，因此只在这个 nfs 存储中存放不涉及到集群的内容。
思路扩展
按照上面的思路，只要 nfs 存储上放的内容不涉及到集群，即不会造成集群范围内的冲突，就不影响使用。
扩展存储类型以包含 ISO 文件
因此，nfs 存储存放的类型可以不限于单纯的 “VZDump backup file”， 可以增加 iso image, 毕竟 iso 文件是没有任何集群属性的，而且也没有必要每台 pve 机器都存放一份。
手工分配 id 以避免冲突
继续扩展上面的思路，对于可能会造成集群冲突的内容，如果能通过某种方式避免冲突，那么也是可以存放在 nfs 上的（备注：多台 pve 机器但是不建立集群) ，比虚拟机和模板。
关键： 在虚拟机和模板的建立过程（包括新建，clone, 恢复等）中， id 是容许手工指定的。
因此，只要制订并遵守某个 id 分配的规则，让不同 pve 节点上的 nfs 存储以不同的 id 段分配 id, 就可以确保任意一台 pve 节点上的 id 都不会和其他 pve 节点重复。
按照这个思路，修改 nfs 存储可以存放的类型，增加 “Disk image” 用来存放虚拟机和模板的镜像文件。
比如 skysever4 这台机器的 id 就以 14000 开头，从 14001 到 14999，绝对够用。skysever5 就用 15001 到 15999……