[排错] 解决虚拟机使用命令 nmcli connection up enp1s0 时报错 Error: Connection activation failed: No suitable device found for this connection (device eth0 not available because profile is not compatible with device (mismatching interface name)). (给网卡配置的静态 IP 地址无法生效)

报错代码:

# nmcli connection up enp1s0 
Error: Connection activation failed: No suitable device found for this connection (device eth0 not available because profile is not compatible with device (mismatching interface name)).

解决方法:

步骤一:在虚拟机管理器上刷新虚拟机网卡的 MAC 地址或者删除原网卡添加一个新网卡

(步骤略)

步骤二:删除 NetworkManager 上所有的网卡配置

2.1 显示目前 NetworkManager 所有的网卡配置

# nmcli connection show

2.2 删除 NetworkManager 上所有的网卡配置

# nmcli connection delete enp1s0
# nmcli connection delete Wired\ connection\ 1 

(补充:这里以删除网卡配置 enp1s0 和 Wired\ connection\ 1 为例)

2.3 确保目前 NetworkManager 没有网卡配置

# nmcli connection show

(注意:确保这条命令输入后没有输出结果)

步骤三:添加新的 NetworkManager 网卡配置

3.1 显示目前的网卡硬件

# nmcli device show

(注意:这里需要记住网卡硬件的名称,因为下个步骤需要使用)

3.2 添加新的 NetworkManager 网卡配置

# nmcli connection add con-name eth0 ifname eth0 type ethernet

(补充:这里以给 eth0 网卡添加个名为 eth0 的 NetworkManager 网卡配置为例)

(注意:这里的 ifname 后面的名称,必须和上个步骤输出命令后显示的网卡硬件名称一致)

3.3 让刚刚添加的 NetworkManager 网卡配置生效

# nmcli device connect eth0

(补充:这里以启动 eth0 网卡为例)

(注意:这里的 eth0 是在上个步骤中使用 con-name 参数配置的网卡配置名)

步骤四:给 NetworkManager 网卡配置设置 IP 地址

4.1 给 NetworkManager 网卡配置设置 IP 地址

# nmcli connection modify eth0 ipv4.method manual ipv4.addresses 192.168.100.8/24 ipv4.gateway 192.168.100.1 autoconnect yes ipv4.dns 1.1.1.1

(补充:这里以给 eth0 网卡添加静态 IP 地址 192.168.100.8/24,网关 IP 地址 192.168.100.1,DNS 1.1.1.1 并开机自启为例)

(注意:这里的 eth0 是在前面的步骤中使用 con-name 参数配置的网卡配置名)

4.2 让刚刚配置的 IP 地址生效

# nmcli connection up eth0 

(补充:这里以让 eth0 网卡上配置的 IP 地址生效为例)

(注意:这里的 eth0 是在前面的步骤中使用 con-name 参数配置的网卡配置名)

[步骤] KVM 环境变化后模板虚拟机 XML 文件的修改 (从 Rocky Linux 8 的 KVM 更换到 openSUSE 15.6 的 KVM 版)

步骤一:使用新的 KVM 创建 1 台虚拟机

(步骤略)

步骤二:拷贝新创建虚拟的 XML 文件并和模板虚拟机的 XML 文件进行比较

(步骤略)

(补充:KVM 新创建的虚拟机 XML 文件默认放在 /etc/libvirt/qemu/ 目录里)

步骤三:修改模板虚拟机的 XML 文件

3.1 修改 os 参数

将以下内容:

  <os>
    <type arch='x86_64' machine='pc-q35-rhel8.6.0'>hvm</type>
    <boot dev='hd'/>
  </os>

修改为:

  <os>
    <type arch='x86_64' machine='pc-q35-8.2'>hvm</type>
    <boot dev='hd'/>
  </os>

(补充:这里是以将模板虚拟机的运行环境从 Rocky Linux 8 的 KVM 更换到 openSUSE 15.6 的 KVM 为例)

3.2 修改 emulator 参数

将以下内容:

    <emulator>/usr/libexec/qemu-kvm</emulator>

修改为:

    <emulator>/usr/bin/qemu-system-x86_64</emulator>

(补充:这里是以将模板虚拟机的运行环境从 Rocky Linux 8 的 KVM 更换到 openSUSE 15.6 的 KVM 为例)

3.3 修改 graphics 参数

将以下内容:

    <graphics type='vnc' autoport='yes'>
      <listen type='address'/>
      <image compression='off'/>
    </graphics>

修改为:

    <graphics type='spice' autoport='yes'>
      <listen type='address'/>
      <image compression='off'/>
    </graphics>

(补充:这里是以将模板虚拟机的运行环境从 Rocky Linux 8 的 KVM 更换到 openSUSE 15.6 的 KVM 为例)

[排错] 解决 Linux 创建 VM 时报错 ‘blk_cloned_rq_check_limits’

报错代码:

kernel: blk_cloned_rq_check_limits: over max size limit. (65535 > 0)

分析:

SAN 存储设备需要 ’68 Support Page Reclamation for Linux bit’ 功能开启后才能实现精简配置

解决方法:

在 SAN 存储设备上开启 ’68 Support Page Reclamation for Linux bit’ 功能后执行以下命令:

$ for i in /sys/block/sd*; do echo 1 > $i/device/rescan; done
$ multipath -r
$ multipath -ll

参考文献:

https://access.redhat.com/solutions/5619941

[排错] Linux 解决日志里报错 “kernel: [829455.595333][ C10] critical target error, dev sda, sector 104056241 op 0x3:(DISCARD) ……”

报错代码:

kernel: [829455.595333][ C10] critical target error, dev sda, sector 104056241 op 0x3:(DISCARD) ......

分析:

如果是在 VMware 上运行的虚拟机在日志里出现 critical target error 此类报错,尤其是涉及到 DISCARD 操作的错误,通常是由 VMware 进行硬盘垃圾空间回收或者进行硬盘优化造成的。

解决方法:

VMware 的控制平台上,检查宿主机的硬盘是否正常。若不正常则修复或者更换硬盘。

Several situations of Linux automatically reboot without reboot logs in the /var/log/messages

Situation One

This Linux server is a virtual server. If we reboot it though its virtual software, there is no relevant logs in the /var/log/messages.

Situation Two

This Linux server is a member of a pacemaker cluster. If the pacemaker cluster software fences this server for protecting the whole cluster, there is no relate logs in the /var/log/messages.

Situation Three

This Linux server has critical problems in its system or hardware. Core panic of Linux and hardware problem both can reboot the system automatically without any reboot logs in the /var/log/messages.