虚拟机主机信息文件发生改变

主机文件变化，通常源于以下几类机制：

1. 平台自动化机制（最可能的原因）

   • 定期系统巡检与优化：平台会按预设计划（如每日/每周）执行健康检查、磁盘碎片整理、存储空间均衡（如Ceph的rebalancing）等任务，都会导致文件状态变更。

   • 虚拟机生命周期事件：即使没有手动操作，快照的自动创建/合并、虚拟机内部的系统更新或软件安装、系统日志的生成/轮转、内存交换文件的变化等，都会引起主机文件系统变化。

   • 分布式存储后端操作：UIS的ONEStor分布式存储会因硬盘故障、节点增减触发数据的自动修复和重新平衡（Rebalancing），操作期间文件会持续变化。

2. 外围集成系统（可能性中等）

   • 监控系统：如果部署了第三方监控工具（如Zabbix），其定期轮询也可能在主机上留下访问痕迹。

   • 备份软件：配置了定期备份策略的第三方备份软件，其运行时也会导致文件变化。

   • 安全软件：企业级防病毒或入侵检测软件（IDS/IPS）在后台扫描文件时，同样会留下访问或修改记录。

3. 人为或安全事件（可能性较低，但需警惕）

   • 排查是否有其他管理员通过SSH等方式登录主机进行操作。如发现未知操作，可能是系统存在异常或被入侵的迹象。

遵循由近及远、由平台到系统的排查顺序，有助于高效定位问题。

1. 第一步：查“案发现场”（快速定位）

   • 登录UIS管理平台，进入“系统”或“任务” 页面，查看任务列表，重点寻找与文件变化时间点匹配的系统任务（如巡检、存储修复等）。

   • 检查“告警” 页面，查看文件变化前后是否有关于磁盘、存储池或主机的告警。

2. 第二步：看“任务日志”（追根溯源）

   • 进入“审计”或“日志” 菜单，使用关键词（如operation log、task）过滤，按时间范围搜索相关操作记录。

   • UIS的审计日志通常会记录“谁”（操作者）、“什么时间”（操作时间）、“做了什么”（操作内容） 等信息，这是定位操作来源的直接证据。

3. 第三步：翻“系统日志”（深挖细节）

   • 若前两步未发现线索，需登录到具体的主机节点（CVK），通过SSH查看底层系统日志。

   • 查看任务计划：执行 crontab -l，检查是否存在非预期的定时脚本。

   • 查看历史命令：检查 /var/log/messages、/var/log/cron 等系统日志文件。注意，日志文件本身会因轮转而变化，观察时需排除此类正常变动。

   • 启用审计功能：若常规手段无法定位，可启用Linux的auditd服务，对目标目录（如/var/lib/libvirt/images/）设置精细的监控规则，精确捕捉变更的进程和操作。

一、先确认：你看到的 “变化” 是什么样？

1. XML 内部字段更新（最常见）
   • 文件修改时间变了
   • 内容里多了一些 <uuid>、<seq>、<timestamp>、<runtime>、<host> 相关字段
   • 或部分参数顺序、注释、空行变化
2. 真的配置被改写（少见）
   • 网卡、磁盘、CPU、内存等关键配置被改
   • 虚拟机突然变配置、无法启动

二、UIS/CAS 下，自动导致配置文件变化的常见原因（无人工操作）

1. 虚拟机正常启动 / 停止 / 重启 → 平台自动更新 XML

• 虚拟机每次 开机、关机、挂起、恢复
• UIS/CVM 都会 自动重写 XML：
  • 写入 运行时状态、启动时间戳、调度信息、宿主机信息
  • 增加 / 更新：<runtime>、<last-startup>、<host>、<seq>、<generation> 等
• 表现：
  • 文件修改时间更新
  • 内容多了几行运行时字段
  • 业务完全正常

2. 平台定时同步、心跳、状态刷新（后台自动）

• UIS 集群 / 主机 定时同步虚拟机状态（几分钟～几十分钟一次）
• 为保证 高可用、HA、资源调度、状态一致
• 后台自动 刷新、重写 VM 配置文件
• 表现：
  • 虚拟机在运行中，无人操作，但 XML 突然更新时间
  • 内容少量变化（时间戳、状态标记）

3. Tools（CAS Tools）自动升级 / 状态上报

• 如果开启：虚拟机 Tools 自动升级、状态上报
• 虚拟机内部 Tools 向 CVM / 主机 上报：
  • IP、进程、驱动状态、性能数据
