前面我们对HCL的发版情况做了简单介绍（网络之路11：认识网络设备模拟器HCL），在2021年之前，HCL已经很久没有更新了，2018年2月份发布的V2.1.1，2021年1月份发布的V2.1.2，2021年8月份发布的V3.0.1；从2022年6月份发布V5.0.0之后，更新速度开始狂飙起来了，到2023年10月份，一共发了13个V5小版本，平均发版间隔41天，快赶上月更了；其中，最短的发版间隔只有半个月。
在上个版本中（HCL中竟然新增了Openwrt服务器，你知道怎么用吗？），我们还特地测试了新增的Openwrt设备，整体功能还可以。
后来新版本出来，我看只是支持了配置H3C的NFV设备，考虑到性能问题，我就没有第一时间进行测试，今天来补测一下其中的问题。
默认情况下，HCL是无法创建NFV设备的。首先，我们打开设置面板，进入“镜像”选项卡，点击VSR1000后面的“导入镜像”按钮。
通过查看右下角的镜像格式，我们知道一共支持vmdk、vdi和ova三种格式，这3种格式都是VirtualBox支持的格式。
我们查看一下从官网下载的VSR1000压缩包，里面有对应的ova文件，我们先用这个文件试一下。
额，没想到啊，导入之后创建VSR1000直接报错了。
我第一次导入的现象是虚拟机启动之后一直无法引导进入系统，既然都是报错，那我们继续介绍吧。
接下来，我们需要先在VirtualBox用刚才的ova文件创建一台虚拟机，在VirtualBox管理器中，点击“管理”下面的“导入虚拟电脑”。
点击右侧的导入文件按钮选择到刚才的ova文件，然后点击“下一步”。
默认情况下，这里的配置是不需要调整的，不过我们可以按需进行调整，比如设置虚拟机名称、操作系统类型和实例规格等等；其它选项中的“导入虚拟硬盘为VDI”是默认勾选的，注意检查；最后点击“导入即可”。
导入完成之后，我们就可疑在虚拟机的磁盘存储路径下找到vdi镜像文件了，然后我们将HCL中VSR1000的镜像文件替换为这个vdi文件。
替换完成之后，再次创建VSR1000，就可以创建成功了。
然后我们启动命令行终端，登录设备看一下。
这个时候，我们遇到了一个老问题（如何在EVE-NG中导入VSR1000设备？怎么解决登录问题？）。我们使用MobaXterm登陆的时候无法进入命令行，而在VirtualBox的后台则可以直接登录，提示已经很明显了，MobaXterm连接时显示的是“Line con0 is available”，说明连接的是设备的aux0用户线；而VirtualBox连接时显示的则是“Line aux0 is available”，说明连接的是设备的con0用户线。
上次我们的解决方案有两种，一是切换EVE-NG的Console模式为VNC，另一种是通过con0登陆之后修改aux0的认证方式。显然使用MobaXterm是没办法使用VNC了，那我们直接上第二种方案，先来看一下用户线的相关配置信息。
乍一看好像没什么问题，但是我们查看状态看一下。
可以看到，console用户线的缺省认证方式为N（none，无需认证），所以可以直接登录。
而AUX用户线的缺省认证方式为P（password，密码认证），所以无法直接登录。此时只需要修改AUX用户线的认证方式为none，再将权限配置为network-admin即可。
修改时，我们需要先在VirtualBox的虚拟机进行操作，然后保存配置即可。
再次通过MobaXterm进行登录，看一下登录信息。
登陆成功，并且权限为network-admin。
换个思路，如果使用HCL默认的Putty登录是否可以呢？我们在设置里面，将命令行终端模类型修改回Putty。
然后再次打开命令行终端，可以看到用户线仍然是AUX0，看来要用NFV的话，修改AUX0的配置是不可避免了。
在使用过程中，可以比较明显地感觉到命令行有些卡顿，查看设备资源利用率稍微偏高，在未运行任何任务的情况下，CPU利用率始终保持在20&以上，运行命令时更是逼近90%，内存利用率稍微低一些。
通过在VirtualBox进行查看，设备的配置为2核CPU、2 GB内存，配置不算低，跟我配置NFV的配置差不多，应该是HCL调用的问题，直接在VirtualBox进行操作，卡顿没有这么明显。
如果查看任务详情，可以看到CPU占用率比较高的几个进程是rcu_sched（16.6%）、diagd（16.6%）、mtpd（16.6%），其中RCU指Read-Copy Update，即非对称读/写同步机制，而我们看到的AUX0就是使用的async mode（异步模式），所以相比于CON会占用更多的系统资源，导致系统卡顿，应该是这个原因，欢迎拍砖！
