hetzner 桥接使用ipv6导致的mac abuse警告

最近在hetzner的独服上装了pve跑了几个虚拟机,并做好了nat网络端口转发,后面又想着IPV6要用起来,于是在各vm上又添加了网卡,桥接到原有的宿主机网卡上,配置好ipv6地址。

测试网络正常联通,可是不久后便收到hetzner发来的邮件,大致内容为:

We have detected that your server is using different MAC addresses from those allowed by your Robot account.

Please take all necessary measures to avoid this in the future and to solve the issue.

[email protected] wrote: > #1581844 (176.9.127.34) > Allowed MACs: > Unallowed MACs:

> 02:d5:9e:70:29:a8 > 30:85:a0:b5:5a:5f > 4e:5f:48:27:5e:de

原因大概是我在虚拟机中配置了ipv6地址然后通过宿主机桥接到网络出去,上层监控流出流量中MAC地址不是物理机原来的MAC。原来的ipv6地址配置按宿主机配置的:

allow-hotplug eth1
      address 2a02:5f8:152:923c::3/64
      gateway fe80::1

在虚拟机配置中先删除掉桥接ipv6的网卡,随后便收到hetzner发来的ticket解决的邮件。然后找到ipv6 路由模式配置虚拟机ip,也没有再收到network abuse MAC-Errors的邮件了

allow-hotplug eth1
iface eth1 inet6 static
      address 2a02:5f8:152:923c::3/64
      gateway 2a02:5f8:152:923c::2

gateway 2a02:5f8:152:923c::2 为宿主机ipv6地址

最后一步,问题解决后要要给hetzner邮件中发送的statement链接中填写声明信息,大概就是做了什么东西导致的问题,怎么解决的。

PVE反向代理后VNC无法访问的问题

昨天在nginx上给pve做了一下反向代理,在测试完登录成功后便没多在意以为没问题了。今天在登录pve后访问虚拟机console后发现无法连接,后从官方文档找到reverse proxy 文档,发现配置内容中少了两项:

 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection "upgrade"; 

nginx文档中描述,此配置是用于做websocket连接的代理选项。

PVE下安装ESXI测试环境

启用嵌套虚拟化

验证节点CPU是否支持硬件辅助虚拟化

# cat/proc/cpuinfo |grep -E '(vmx|svm)'

有结果输出则CPU支持硬件辅助虚拟化,Intel的VTX(vmx)、AMD的AMD-V(SVM)

启用嵌套虚拟化

如果重载模块后 cat /sys/module/kvm_intel/parameters/nested 输出仍然为N,需要重启节点。

  • Intel编辑修改/etc/modprobe.d/kvm-intel.conf,重载模块
# vim /etc/modprobe.d/kvm-intel.conf 
options kvm ignore_msrs=y options kvm-intel nested=Y ept=Y
# modprobe -r kvm-intel kvm; modprobe kvm kvm-intel
  • AMD同intel一样,只是模块名称不同。
# vim /etc/modprobe.d/kvm-amd.conf 
options kvm ignore_msrs=y options kvm-amd nested=Y ept=Y 
# modprobe -r kvm-amd kvm; modprobe kvm kvm-amd

虚拟机设置

在启用嵌套虚拟化后,虚拟机的CPU类型需要设置为host

# qm set <vmid> --cpu cputype=host

或在web界面中直接修改

安装esxi

创建虚拟机的要求

  1. OS Type :Other
  2. CPU Type:host
  3. Network Type: VMWare vmxnet3
  4. NUMA:禁用 (启用NUMA无法启动到安装界面,failed to resolve circular relocation)
  5. SCSI Controller Type: Default (LSI 53C895A)

esxi创建虚拟机默认情况会无法启动,需要打开虚拟化嵌套

vim /etc/vmware/config  
vmx.allowNested = "TRUE"

pve集群中使用zfs replication做HA

这两天因为QNAP NAS意外断电,造成共享的NFS文件系统出现问题,而PVE原有的共享存储都是位于该NAS共享的NFS上。先是发现集群中vm的性能出奇的差,从vnc console登录进系统的时候都要卡许久,后发现大部分nginx转发的后端都出现502、503等无法访问的问题。在QNAP中检查修复文件系统后,服务才恢复正常。 所以想着还是找多两块硬盘,在两节点上各加一块,做ZFS Pool,在集群中使用zfs replicaion 做HA。

创建ZFS pool

要使用replication功能,必须使用ZFS文件系统。在每个节点中创建相同名称的zfs池。需要注意的是,在WEB UI中无法在不同节点中创建相同名称的ZFS存储,所以需要登录到每个节点中创建zfs pool,这里使用的是单硬盘。

