- 禁用
bcdedit /set hypervisorlaunchtype off - 开启
bcdedit /set hypervisorlaunchtype auto
Views: 61
Views: 61
使用.NET远程控制台的时候发现会有证书错误,导致无法使用.NET远程控制台,所以用acme.sh生成正确的证书
登录ILO后找到存取管理->安全性,然后点击自定义证书,填写正确的域名,生成CSR,等一会儿再点一次生成CSR,把CSR保存下来
然后执行命令
acme.sh --signcsr --csr dl360.csr --dns dns_gd
acme.sh --install-cert -d dl360.hetao.me --fullchain-file /opt/certs/dl360.hetao.me/fullchain.pem --cert-file /opt/certs/dl360.hetao.me/dl360.hetao.me.pem
cd /opt/certs/dl360.hetao.me
sed '4r dl360.hetao.me.pem' ilocert.cfg>dl360cert.cfg
hponcfg -f dl360cert.cfg
<RIBCL VERSION="2.0">
<LOGIN USER_LOGIN = "adminname" PASSWORD = "password">
<RIB_INFO MODE = "write">
<IMPORT_CERTIFICATE>
<!-- Replace the following text and comments with the certificate -->
<!-- INCLUDE the full header and full footer of the certificate -->
</IMPORT_CERTIFICATE>
<!-- The iLO will be reset after the certificate has been imported. -->
<RESET_RIB/>
</RIB_INFO>
</LOGIN>
</RIBCL>
也可以用命令行操作
然后会生成证书文件dl360.hetao.me.pem(不是fullchain.pem),把里面的证书再粘到ILO中,ILO会自动重置,ILO再次启动后就好了,.NET远程控制台也能用了。
注意:
ilo固件刷新后需要重新生成CSR,不然导入证书时会不识别
Views: 59
这个问题跟nvidia显卡虚拟化有关,执行以下命令可解决
echo “options vfio_iommu_type1 allow_unsafe_interrupts=1” > /etc/modprobe.d/iommu_unsafe_interrupts.conf && update-initramfs -u -k all
参考:
https://pve.proxmox.com/wiki/PCI_Passthrough#NVIDIA_Tips
Views: 33
P4的参数相当于GTX1080,是一个半高单槽的卡,另外P100(HBM2)和P40(GDDR5X)是双槽全高的卡,具体比较可以看这里:
https://developer.aliyun.com/article/753454
https://cloud-atlas.readthedocs.io/zh_CN/latest/machine_learning/hardware/nvidia_gpu/tesla_p10.html
P4适用于1U的服务器,P40和P100适用于2U的机器,价格比P4要贵一倍多,在HP 360 Gen9服务器上P4可以直接安装。
关于HP DL360 Gen9服务器的介绍,这个是别人写的,我贴过来:
https://cloud-atlas.readthedocs.io/zh_CN/latest/linux/server/hardware/hpe/hpe_dl360_gen9.html
360GGen9的扩展能力比较小,最多只能安装两张GPU卡,再加一个SSD就满了。
支持vGPU的显卡列表:
https://docs.nvidia.com/grid/gpus-supported-by-vgpu.html
桌面显卡启用vGPU:
https://gitlab.com/polloloco/vgpu-proxmox
apt install pve-headers-$(uname -r)
apt install build-essential dkms pve-headers mdevctl
echo -e "vfio\nvfio_iommu_type1\nvfio_pci\nvfio_virqfd" >> /etc/modules
echo "blacklist nouveau" >> /etc/modprobe.d/blacklist.conf
echo "options nouveau modeset=0" >> /etc/modprobe.d/blacklist.conf
update-initramfs -u -k all
chmod +x NVIDIA-Linux-x86_64-535.104.06-vgpu-kvm.run
./NVIDIA-Linux-x86_64-535.104.06-vgpu-kvm.run --dkms
reboot
用nvidia-smq命令可以查看显卡的工作状态
用mdevctl types命令可以查看支持的vGPU实例类型和数量,所有vGPU实例需要用完全相同的规格,显存也是等分的,不能超额分配。如果要支持8K显示至少要2G显存,如果4K显示1G就够了。
vGPU实例类型参考这里:
https://docs.nvidia.com/grid/13.0/grid-vgpu-user-guide/index.html#virtual-gpu-types-grid
– 添加虚拟机
先添加虚拟机实例,安装好virtio-gt和virtio-gm程序,虚拟机配置中开启qemu-guest-agnet,bios不要选uefi(装驱动时需要重新签名)
apt install xrdp
禁用或删除nvidia开源驱动
apt remove nvidia-*
echo "blacklist nouveau" >> /etc/modprobe.d/blacklist.conf
echo "options nouveau modeset=0" >> /etc/modprobe.d/blacklist.conf
不然的话在添加vGPU后有可能黑屏
添加PCI设备
硬件->添加->PCI设备
这里面列出的设备可能比较多,要仔细找
以Debian为例
– 开启xorg(关闭wayland)
编辑/etc/gdm3/daemon.conf,添加
WaylandEnable=false
sudo apt update
sudo apt upgrade
reboot
sudo apt install dkms build-essential dkms jq uuid-runtime -y
sudo apt install -y linux-headers-$(uname -r)
sudo apt install pkg-config libglvnd-dev -y
init 3
echo "blacklist nouveau" >> /etc/modprobe.d/blacklist.conf
echo "options nouveau modeset=0" >> /etc/modprobe.d/blacklist.conf
update-initramfs -u -k all
chmod +x NVIDIA-Linux-x86_64-535.104.05-grid.run
./NVIDIA-Linux-x86_64-535.104.05-grid.run --dkms
reboot
curl --insecure -L -X GET https://dls.hetao.me/-/client-token -o /etc/nvidia/ClientConfigToken/client_configuration_token_$(date '+%d-%m-%Y-%H-%M-%S').tok
service nvidia-gridd restart
nvidia-smi -q | grep "License" #要等大约1分种后才能看到结果,每次授权的有效期是3个月
apt install xrdp
驱动下载
现在可用的下载链接:
https://alist.homelabproject.cc/foxipan/vGPU
https://yun.yangwenqing.com/ESXI_PVE/vGPU/NVIDIA
https://pan.hetao.me/s/RHMxwE95QwmGmAG
已经不能下载:
https://foxi.buduanwang.vip/pan/vGPU/
https://foxi.buduanwang.vip/pan/foxi/Virtualization/vGPU/
https://github.com/justin-himself/NVIDIA-VGPU-Driver-Archive
https://archive.biggerthanshit.com/NVIDIA/
参考:
https://gitlab.com/polloloco/vgpu-proxmox/-/tree/master
Views: 343
近日,工信部发布《关于推进5G轻量化(RedCap)技术演进和应用创新发展的通知(征求意见稿)》,提出到2025年,5G RedCap产业综合能力显著提升,新产品、新模式不断涌现,融合应用规模上量,安全能力同步增强。其中,全国县级以上城市实现5G RedCap规模覆盖,5G RedCap连接数实现千万级增长。
一时间,RedCap再次成为业界关注的焦点。
那到底什么是RedCap?我们今天来展开讲讲。
先来画一张蜂窝物联技术演进图。
自Release 8以来,在移动宽带(MBB/eMBB)速率不断增长的同时,3GPP也引入了LTE Cat 1、Cat 1 bis、eMTC、NB-IoT、EC-GSM、RedCap等多种蜂窝物联技术。
这些蜂窝物联技术通过不同程度的“功能裁剪”来降低终端和模组的复杂度、成本、尺寸和功耗等指标,从而“量体裁衣”适配不同的物联需求。
简单介绍一下:
LTE Cat 1是3GPP Release 8专门为M2M物联应用制定的蜂窝物联技术,信道带宽为20MHz,下行峰值速率为10Mbps,上行为5Mbps。
LTE Cat1 bis提出于Release 13,作为Cat 1的演进,它进一步将LTE Cat 1终端的双接收天线裁剪为单接收天线。
LTE Cat 0是3GPP Release 12提出的适用于物联应用的UE类型,信道带宽为20MHz,上下行峰值速率为1Mbps。LTE Cat 0支持单接收天线和半双工模式,因此与LTE Cat 1相比,终端复杂度下降至少50%。
在Release 13中,LTE Cat 0演进为eMTC或LTE-M(Cat M1)。由于最大信道带宽缩减至1.4MHz,LTE Cat M1相比LTE Cat 0的复杂度进一步减小,覆盖能力得到进一步提升。
之后,eMTC演进至5G时代的Release 15和Release 16,功能持续增强。
NB-IoT是3GPP Release 13引入的窄带物联技术,信道带宽为180KHz,峰值速率几十至200Kbps左右。
与eMTC一样,NB-IoT也从4G时代的Release 13、Release14持续演进至5G时代,功能不断增强,共同推动5G Massive IoT发展。
EC-GSM-IoT是3GPP Release 13规范的一部分,主要由2G技术升级演变而来,可通过2G GSM网络软件升级实现,信道带宽为200KHz,峰值速率约70至240Kbps。
RedCap制定于5G Release 17版本,全称Reduced Capability NR,即“裁剪NR能力”的意思,所以也被称为轻量版、简化版的5G NR。
众所周知,5G最初定义了eMBB、uRLLC和mMTC三大场景,与之相对应,5G时代的物联网类型包括宽带物联网、关键任务型物联网和大规模物联网。
eMBB主要针对高清视频、VR/AR等大带宽应用,通常网络下行峰值速率高达Gbps,上行达几百Mbps。
uRLLC主要针对远程控制、无人驾驶等关键任务型物联网应用,要求网络端到端时延低至毫秒级,可靠性高达5个9。
而mMTC由4G时代的NB-IoT和eMTC低功耗广域物联网技术演进而来,主要面向智能抄表、智能路灯等大规模物联网场景,对数据传输速率和时延要求很低,网速小于2Mbps,时延可容忍至10秒。
虽然这三大场景差异化匹配了高速率、低时延和低速率的物联应用需求,但细心的你一定发现了,那些对速率和时延要求中等的物联网应用还没有覆盖到。
比如,用于测量和采集温度、湿度、压力等数据的工业无线传感器要求数据传输速率约2Mbps,时延小于100毫秒,可靠性仅需99.99%;智能手表、医疗监控设备、AR/VR眼镜等可穿戴设备要求数据传输速率约2至10Mbps;监控摄像头要求数据传输速率约2至25Mbps,时延小于500毫秒,可靠性仅需99%至99.9%。
这些物联网场景如果用eMBB和uRLLC能力来支撑,就是大材小用、资源浪费,而mMTC的速率和时延能力又不能满足需求。
RedCap,正是为了填补eMBB、mMTC与uRLLC之间的“空白地带”而生的蜂窝物联技术。
正如演进图中所示,RedCap位于中间位置。如果根据带宽、时延、成本、终端功耗、覆盖距离等技术指标将5G蜂窝物联网分为低、中、高三个档位,那么RedCap就是5G时代的“中档”物联技术。
RedCap裁剪了哪些能力?
640?wx_fmt=png
如上表,Release 17 RedCap主要裁剪了以下功能,从而将终端复杂度和成本下降50%至65%。
为了实现更高的峰值速率,RedCap终端设备也可以不用裁剪得这么狠,可以选择更高级的功能,比如支持2个接收天线、2个下行MIMO层、256QAM、全双工FDD等。
通过这些能力剪裁,可更加低成本、高效率地匹配可穿戴设备(包括可穿戴手表、AR/VR眼镜等)、工业无线传感器、监控摄像头等物联应用的网络连接需求。
同时,针对可穿戴设备、工业无线传感器等通常没有外部供电条件的场景,要求电池使用寿命长达1-2周甚至数年,RedCap还通过降低终端发射功率等级、引入eDRX和RRM测量放松等节电技术,来进一步降低终端功耗。
比较一下技术指标,很明显,RedCap主要将取代4G时代的LTE Cat 4和LTE Cat 1/1 bis。
准确点讲,Release 17版本的RedCap预计将取代基于LTE Cat 4的物联应用。而Release 18版本中的RedCap,即增强版RedCap预计将取代基于LTE Cat 1和LTE Cat 1 bis的物联应用。
在R18版本中,增强版的RedCap或将增加支持5MHz、10MHz和40MHz带宽,并进一步降低终端复杂度和成本,以及增加定位、sidelink连接等功能,从而支撑更广泛的物联应用。
为啥要取代LTE Cat 4和Cat 1/1bis?
首先,RedCap为4G时代的LTE Cat1/1 bis和Cat 4提供了向5G网络迁移的路径,面向未来利于运营商重耕4G LTE频谱资源。据统计,当前LTE Cat 1 bis 和 Cat 4 约占当前全球蜂窝物联网市场的一半。
其次,与LTE Cat 4和Cat 1/1bis相比, RedCap天然具有5G能力优势,比如,不仅支持包括毫米波在内的更广泛的频段、网络效率更高、具备5G安全能力,而且可与5G网络切片、5G专网、5G定位等技术结合提供更好的物联服务,同时理论上运营商只需对现有5G网络进行软件升级即可部署。
另外,RedCap填补了中档物联空白,使5G具备了一张网络适配所有低、中、高档物联应用的能力,这也利于蜂窝物联网统一高效管理。
转载自:https://www.txrjy.com/thread-1297962-1-1.html
Views: 8
低时延,大带宽,与embb共存部署,urll可以与tsn结合使用,为了降低时延还需要全双工支持(R19支持TDD的全双工)
4G时代定义的技术,被5G采纳
nb-iot 使用180khz带宽,支持159/127kbs的上下行
eMTC使用1.4MHz带宽时支持1Mbps的上下行,使用5MHz带宽时支持7/4Mbps的上下行
R15中支持NR带内部署,R16中支持连接5G核心网
速率高于eMTC,仅次于eMBB,与eMBB共存部署
使用20MHz带宽时91/227Mbps的上下行,使用10MHz时支持100Mbps的上下行,使用5MHz时支持10Mbps的上下行。
Views: 18
wifi8(802.11bn)计划是2028年最终发布,预计2026或2027年会发布一个中间节点的标准,主要特性是集成毫米波,AP协同,基于MLO的漫游,降低延迟和抖动,节能,改进P2P(wifi直连)
Views: 176
参考:
https://www.txrjy.com/thread-1214262-1-1.html
https://www.txrjy.com/thread-1278460-1-1.html
https://www.atis.org/?smd_process_download=1&download_id=1732913
https://www.5gamericas.org/wp-content/uploads/2022/12/Becoming-5G-Advanced-the-3GPP-2025-Roadmap-InDesign.pdf
https://www.qualcomm.com/content/dam/qcomm-martech/dm-assets/documents/setting-off-the-5g-advanced-evolution-with-3gpp-release-18.pdf
Views: 103
路由器在转发包的时候优先顺序依次是NAT,路由表,IPSec策略。
IPSec报文的处理流程如下(参考:https://forum.huawei.com/enterprise/zh/thread/580935480827068416):
FW处理流程中,IPSec的处理位于NAT、路由、安全策略之后,故应保证NAT策略对IPSec保护的报文不进行处理,IPSec保护的报文能够通过匹配路由和安全策略被送达应用了IPSec安全策略的接口。具体要求如下:
1. 到达FW的报文不能匹配NAT Server建立的Server MAP表和反向Server MAP表,否则报文目的地址将被转换。
2. 到达FW的报文不能匹配目的NAT的策略,否则报文目的地址将被转换。
3. 路由表中必须有到达IKE对等体私网的路由(一般为缺省路由),路由的出接口为应用了IPSec策略的接口。若没有匹配的路由,报文将被丢弃;若匹配路由的出接口为其它接口,报文也将无法进入IPSec处理模块,以明文形式发送。
4. IPSec VPN数据流一般在域间流动,故要求开放源域(内网接口所在域)和目的域(应用了IPSec策略的外网接口所在域)之间的域间包过滤,否则报文将被丢弃。
5. 通过域间包过滤策略检查的报文可以做源NAT,也可以不做。当匹配源NAT的域间NAT策略时,报文源地址被转换,此时匹配security acl的是转换后的源IP地址。当不匹配域间NAT策略时,报文被直接送入IPSec模块。
6. 进入IPSec模块的报文只有在匹配了security acl的情况下才能被保护,否则被丢弃。
所以理论上来说只要被路由器接收到并且匹配security acl的报文都会被IPSec转发,接收到的报文可以来自物理接口,也可以是隧道接口或者其它VPN策略接收到的报文。
因为ipsec使用ACL来匹配要处理的报文,而ACL规则又比较灵活。在ACL中可以同时指定源地址和目的地址,也可以只指定目的地址或源地址,当只指定目的地址时则起到与路由表类似的效果。
关于security acl有如下描述:
该命令用于通过ACL方式指定需要IPSec保护的数据流。实际应用中,首先需要通过配置ACL的规则定义数据流范围,再在IPSec安全策略中引用该ACL,才能起到保护该数据流的作用。
当以IPSec安全策略模板方式创建IPSec安全策略时,定义需要IPSec保护的数据流在协商的响应方为可选:
•如果协商的响应方不指定需要IPSec保护的数据流,则表示接受发起方定义的需要IPSec保护的数据流的范围。
•如果协商的响应方指定需要IPSec保护的数据流,则需要与发起方镜像配置或者包含发起方指定的保护的数据流范围。
也就是说IPSec会结合连接双方的acl配置选取其子集作为生效的报文匹配策略,并不要求双方一致。IPSec连接本身是点对点的。
基于以上可做如下配置:
– 在响应方(中心IPSec)配置ACL的目的网段匹配所有分支机构的网段
– 在请求方(分支机构)配置ACL的目的网段匹配其它分支机构和中心IPSec的网段
在ACL中仅指定目的网段即可,这样配置等于把对应的目的网段路由到IPSec通道。也可以同时指源网段,但是分支机构多时中心IPSec上的ACL会非常复杂,每个组合都要写才行,所以不建议,也没必要。
Views: 55
mkdir my-electron-app && cd my-electron-app
npm init ;生成package.json文件
package.json文件的内容如下
{
"name": "my-electron-app",
"version": "1.0.0",
"description": "Hello World!",
"main": "main.js",
"author": "Jane Doe",
"license": "MIT"
}
author和description项不能为空,否者npm run make会报错
在根目录创建好以下3个文件,参考:
https://github.com/electron/electron/tree/v25.5.0/docs/fiddles/quick-start
npm install --save-dev electron
npm install --save-dev @electron-forge/cli
npx electron-forge import
最后执行
npm run make
生成应用程序包
Views: 132