首页 文章 精选 留言 我的

精选列表

搜索[虚拟线程],共10000篇文章
优秀的个人博客,低调大师

微信语音遥控Windows Azure云虚拟

去年3月份时,我和朋友陈希章老师合作过一个微信语音操控云服务的场景。敝帚不敢自珍,我想简单交代一下这个策划的源起和经历。 先来看一下视频(抱歉被优酷压缩得很厉害,不太清晰)哈,里面有功能演示和原理介绍。 为什么会有这个想法? 最初只是想到网上常见的应答机器人(例如大家常用的微信天气订阅),例如客户问: -买了你们的Cloud,我能获得什么服务呀? -可以自动回复一段非常地道的官方解答,甚至可以播放音频视频等 后来就想:为什么不能我发一条微信,让它自动代我们控制Windows Azure -例如我发条微信说创建虚机,它就真的替我们创建虚机? -例如我说启动虚机,它就真的替我们启动,而且还不需要麻烦IT部门? 这想必会受到BU(业务部门)的喜爱,因为他们可以直接利用社交端对Windows Azure做一些最简单的管理,而不再需要IT部门干预。 BU难道不就是期待自己能做一些最简单的事情?业务来了开一下机器,业务拓展了,我也能发条消息自动扩展Azure架构。而且完全是用微信上的自然语言,多棒啊? IT部门的价值在哪里?后端的自动化架构都是他们利用云计算的自动化架构搭建的,这才是他们的价值。混合云的价值! 社交2.0 整个过程完全符合社交2.0的定义: -在社交圈里想出点子 -在社交圈里设计策划/在社交圈里组织讨论 -同事和客户IT积极参与 -在社交圈里形成方案 -最终成果在社交圈里发布 -甚至产品都和社交有关 我们自信这是一个很2.0的产品。 微信里倡议,并立刻得到反馈。当时还只是想到把消息回送到微信里,当时立马讨论,形成可行性分析。 后来逆向思维,既然回送消息是可能的,那么能否反过来,通过微信消息来操控IT系统、或者云服务? 移动互联网的精髓,就是快速迭代、快速发布,很快陈希章老师就开发出微信接口,而盆盆则做出runbook和微信接口程序对接,很快搞定了这个产品。 这只是一个开始 这只是一道开胃菜而已,仅从技术层面,就能拓展很多东西: - BU用户创建Azure虚机,领导直接在微信上批准,后端自动化架构收到消息,自动创建虚机 - BU用户查看虚机状态,是不是过载啊等等,后端自动化架构收到消息,立即反馈虚机的健康和性能消息 本文转自 ahpeng 51CTO博客,原文链接:http://blog.51cto.com/markwin/1623252,如需转载请自行联系原作者

优秀的个人博客,低调大师

在 KVM 上安装 Win7 虚拟

之前都是在用Linux 虚机,现在有需要用到Win7 虚机,才发现在 KVM 上安装 Win7 的过程远比想象中的复杂。本文就把其过程做个简单总结。 1. 在 Virtual Machine Manager 里面安装 首先尝试在 Virtual Machine Manager 里面安装。遇到的问题如下: (1)一直停留在 starting windows 界面。 解决方法:修改 video model 为 Cirrus,问题解决。 (2)开始安装后,对鼠标和键盘无响应。 google,发现需要使用<input type=’tablet’ bus=’usb’/>。添加一个: 但是键盘还是不好使。。算了,还是转到使用 qemu-system-x86_64 命令启动虚机吧。 2. 使用qemu-system-x86_64 启动 Win 7 虚机 2.1 环境准备 (1)下载 Windows virtio driver iso:https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/virtio-win-0.1.102/,因为要将磁盘挂接为 virtio 磁盘。 (2)创建系统盘qemu-img create -f raw win7.img 30G,这将作为Win7的操作系统盘。 (3)创建启动脚本 #!/bin/sh DISKIMG=/home/s1/win7.img WIN7IMG=/home/s1/en_windows_7_enterprise_x64_dvd_x15-70749.iso VIRTIMG=/home/s1/virtio-win-0.1.102.iso qemu-system-x86_64 --enable-kvm -drive file=${DISKIMG},if=virtio -m 2048 \ -net nic,model=virtio -net user -cdrom ${WIN7IMG} \ -drive file=${VIRTIMG},index=3,media=cdrom \ -rtc base=localtime,clock=host -smp cores=2,threads=4 \ -usbdevice tablet -cpu host -name win7 -vnc :5 -device cirrus-vga,id=video0,bus=pci.0,addr=0x4 (4)可以运行脚本了,然后通过 VNC 进入界面,进入下面部分。 2.2 安装 Win 7 (1)选择 Custom(advanced) (2)选择 virtio 磁盘 (3)选择 virtio disk driver (4)安装 Win7 Virtio SCSI Driver (5)安装好以后,就可以看到安装的目标磁盘了 (6)进入常规的 Win7 安装流程 3. 安装其它 Virtio 驱动 (1)网络驱动 但是安装失败: 尝试 device manager: 但是还是失败: (2)Baloon driver Device manager, 右键 root device, add legacy hardware, next, install manually (advanced), next, have disk, browse, select inf, install. 改成此方法安装 network 驱动成功。注意将虚机重启从而使得安装生效。 (3)诡异的问题 通过上面方法得到的 Win7 raw 格式的镜像文件可以直接使用来创建新的虚机,这些新的虚机会使用 virtio network driver。 但是,在 OpenStack 环境和中,Nova 首先将 qcow2 格式的镜像从glance 中下载到计算节点上,然后将它转化为 raw 格式作为 backfing file,再创建一个 qcow2 文件,它使用 raw 文件作为 backing file。如下图所示: root@linuxkvm1:/home/s1# qemu-img info /var/lib/nova/instances/1d157798-848d-4dc0-9663-7343083ec943/disk image: /var/lib/nova/instances/1d157798-848d-4dc0-9663-7343083ec943/disk file format: qcow2 virtual size: 30G (32212254720 bytes) disk size: 1.3G cluster_size: 65536 backing file: /var/lib/nova/instances/_base/d074d3233a25bf3d10fdc4915e2c7913aebf39ee Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false root@linuxkvm1:/home/s1# qemu-img info /var/lib/nova/instances/_base/d074d3233a25bf3d10fdc4915e2c7913aebf39ee image: /var/lib/nova/instances/_base/d074d3233a25bf3d10fdc4915e2c7913aebf39ee file format: raw virtual size: 30G (32212254720 bytes) disk size: 7.1G 诡异的是,OpenStack 中新建的虚机不能使用 virtio network driver: 但是, 如果使用backing file 直接启动虚机,则没有这个问题。 使用同样的 backing file 创建一个新的 qcow2 文件,则没有这个问题 具体原因应该和 Nova 的具体逻辑有关,将来再查,现在暂时使用 SCSI network driver。 参考文档: https://pve.proxmox.com/wiki/Windows_7_guest_best_practices 本文转自SammyLiu博客园博客,原文链接:http://www.cnblogs.com/sammyliu/p/5740129.html ,如需转载请自行联系原作者

