「记录」使用PCI设备直通技术在vSphere中部署基于Ubuntu Server 1804的GPU服务器

大约在两年前我撰写了一篇文章记录我为实验室部署GPU云的核心过程。现在给学院部署GPU云,本以为可以照着原来的文章很顺利就可以装完,结果却搞得心态爆炸,一度怀疑人生,所以很有必要再写一篇记录一下。

环境:

实体机:曙光 天阔 W780-G20
操作系统: VMware ESXi, 6.7.0, 14320388
管理平台: VMware vCenter Server Appliance, 6.7.0, 15129973
GPU:NVIDIA GP100GL [Tesla P100 PCIe 16GB] ×8

先简单说一下部署环境和上次的区别:第一是平台不再是商业大厂DELL EMC,很多文档资料缺失;第二是底层esxi和管理平台vcenter都升级到了6.7;第三是虚拟机准备安装Ubuntu Server 1804,之前的16在21年来看有点过老。最关键的是第四点:显卡质量和数量都上了一个巨大台阶,原来单台机器最多3卡(一个泰坦X,两个泰坦XP),遇到的显存最大的卡应该就是p40。当时在安装p40的时候就遇到奇怪的问题,为此还写了一篇记录文章。这次遇到的核心问题和p40那次应该是同一个,都是高级显卡显存过大,需要一些特定的底层配置参数,vmware专门有博客文章(下简称博文)进行了介绍,但是我一开始寻找解决方案的方向有很大偏差,绕了一大圈才找到。

让我一度怀疑人生的核心问题

0. 准备工作

0.1. 主机BIOS设置

根据博文内容,需要在运行虚拟GPU服务器的esxi主机的BIOS设置中查找并开启类似这样的选项:“above 4G decoding”、“memory mapped I/O above 4GB”、“PCI 64-bit resource handing above 4G”

启用BISO中的相关设定

0.2. 配置PCI设备直通

在esxi主机中配置好显卡的设备直通

0.3. 上传系统安装镜像

将ubuntu server 1804安装镜像上传到主机数据存储

1. 创建虚拟机

⚠️注意:必须在vsphere client中创建虚拟机,不可以在本地workstation创建虚拟机安装后再上传

首先按照常规方法创建虚拟机,创建后不要启动!按以下步骤进行预先配置。

1.1. 设置虚拟机引导方式为EFI

为虚拟机的“引导选项”中启用EFI

在虚拟机页面,“操作”→“编辑设置”→“虚拟机选项”→“引导选项”→“固件”,选择“EFI”。

1.2. 设置虚拟机高级配置参数

虚拟机选项中的高级选项卡

在刚才1.1的“引导选项”下方找到“高级”,点击“配置参数”右侧的“编辑配置”,进入高级参数配置窗口。

高级参数配置窗口

在窗口中点击“添加配置参数”,然后添加2条

⚠️注意:“pciPassthru.64bitMMIOSizeGB”条目的值需要根据虚拟机具体直通的显卡型号和数量进行计算后得出!

博文中提供了一种简单估算方法:GPU个数 × 一块GPU的显存大小(GB为单位),然后将结果向上取整到下一个2的整数次幂。

例如,要给这个虚拟机直通两个p100显卡,则值应为:2 × 16 = 32,向上取整到下一个2的整数次幂,得到64。但如果是直通v100显卡,64则只能直通一块,因为v100单卡显存就是32G,想要直通两块就需要改为128。

⚠️注意:与通常情况不同的是不可以添加“hypervisor.cpuid.v0 = FALSE”参数!

1.3. 修改虚拟机兼容性

选择升级虚拟机兼容性

在虚拟机页面,“操作”→“兼容性”→“升级虚拟机兼容性”,打开“配置虚拟机兼容性窗口”。

配置虚拟机兼容性窗口

将虚拟机兼容性改为:ESXi 6.7 Update 2 及更高版本

2. 安装操作系统

现在可以进行第一次开机,并按照提示安装操作系统。安装后,顺便进行基本的系统配置,例如换源、配置网络、软件包升级等。

3. 为虚拟机添加显卡直通

3.1. 启用内存预留

启用内存预留

在虚拟机页面,“操作”→“编辑设置”→“虚拟硬件”→“内存”,勾选“预留所有客户机内存(全部锁定)”。

3.2. 添加显卡设备

添加显卡设备

在虚拟机页面,“操作”→“编辑设置”→“虚拟硬件”→“添加新设备”→“PCI 设备”,然后在PCI设备选项中选择需要添加的显卡。

4. 安装NVIDIA驱动和CUDA

4.1. 检查GPU

4.2. 禁用nouveau

4.3. 安装依赖包

4.4. 安装NVIDIA驱动

默认已经下载好驱动文件

4.5. 安装CUDA

「记录」解决Ubuntu Server 18.04因Intel微码修复无法启动问题