• 平台收到后 自动更新 VM 配置 / 元数据
• 表现：
  • XML 里多了：<guest-agent>、<ip-address>、<tools-version> 等

4. 集群 HA、DRS 调度、资源重平衡（后台隐式动作）

• 即使 没手动迁移，UIS 开启：
  • HA 高可用
  • DRS 负载均衡、资源调度
• 平台会：
  • 隐式调整虚拟机的 “归属主机、调度策略、资源约束”
  • 不触发完整迁移，但 更新配置文件里的主机亲和、位置信息
• 表现：
  • XML 中 <host>、<scheduler>、<placement> 相关字段变化
  • 用户无感知、业务不中断

5. 平台 / 主机 时间同步、时钟变化

• 主机 NTP 同步、时间跳变
• 虚拟机配置文件里 时间戳字段被更新
• 表现：仅时间相关字段变

6. UIS/CAS 平台 自动备份、快照索引更新

• 开启 自动快照、定时备份
• 每次快照 / 备份：
  • 平台 更新虚拟机配置中的磁盘链、快照索引、备份标记
• 表现：
  • XML 里 <disk> 部分多了快照相关 snapshot='yes'、index 等
  • 或备份相关字段

7. 底层存储 / 路径轻微变化（存储扫描、重挂载）

• 存储 重新扫描、路径刷新、多路径切换
• 虚拟机磁盘 <source file='...'/> 路径、dev 名被平台标准化 / 重写
• 表现：
  • 磁盘路径格式变化（如 /dev/sdb1 → /dev/mapper/...）
  • 或文件路径大小写、符号链接标准化

8. 平台 补丁 / 小版本升级、配置规则变更

• UIS/CVM 自动打补丁、规则更新
• 为兼容新版本，批量标准化、重写所有 VM XML
• 表现：
  • 同一时间 大量虚拟机 XML 同时更新
  • 内容结构、字段顺序、注释变化

三、少见但要警惕：真正 “异常修改” 的情况

1. 关键配置被篡改
   • CPU、内存、网卡、磁盘 数量 / 型号被改
   • 虚拟机 无法启动、网络不通、丢盘
2. 配置文件被删除、损坏、乱码
3. 多台虚拟机同时异常、且伴随：
   • 集群分裂、主机失联、存储异常、CVM 报错
4. 有未授权登录、操作日志异常

四、你现在该怎么做（排查 + 确认）

1. 先看变化内容（最关键）

• SSH 登 CAS 主机
• 进入虚拟机配置目录（默认）：
  bash

  运行

  cd /etc/libvirt/qemu/ # 或 cd /var/lib/libvirt/qemu/
• 对比 变化前后的 XML：
  bash

  运行

  # 看修改时间 ls -l 虚拟机名.xml # 对比差异（用 diff） diff 虚拟机名.xml 虚拟机名.xml.bak # 或直接看最后几行 tail -20 虚拟机名.xml
• 判断标准：
  • 只变：时间戳、runtime、host、seq、uuid、tools、scheduler → 正常自动行为
  • 变了：CPU、内存、网卡、磁盘、mac、vnc 密码 → 异常，要查日志

2. 查 UIS/CAS 操作日志（确认有没有人 / 任务动过）

• Web 界面：
  • 【云资源】→【虚拟机】→【操作日志 / 事件】
  • 看：谁、何时、做了什么
• 命令行（主机）：
  bash

  运行

  # 查看 libvirt 操作日志 tail -f /var/log/libvirt/qemu/虚拟机名.log # 查看 CAS 操作日志 tail -f /var/log/h3c/cvm/ tail -f /var/log/h3c/cas/
• 结论：
  • 日志 无任何人工操作 → 平台自动更新
  • 日志有 unknown user、定时任务、API 调用 → 追查来源

3. 查是否开启：自动快照、HA、DRS、Tools 升级

• 【集群】→【高可用 / HA】→ 是否开启
• 【集群】→【调度策略 / DRS】→ 是否开启自动负载均衡
• 【虚拟机】→【工具】→ Tools 自动升级 是否开启
• 【备份 / 快照】→ 自动任务 是否存在

五、总结（给你直接结论）

• UIS/CAS 本身就会在虚拟机运行、状态同步、HA/DRS、Tools 上报、定时刷新时，自动更新 XML 配置文件
• 没有人工操作、没有迁移、没有克隆，文件照样会变
• 只要业务正常、关键配置（CPU / 内存 / 网卡 / 磁盘）没被改，就完全不用管