解决 Windows instance 时间不同步问题 - 每天5分钟玩转 OpenStack(153)

 

这是 OpenStack 实施经验分享系列的第 3 篇。

问题描述

通过上一节部署出来的 Windows instance 有时候会发现操作系统时间总是慢 8 个小时,即使手工调整好时间和时区,下次 instance 重启后又会差 8 个小时。

原因

KVM 对 Linux 和 Windows 虚拟机在系统时间上处理有所不同,Windows 需要额外一些设置。

解决办法一

给 Windows 镜像添加 os_type 属性。

glance image-update --property os_type="windows" <IMAGE-ID>

明确指定这就是一个 windows 镜像。通过此镜像部署 instance 的时候,KVM 会在其 XML 描述文件中设置相应参数,保证时间的同步。

解决办法二

对于之前部署的 Windows instance,用第一种方法就没有效果了,只能采取一点非常规手段:Hack Database!

假设要 hack 的 instance 的名字是 win-test,用下面的 MySQL 命令:

$ use nova;

$ update instances set os_type='windows' where hostname='win-test';

$ select hostname,os_type from instances where hostname='win-test';

+------------+----------+

| hostname  | os_type  |

+------------+----------+

| win-test     | windows |

+------------+----------+

需要重启 win-test,KVM 会获取修改后的数据库信息,更新 XML 配置,保证时间同步。

下一节继续讨论镜像使用上的经验和技巧。

时间: 2024-09-20 21:22:17

解决 Windows instance 时间不同步问题 - 每天5分钟玩转 OpenStack(153)的相关文章

部署 instance 到 OVS flat network - 每天5分钟玩转 OpenStack(135)

上一节创建了 OVS flat network,今天我们部署 instance 并验证 flat 网络的连通性. launch 新的 instance "cirros-vm1",网络选择 falt_net. cirros-vm1 分配到的 IP 为 172.16.1.3. cirros-vm1 被 schedule 到控制节点,其虚拟网卡也连接到 br-int. 虚拟网卡与 br-int 的连接方式与 local 网络是一样的,不再赘述. 当前 flat_net 的结构如下: 继续用同

instance “error” 了怎么办?- 每天5分钟玩转 OpenStack(159)

  这是 OpenStack 实施经验分享系列的第 9 篇. OpenStack 用多了,经常会遇到这种情况:对 instance 执行某个操作如果失败了就会处于 "error" 状态: 而且这时我们除了删除 instance 外,几乎做不了其他操作. 本节就教大家如何恢复 "error" 的 instance.以上面的情况为例,error 之后,可以点击 instance 的链接,到详情页中看看 error 的具体原因. 可以看到当时执行 resize 操作时发生

制作 OpenStack Windows 镜像 - 每天5分钟玩转 OpenStack(152)

这是 OpenStack 实施经验分享系列的第 2 篇. OpenStack 通过 Glance 镜像部署 instance,上一节我们介绍了 linux 镜像制作方法,windows 镜像与 linux 有很大不同,今天我们以 windows2008 为例详细讨论. 镜像制作步骤如下:1. 创建并运行 windows2008 KVM 虚拟机2. 安装 virtio 驱动3. 安装 cloudbase-init4. 其他定制工作5. 创建 Glance 镜像6. 通过镜像部署新 instance

nova-compute 部署 instance 详解 - 每天5分钟玩转 OpenStack(28)

本节讨论 nova-compute,并详细分析 instance 部署的全过程. 先给大家道个歉:今天这篇文章的篇幅比以往要多一些,本来想分两次发,但考虑到文章的完整和系统性,还是一次发了出来,这次可能要超出 5 分钟了,大家见谅. nova-compute 在计算节点上运行,负责管理节点上的 instance. OpenStack 对 instance 的操作,最后都是交给 nova-compute 来完成的. nova-compute 与 Hypervisor 一起实现 OpenStack

创建 vxlan 并部署 instance - 每天5分钟玩转 OpenStack(147)

上一节我们完成了 OVS VxLAN 的配置工作,今天创建 vxlan100_net 并部署 instance. 创建 vxlan100_net 打开菜单 Admin -> Networks,点击 "Create Network" 按钮. 显示创建页面. Provider Network Type 选择 "VXLAN".  Segmentation ID 即 VNI,设置为 100. 点击 "Create Network",vxlan100

Migrate Instance 操作详解 - 每天5分钟玩转 OpenStack(40)

Migrate 操作的作用是将 instance 从当前的计算节点迁移到其他节点上. Migrate 不要求源和目标节点必须共享存储,当然共享存储也是可以的. Migrate 前必须满足一个条件:计算节点间需要配置 nova 用户无密码访问. 下面是 Migrate instance 的流程图 向 nova-api 发送请求 nova-api 发送消息 nova-scheduler 执行调度 nova-scheduler 发送消息 nova-compute 执行操作 下面我们详细讨论每一个步骤.

Snapshot Instance 操作详解 - 每天5分钟玩转 OpenStack(36)

本节我们通过日志详细讨论 instance 的 snapshot 操作. 有时候操作系统损坏得很严重,通过 Rescue 操作无法修复,那么我们就得考虑通过备份恢复了.当然前提是我们之前对instance做过备份. Nova 备份的操作叫 Snapshot,其工作原理是对 instance 的镜像文件(系统盘)进行全量备份,生成一个类型为 snapshot 的 image,然后将其保存到 Glance 上. 从备份恢复的操作叫 Rebuild,将在下一节重点讨论. 下面是 snapshot in

Start Instance 操作详解 - 每天5分钟玩转 OpenStack(31)

本节通过日志文件详细分析 instance start 操作. 下面是 start instance 的流程图 向 nova-api 发送请求 nova-api 发送消息 nova-compute 执行操作 下面我们详细讨论每一个步骤. 向 nova-api 发送请求 客户(可以是 OpenStack 最终用户,也可以是其他程序)向API(nova-api)发送请求:"帮我启动这个 Instance" 查看日志 /opt/stack/logs/n-api.log nova-api 发送

将 instance 连接到 flat_net - 每天5分钟玩转 OpenStack(88)

上一节我们创建了 "flat_net",本节将在此网络中部署 instance 并验证连通性. launch 新的 instance "cirros-vm1",选择网络 falt_net. cirros-vm1 分配到的 IP 为 172.16.1.103. cirros-vm1 被 schedule 到控制节点,对应的 tap 设备为 tapc1875c7f-cb,并且已经连接到 bridge. 当前 flat_net 的结构如下: 继续用同样的方式 launch