最近在重建学院GPU云,使用原来实验室云的双层虚拟化架构。原来实验室云使用的是基于ubuntu16的GPU服务器,21年再使用16版本就有点老了,准备换成ubuntu18,但是遇到一个奇怪的问题,在此记录一下。

问题的表现形式如下:

环境:

实体机:曙光 天阔 W780-G20
操作系统: VMware ESXi, 6.7.0, 14320388
管理平台: VMware vCenter Server Appliance, 6.7.0, 15129973
虚拟机兼容性: ESXi 6.7 Update 2
虚拟机高级配置附加参数:
hypervisor.cpuid.v0 = FALSE
pciPassthru.use64bitMMIO = TRUE
虚拟机操作系统版本:Ubuntu Server 18.04.5 LTS
截止2021年1月20日,已更新所有最新包

当虚拟机CPU只给一个核心的时候,一切正常。当给2个或者更多核心的时候会出现无法启动的问题,显示如下:

虚拟机无法启动的控制台输出

经过排查发现问题触发的原因有两个:①虚拟机高级配置参数 hypervisor.cpuid.v0 = FALSE;②有2个或更多CPU核心

通过搜索找到两篇类似问题的文章:ESXi 6.7 ubuntu GPU直连踩坑记VMware ESXi 6.7.0 update2 使用 GPU Passthrough 模式的坑。第一篇文章是通过更新esxi解决的,但是第一篇文章里更新后的esxi版本与我现在使用的是同一版本,所以解决方法对我不适用。第二篇文章将问题的根源指向了intel的漏洞修补微码软件包“intel-microcode”。

通过测试发现,无法启动的核心问题就是由“intel-microcode”导致的,该软件包是intel为了修补幽灵、熔断漏洞的补丁,应该是在启动之前执行某种防护操作。我测试时首先尝试卸载该软件包,并同时卸载依赖包,结果导致部分核心包被卸载,无法启动。之后测试只卸载该软件包,不卸载依赖,结果问题解决,确定问题核心就是该软件包导致。

为了解决问题,我首先想到的是在安装vsphere过程中被提示可能受intel的漏洞影响,所以我考虑可能是虚拟化平台的宿主机没有进行漏洞修补,而ubuntu虚拟机进行了漏洞修补,出现兼容性问题。为此我查阅了vsphere的文档,确定默认状态下vsphere6.7确实是不启用漏洞修补程序的。同时,我也发现启动修补程序会导致严重的性能损失,不适合我现在的场景。

之后,我考虑既然虚拟化平台没有进行漏洞修补,那关掉ubuntu虚拟机的漏洞修补应该可以解决问题。于是我阅读了第二篇文章中提到的讨论:Intel-microcode package upgrade in ubuntu 18.04 leads to unbootable system。根据这个讨论,可以通过更改grub参数的方式禁用微码修补,但是尝试了讨论中的解决方案和关联的解决方案,发现并没有效果。最终,我决定按照讨论中的最终解决方案,更换旧版本的二进制软件包。

解决方案:

「记录」博客重生记——Ubuntu 18.04安装LNMP+phpmyadmin

  因为各种客观+主观的原因(chrome恶心的安全措施、长期没有对服务器系统进行升级、脑子被门夹了非要上https、海森堡编辑器全是bug、研二全是事情等等),我做了各种令人窒息的操作,导致我的站点和博客彻底凉凉。为了完成曾老师的作业,也为了能好好做记录,我终于下定决心把整个站点重建一遍。

  其实最早只是想着从ubuntu16迁移到18,结果玩脱了。不过既然都上18了,再退到16岂不是坑都白踩了,而且16也不一定能活多久,干脆一步到位。

  这次记录除了包括在ubuntu18上部署lnmp、phpmyadmin以外,还会有https站点迁移的内容,读者请各取所需。

首先安装 lnmp

下面给一个配置文件样本,是一个很早的原始版本,仅供测试参考

有了简单配置之后可以测试下nginx和php了,一定先测试后迁移,因为在迁移过程中涉及的步骤和环节很多,而且中间几乎无法测试,一旦前期有问题最后都没法定位错误!

使用php探针测试会发现页面显示白页,nginx日志无问题,这是一个bug,解决方法如下

测试通过之后就可以开始迁移了,但是建议先把phpmyadmin装了,这样可以先配置数据库

终于可以开始迁移服务器了

完成数据库迁移之后,就是最关键的部分了,之后的步骤中间几乎完全不能调试

  1. 将整站数据上传至相应的服务器目录
  2. 修改目录属主和权限
  3. 将原服务器的nginx配置文件替换掉新服务器nginx的配置文件
  4. 修改新服务器nginx服务器文件,使得其中一些小条目符合新服务器配置
  5. 将ssl证书配置到相应目录
  6. 重启nginx
  7. 进入wordpress目录修改wp-config.php中的数据库连接信息
  8. 修改dns解析地址到新服务器
  9. 通过url访问页面测试

如果一切正常,恭喜你完成了全部步骤!