重要性阅读引导:

1、本文前部分为背景和原理介绍,如需尽快解决问题请跳转到后半部分
2、解决方案从第三个大标题开始
3、未经授权,不允许复制此篇文章到其他平台,在其他平台做成教程时,必须链接本篇文章源地址
4、如果你有更好的方案,你可以在网站上留言,一个生态的良好环境由所有使用者共同塑造。

一、问题的诞生

在基于Apple Silicon的Mac上,为了更高的安全性,Apple已经弃用了UEFI的启动方式,这意味着使用EFI引导的Windows系统无法在Apple Silicon平台上正确运行。

图片中是基于Apple Silicon的Mac和基于Intel 的Mac启动方式的差异。

图1 来自Apple官网的基于Apple Silicon的Mac启动过程
图2 基于Intel的Mac启动过程(依赖T2 芯片)来自Apple官网

所以,我们不能够使用EFI引导Windows For Arm64来从物理机启动,在Apple自己发布启动驱动程序或有其它开发者破解引导程序之前,我们只能在虚拟机中引导Windows。

还好,Apple开放了Apple Silicon的虚拟化支持,但是很不幸,这种虚拟化驱动不能支持虚拟化嵌套。

在中国,华为(HUAWEI TECHNOLOGIES CO., LTD.)是一家市场份额巨大的网络设备厂商,互联网相关专业的学生有很大一部分学习华为的技术,其中不乏我这样的Apple爱好者同时又需要学习华为的设备。

ENSP是华为一款重要的网络设备模拟器软件,它和Cisco Packet Tracer是同一种类型的软件,但是它仅对Windows平台提供支持。

从远程服务器安装ENSP并在远程桌面上执行它是我曾经使用的方式,它快速,功能完整可以说没有什么很明显的弊端,但是,学习的过程中并不是一直有网络,远程桌面的方式十分依赖网络连接。而笔记本就是要解决本地运算的问题,所以我开始研究在我的基于M1芯片的Macbook Pro上运行ENSP。

二、初步解决方案(失败)

首先是在目前商业化最成功的M1虚拟机Parallels Desktop上进行实验。

安装Windows十分顺利,因为我购买了正版授权,所以软件运行中基本没有什么故障存在,一切很顺利地来到了Windows桌面。

图3 运行过Windows11一段时间后的PD虚拟机

在Windows 11 For Arm64版本上,Windows运行的出乎意料的快,在基本操作时,与我的搭载Intel Core i5-11400的PC运行速度并无二异。

我装了几个X86软件,在有效的64Bit转译下,X86应用的运行速度也能达到正常可用水平。

于是我开始安装ENSP

ENSP内的网络设备基于Oracle VirtualBox ,在我刚刚开始安装VirtualBox就出现了问题,它提示我无法继续安装,因为遇到无法解决的问题。

图4 无法在Windows11 For Arm上安装Vbox的报错
图5 无法安装Vbox的中文翻译

经过我多方查询,最终确认

因为PD虚拟机不支持嵌套虚拟化,导致VBox无法虚拟化网络设备,最终导致无法安装。

并且似乎Apple本身并不支持嵌套虚拟化,所以PD运行ENSP的方法似乎暂时行不通了(截止到2022年1月)

后来我又尝试了还在内测当中的Vmware Fusion,也是同样的情况。

三、最终解决方案

此时我注意到了之前在iPad上运行Windows的虚拟化软件UTM。

图6 UTM软件界面

UTM是一个可以在Arm计算机上通过QEMU模拟X86环境的软件,因为是开源产品,所以可以调节的项目也非常多。

我在UTM中安装了X86版本的Windows7系统,分配了较大的可用资源,以保证模拟软件正常运行,打好所有驱动后,我又开始了安装ENSP的过程。

图7 给Windows7分配的硬件资源

在实际体验中,x86版本的系统通过模拟化运行还是很卡顿的,整套操作的流畅度基本和2代i5的性能差不多,并且不能完美驱动显卡,导致Aero和硬件加速不能启用,不过这都不是关键,关键是ENSP能否正确运行。

这次安装Vbox过程中和在PC上一样顺利,一路下一步便来到了安装成功页面,我又开始安装依赖插件WireShark和Npcap。

图8 在UTM虚拟机中成功安装并运行ENSP

一切似乎都很顺利,我打开ENSP,启动了一台交换机,经过整整三行半的启动符号之后,终于出现“<huawei>”的待命状态。

从图中不难看出,启动过程中,CPU消耗资源上升明显,未启动完成时UTM进程能耗达到了惊人的146.7%(未截图),启动完成后也维持在50%上下。

图9 交换机刚刚启动时的运行状况和资源占用情况

并且设备接口先从Down状态启动再更新到Up状态。

图10 交换机从Down切换到Up状态

嗯,其实还不错,虽然速度略慢,但是还是能成功运行的,正在我想为自己的成功而欢呼的时候,意外发生了。

我随手拖进了一台路由器(AR2220),发现无论启动多久都是启动符号(#),这很明显,Vbox没有成功运行AR虚拟机。

图11 启动路由器后不停出现“#”但是程序不予响应

我四处排查问题,直到我发现在UTM的CPU模拟设置中有这样的字样:Hypervisor。

图12 UTM中虚拟机监视工具复选框,您可能需要显示所有Flags自己寻找

我看到这个就知道这是一个检测虚拟机的软件,因为折腾过ESXI直通,我下意识的认为打开它就能成功运行,于是我勾选这个选项,并重新开启虚拟机,重新注册设备,找到AR,开启。

图13 重新注册设备

奇迹发生了,AR在跑数行后就成功运行,虽然相比PC平台,这个速度慢了很多,但是胜在能够使用Mac模拟网络拓扑了。

图14 路由器刚刚启动时的能耗
图15 AR2220和交换机已完全启动后的CPU占用

至此,我们可以在Mac上以较低速度模拟运行ENSP了。

这仍然不是一个很棒的方式,因为效率低下,我也正在寻找一个效率更高的方式,如果你有一些建议,请留言。

罗辑赞歌

2022年1-5月为你研究

作者:韩俊钊

One response

发表评论

您的电子邮箱地址不会被公开。