# fdisk /dev/sda    ##如果是未分区的硬盘可以忽略
>> 进到 fdisk中按o清空分区表,按w保存退出
#  zpool create -f pve-cluster-zfs /dev/sda

在节点中创建完zfs pool后,就可以在web ui中添加存储。 在web管理页面中,点击Datacenter–Storage–Add–ZFS,填写ID <ZFS_REP>(后面创件虚拟机使用存储),ZFS pool选择先前创建的 pve-cluster-zfs。

创建测试虚拟机

创建新的虚拟机,HARD DISK Storage存储选中Datacenter中创建的ZFS_REP,大小设置为1G即可。

选中刚创建完的虚拟机,点击Replication–Add,将Schedule设置为”*/1″,每分钟创建同步一次。 一分钟后,应看到该任务被执行,如

2021-07-01 23:05:00 102-0: start replication job 2021-07-01 23:05:00 102-0: guest => VM 102, running => 0 2021-07-01 23:05:00 102-0: volumes => ZFS_REP:vm-102-disk-0 2021-07-01 23:05:01 102-0: create snapshot ‘replicate_102-0_1625151900‘ on ZFS_REP:vm-102-disk-0 2021-07-01 23:05:01 102-0: using secure transmission, rate limit: none 2021-07-01 23:05:01 102-0: full sync ‘ZFS_REP:vm-102-disk-0’ (replicate_102-0_1625151900) 2021-07-01 23:05:02 102-0: full send of pve-cluster-zfs/vm-102-disk-0@replicate_102-0_1625151900 estimated size is 29.1K 2021-07-01 23:05:02 102-0: total estimated size is 29.1K 2021-07-01 23:05:02 102-0: TIME SENT SNAPSHOT pve-cluster-zfs/vm-102-disk-0@replicate_102-0_1625151900 2021-07-01 23:05:03 102-0: successfully imported ‘ZFS_REP:vm-102-disk-0’ 2021-07-01 23:05:03 102-0: end replication job

schedule:这里设置的schedule */1只是为了快速测速看到结果用,实际使用视情况而定,如考虑虚拟机的镜像大小,网络带宽等。

创建HA

Datacenter–HA–Groups–Create,创建TESTREP组,选中HA节点并设置优先级。 Datacenter–HA–Add,选中VM102,group选择TESTREP。

# ha-manage groupadd TESTREP -nodes "node1:1,node2:2"
# ha-manager add vm:102 --state started --group TESTREP --max_relocate 2

只在部分节点上存储池需要做节点访问限制,restriction限制访问节点,storage.cfg配置如下

# vim /etc/pve/stroage.cfg
zfspool: px-zfs-z1
        pool px-zfs-z1
        content images,rootdir
        mountpoint /px-zfs-z1
        nodes pve
        sparse 1

nodes: 指定节点

如果没有做节点访问限制,虚拟机在HA迁移时候会报错:

Failed to sync data - could not activate storage 'Migration of VM between nodes failed - could not activate storage 'px-zfs-z1', zfs error: 

PVE 使用QDevice作为外部投票节点

新版PVE cluster不支持双机HA,因此cluter ha至少要三个节点以上。不过也可以使用外部投票机制,创建一个2+1的集群,外部设备仅作为投票用,不参与虚拟化其他工作。

  • 外部设备上安装 QDevice-Net
$ sudo apt install corosync-qnetd -y 

因为该设备仅作为投票用,因此找一个行能较低,功耗低的开发板足矣。这里使用一个跑在nextcloud 的rock64,尽量把剩余资源利用上。

  • 在所有PVE节点中安装corosync-qdevice
# apt install corosync-qdevice -y 
  • 在PVE集群中加入投票节点
# pvecm qdevice setup 192.168.0.249

需要注意的是,添加投票节点时,确保所有集群节点都处于在线状态,此处192.168.0.249为上面的rock64。

PVE修改虚拟机ID

前段时间在pve上做redis实验的时候创建的虚拟机,发现原有创建时ID与先前认为的规范不一致,所以需要修改为正确的ID。

关闭需要修改ID的虚拟机

使用虚拟机名称过滤停止虚拟机实例

# for vm in `qm list |grep redis |awk '{print $1}'`; do qm unlock  $vm;qm stop $vm; done

重命名虚拟机配置文件

进入到/etc/pve/nodes/pve,KVM虚拟机对应目录为qemu-server,lxc容器为lxc,重命名旧配置文件为新ID名称。这次目的只是为了修改虚拟机ID,所以不用做其他操作。

如果是修改了相应的磁盘信息之类的,则需要修改配置文件中相应的项。

# mv 331.conf 131.conf

因为在这里多台虚拟机都是连续的ID号,所以使用for来重命名

# for i in {1..6};do mv 33$i.conf 13$i.conf; done