在上一篇Blog：/proc/cpuinfo里的CPU型号怎么来的？里，可以知道Linux系统是根据CPUID指令来显示具体的CPU型号的。所以很自然的一个想法：是不是可以自定义显示的内容呢？
答案显而易见，必然是可以的。但是如果要改物理CPU的寄存器，那确实会有些困难，不过没关系，我们还有虚拟机嘛，理论上虚拟机可以虚拟这些东西，那改动起来应该也是比较方便的。
想要修改这些寄存器，首先得先看看CPUID指令在Qemu里是怎么处理的：
今天有一件小事，勾起了我的好奇心。有个同事反馈说，我们虚拟的CPU主频较低，对性能有影响，于是就问了一下，怎么看主频的，很简单，看看lscpu里的Model name:字段就行了：
[root@]# lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
...
Vendor ID: GenuineIntel
CPU family: 6
Model: 85
Model name: Intel(R) Xeon(R) Gold 6240R CPU @ 2.40GHz
Stepping: 7
CPU MHz: 2394.374
BogoMIPS: 4788.74
Hypervisor vendor: KVM
Virtualization type: full
...可以看到这台机器的Model name:是Intel(R) Xeon(R) Gold 6240R CPU @ 2.40GHz，@符号后面就是2.40GHz，也就是这颗CPU的基础频率，其实之前写过一个文章再谈CPU的电源管理（如何做到稳定全核睿频？），我们线上实际也是跑在睿频频率上的。实际这个@后面的频率并不能反映证实频率。
那么问题来了。这个Model name到底从哪读的？
当一台机器有超过1块网卡，并且配置的IP地址不在一个段里的时候，会出现在外部只有一个IP地址能够ping通的情况，举个最简单的例子：
一个有2块网卡的机器：
[root@test]# ip addr
2: enp24s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 11:11:11:11:11:11 brd ff:ff:ff:ff:ff:ff
inet 192.168.100.10/24 brd 192.168.100.255 scope global enp24s0f1
valid_lft forever preferred_lft forever
3: enp24s0f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 22:22:22:22:22:22 brd ff:ff:ff:ff:ff:ff
inet 192.168.200.10/24 brd 192.168.200.255 scope global enp24s0f1
valid_lft forever preferred_lft forever可以看到两块网卡，分别配置了192.168.100.10和192.168.200.10这两个IP，再看看机器的默认路由：
针对网卡名字这个问题，其实之前也讨论过一次，主要是如何利用udev去重命名网卡，里面提到了新的一致性命名规则，但是没有细说。
当然肯定是遇到问题了，所以针对网卡命名的细节，需要再探讨一下。
其实目前大家还是更熟悉老的那种eth0,eth1…那种命名，目前我们大部分生产环境里也是这么用的。但是随着网卡数量越来越多（在我们使用的SR-IOV场景，加上VF虚拟网卡，机器上已经有超过16个网卡）这种命名规则已经不适应现代的硬件和操作系统了，所以最近我们也从老的命名方式，切换到操作系统默认的一致网络设备命名。
不过因此也带来了一些问题，发现不同厂商，或者不同机器会有命名不一致的情况，举个例子：
这是某台机器的网卡名字：
事情的起因呢，是我们收到了一条内存报警，提示某台机器的可用内存不足，可用内存剩下不到14G。原本只是一个很简单的问题，但是呢，这次却发现了一些不一样的点。
登录机器后，free -m命令执行的结果如下：
]# free -m
total used free shared buff/cache available
Mem: 385445 363181 1917 4 20346 21147
Swap: 0 0 0问题来了，报警里的14G内存，是从哪来的？好像没有一个数字和这个14G接近？
最近在我们的集群中遇到一个问题，在一台机器上，尝试挂载CephFS失败了，报错如下：
~]# mount -t ceph mon1.ichenfu.com:6789,mon2.ichenfu.com:6789,mon3.ichenfu.com:6789:/ /tmp/data
mount: wrong fs type, bad option, bad superblock on mon1.ichenfu.com:6789,mon2.ichenfu.com:6789,mon3.ichenfu.com:6789:/,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so.因为之前遇到挂载CephFS时出现failed: No such process的问题，这两个问题看起来有点相似，但是确实有些不一样。因为有前车之鉴，所以顺着之前的思路，首先根据报错的提示，看看dmesg里有没有什么有用的信息：
在虚拟化场景下，SR-IOV（Single Root I/O Virtualization）是一个很常用的功能，通过SR-IOV，一个物理的设备（Physical Function），可以派生出很多虚拟设备（Virtual Function），这些虚拟设备具有简单的PCIe功能。以网卡为例，通过SR-IOV，我们可以将一块网卡，虚拟化成很多块网卡，这些虚拟出来的网卡，有自己独立的PCIe地址，中断，配置空间等，这些虚拟出来的网卡，可以作为单独的PCIe设备被attach到虚拟机中，实现网络功能，当然，场景并不局限于VM。
这里先不关注SR-IOV的应用场景，或者其实现原理，而是关心一个简单的问题：如何设置SR-IOV，并且能稳定的实现开机启动时就设置好呢？
之前的Blog：再谈CPU的电源管理（如何做到稳定全核睿频？）最终通过了tuned实现了CPU全核心运行在允许的全核睿频频率上。但是这个只是场景之一，并不是所有场景下都会用到很多的核心，从这些应用角度讲，更需要少量但是更高频率的核心，一个比较简单的例子就是DPDK，作为DPDK应用，一般来说也不会用到很多核心，但是他的polling模型，是希望单核频率越高越好的。针对类似的这种场景，实现少量核心，比如说单核的高频，比多核全开，频率变低更合适。
那么问题来了，怎么在Linux上实现稳定的单核睿频呢？这里给一个稍微暴力点的办法。
在之前的一篇Blog： 服务器的能耗控制以及高性能模式配置（Dell）中，说到在Dell的服务器BIOS中打开Performance模式。就可以实现真正非软件管理的高性能模式，让CPU时刻处在最高性能状态上。但是呢，最近的一批机器，升级到CentOS 7.7系统之后，这个行为发生了一些变化，而针对这批机器的两个供应商的表现呢，也不完全一致，这个现象驱使我研究了一下到底怎么样设置，可以实现期望的运行状态。也就是说，希望CPU稳定的运行在全核睿频上，既不需要他提升单核频率到单核睿频，也不希望他降频，这样，至少在我们当前的业务场景下，能获得比较稳定的性能预期。
在老的Linux中，特别是CentOS 6系统下，网卡大多数都是命名为eth0，eth1这样的形式，但是这样的命名是不稳定的，因为后面的数字是根据驱动的加载顺序来的，那么就有可能出现两次启动导致网卡名称不一样的情况了。
在CentOS 7中，由于有了Systemd，所以引入了一种新的命名规则叫一致网络设备命名，具体的可以参考文档第 8 章 一致网络设备命名，这里就不再赘述了。
现在问题来了，如何真正意义上实现按意愿去设置网卡的名称呢？这里有个通用的方法：
编辑/etc/udev/rules.d/70-persistent-net.rules文件，如果有这个文件，则直接编辑就可以，如果没有就新建一个。
然后在文件中按以下的格式输入规则：
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="aa:bb:cc:dd:ee:01", NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:11:22:33:44:02", NAME="ethxyz"需要注意的是，MAC地址中的字母，必须是小写，否则可能会无法正确匹配。
只需要根据情况，填写MAC地址和名字就可以了。另外，针对已有的网络配置，如CentOS下/etc/sysconfig/network-scripts/底下的那些ifcfg-xxxx配置文件，也需要针对性的进行修改。修改完成后重启机器即可生效。
针对udev规则，还有很多可以MATCH和修改的地方，可以实现很多复杂功能，具体的这里就不赘述了，感兴趣的可以参考一下udev - ArchWiki，或者其他udev相关的文章。