优秀的个人博客,低调大师

虚拟化实战】容灾设计之一设计方法

作者:范军 (Frank Fan) 新浪微博:@frankfan7 在容灾设计中需要有个清晰的思路,能帮助我们既能考虑大局,又能照顾到细节。以商业需求为主导是必须的,而不是一上来就谈某个产品的具体功能。我总结了以下三个步骤: 一深入了解商业需求 上图列出了一些Business Parameters。摘自此文。 我们着重谈其中的的几个要素: RTO(recovery time objective):灾难发生后要求在该时间内能恢复应用。 RPO(Recoverypoint objective):灾难发生后可以容忍数据的丢失的时间段。 理论上讲当然容灾方案支持RTO和RPO越小越好,但千万不能因为单纯追求最小值,而造成不必要高成本,也就是所说的OverEngineering。好的架构师应该从客户角度着想,提供满足需求的方案。 在和客户沟通的时候,一定要打破沙锅问到底,RTO和RPO的值是怎么来的?很多时候会发现没有人能说清楚。这就需要从应用上着手。比如有的应用自身已经实现了高可用性,比如MSCluster, LVS等等,支持该应用的Infrastructure不必过分考虑容灾。很多时候Hypervisor自己HA就能够满足了。 Risk 从严重程度(Severity)和可能性(likehood)来考虑。比如金融机构对此要求非常高,我的一个客户是无法接受因为系统宕机而造成的巨大损失。所以他们对风险评估后要求ZeroRTO和Zero RPO。 二 考虑影响关键架构设计的因素(Architecture Decisions) Site: Local:有的容灾方案在本地实施就能满足客户需求 Dedicated DR Sites:是否需要专门的DRSite,是由公司的IT战略和持续发展来决定的。当然成本上的影响很大。 Shared DR Site:共享的DR Site出了容灾外,可能也有其他用处。 Cloud Based Recovery:可以考虑云服务商的容灾方案。比如VMware混合云(vCHS)最近推出了专门针对容灾的方案。 StorageReplication Software:完全使用软件实现数据同步,不依赖SANReplication。 SAN based:大多数高端存储设备自身支持SANBased的Replication。如果有很特别的需要,也可以借助软件来实现高级的SANReplication。比如EMC Recovery Point. 数据中心之间的网络 DR dedicated:完全是为DR专有的 MPLS:公用的。 根据带宽和同步的数据量来衡量该容灾方案是否能满足RTO和RPO需要 三 评估适合的产品(Product Mapping) 市场上的容灾产品和方案非常多。我们需要问自己一系列的问题,列出需要满足的Feature,然后再针对每个产品来评估各项指标。 方法一: 大概评估几个大的方面 比如 RTO,RPO,Cost,Flexibility,Managability 等等。 方法二 : 细致评估 产品1 产品2 需求1 Y Y 需求2 N Y 参考: Disaster Prevention and Recovery Architecture from RMI DRBC Design- Disaster Recovery and Business Continuity Fundamentals 本文转自frankfan751CTO博客,原文链接:http://blog.51cto.com/frankfan/1288884,如需转载请自行联系原作者

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能,例如代码缩略图,Python的插件,代码段等。还可自定义键绑定,菜单和工具栏。Sublime Text 的主要功能包括:拼写检查,书签,完整的 Python API , Goto 功能,即时项目切换,多选择,多窗口等等。Sublime Text 是一个跨平台的编辑器,同时支持Windows、Linux、Mac OS X等操作系统。

WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源,继承了IntelliJ IDEA强大的JS部分的功能。

用户登录
用户注册