搜索内容

包含标签：重启 的文章

  • 在计算云中windows虚拟机重启后网络不通

    问题描述 用户反映虚拟机（win2003 32位）重启后，网络不通，无法使用，后台通过VNC登录发现系统没有发生卡死现象，ping网关报目的不可达。 处理过程 1.第一天开机登录。域控更改策略，客户机同步策略以致ntuser.pol文件被加密。 2. 关机重启，ipsec服务工作正常,winlogon.exe访问策略文件ntuser.pol，并通过其修改注册表，但该文件无法识别（EventId:1096），以致删除ipsec注册表，但ntuser.pol会重新生成。 3.再次关机重启，ipsec服务访问ipesc注册表，但ipesc注册表已被删除，以致ipsec服务不能启动，并导致其阻止通信（EventId:4292），虚拟机网络不通。 根因 经过定位，发现云平台一切正常，故障虚拟机的ipsec服务没有启动（手动启动报错：系统找不到指定的文件）；确认为ipsec服务异常导致的网络连接异常； 与同类型正常运行的虚拟机对比后，发现注册表中的表项（HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\IPSec）缺失导致ipsec服务无法启动； 解决方案 运行命令regsvr32 polstore.dll，恢复默认ipsec注册表。手动启动ipsec服务。 原文

    SE_You 2024-10-21
    8 0 0

  • FusionCompute产品CNA节点重启问题

    问题描述 某服务器虚拟化局点采用RH5885服务器作为CNA节点，两台CNA节点发生重启。 告警信息 无 处理过程 分别收集两台CNA的message日志分析，message日志显示现网2台CNA分别在15:38和19:50左右出现了异常重启。 1. 分析19:50重启后生成dump的文件，从dump信息看该节点重启原因为系统lpfc驱动异常触发。 2. 15:38分重启原因从串口日志中可以看出同样是由于lpfc驱动异常导致。 现网FusionSphere版本为R3C00SPC200，lpfc驱动版本为8.3.5.48.3p，经研发确认该版本驱动小概率异常情况下会导致服务器重启。FusionCompute R3C00SPC300版本已经修复该问题（驱动lpfc升级为8.3.7.18版本），现网升级到FusionCompute R3C00SPC300版本后问题解决。 根因 对于服务器重启问题，需要通过操作系统message日志和dump日志来分析问题原因。 建议与总结 针对RH5885服务器的lpfc驱动问题在已发布的FusionAdaptor版本修复，并在FusionCompute R3C00SPC300及R3C10版本合入，考虑到在FusionCompute R3C00SPC200使用RH5885的局点很少，且均已完成FusionAdaptor补丁安装。后续的新局点使用FusionCompute R3C00SPC300及R3C10版本交付。

    SE_You 2024-07-01
    46 0 0

  • Atlas 500 异常重启现象

    问题描述 多台Atlas 500智能小站发生异常重启现象，影响现场业务运行。 处理过程 一线人员反馈现场3台设备出现异常重启现象，收集日志后，首先通过MCU日志确定系统重启的时间（MCU侧时间慢8小时，与OS日志对应时，加上8小时）； 对应OS_Drivers下的kbox日志，系统重启时间与kbox记录时间吻合； 查看重启时的kbox日志，都存在out_of_memory+0x210/0x530以及oom stack堆栈相关记录，meminfo中可用内存为0Kb，确认重启原因为内存耗尽； 根据kbox日志，可确认内存溢出时的top 10进程，如下所示，其中红框标示的数据为重启时进程占用物理内存的数值，单位为pages，数据x4Kb便可计算出重启时进程占用内存的大小： xbull () ./xbull : 632146 *4Kb=2.41G java () /usr/jdk/bin/java : 77560*4Kb=0.3G mysqld ():49544 *4Kb=0.19G java () /usr/jdk/bin/java -Xms256M : 62186*4Kb=0.24G java () /usr/jdk/bin/java : 49718*4Kb=0.19G 经计算可知，以上用户的业务程序，占用了大量的物理内存（总内存4G），约3.4G； 日志中total_top_10_rss=916805(pages)表示当前top10 进程总的内存使用页（pages），乘以4Kb可换算出已使用的内存，916805*4Kb=3.5G，而total_rss_all=942163(pages)表示系统可用总页数，942163*4Kb=3.6G，可以内存基本已占用完。 另外两台设备kbox日志记录同样的问题，由此可确定，异常重启的原因是客户相关业务进程占用了内存过多导致系统内存不足，触发复位。 根因 用户运行的程序或者业务进程占用内存过大，剩余系统内存不够导致系统重启 解决方案 建议用户排查业务、分析内存占用率高的相关进程，降低内存消耗，修复内存泄漏问题 免责声明：本案例仅供参考不提供专业意见。

    SE_You 2022-07-11
    18 0 0