nova命令管理虚拟机: $ nova list #查看虚拟机$ nova stop [vm-name]或[vm-id] #关闭虚拟机$ nova start [vm-name]或[vm-id] #启动虚拟机$ nova suspend [vm-name]或[vm-id] #暂停虚拟机$ nova resume [vm-name]或[vm-id] #启动暂停的虚拟机$ nova delete [vm-name]或[vm-id] #删除虚拟机

欢迎各位关注我的博客:http://weibo.com/u/216633637 废话开头: 之前参考这位同学的博客http://www.cnblogs.com/awy-blog/p/3447176.html,同时综合OpenStack的ubuntu的官方安装文档,在修改了一些小错误之后,成功地用三台普通的物理PC机搭了一个OpenStack的环境,各项服务.功能都测试了一遍,感觉还可以.不过后来,由于其中的一台物理机被别人拿走之后,于是乎没继续使用测试了,转而去研究代码了. 后来,由于某种需求,

本文梳理一下 Nova 主要操作的流程. 0. Nova REST-CLI-Horizon 操作对照表 Nova 基本的 CRUD 操作和 extensions: # 类别 Nova V2 REST API Action Nova CLI Horizon 解释   虚机操作 POST boot Launch Instance 启动一个新的虚机 http://www.cnblogs.com/sammyliu/p/4558638.html     DELETE delete Terminate In

nova start 虚机的代码流程分析,以ocata版本为分析基础1.nova api服务接受用户下发的 nova start启动虚机请求其对应的http restfull api接口为post /servers/{server_id}/action发送的action为os-start nova/api/openstack/compute/servers.py class ServersController(wsgi.Controller): def _start_server(self, r

和物理机一样,虚拟机包括几个重要的部分:CPU.内存.磁盘设备.网络设备等.本文将简要总结虚机磁盘设备有关知识. 1. Nova boot CLI 中有关虚机块设备的几个参数 nova boot CLI 的完整参数如下: usage: nova boot [--flavor <flavor>] [--image <image>] //boot from image with id [--image-with <key=value>] //image metadata p

在XenServer中,碰到VM挂起(hang)的情况,也不是那么少见,而VM长时间挂起,那么很影响心情和后续的操作. 一般情况下,为了关闭VM或者重启VM,我们推荐这样的操作顺序: 进入到VM内,使用系统的关机或者重启功能通过XenCenter的菜单选择ShutDown或者Restart.虽然这个菜单的实现是通过XenServer tool来控制系统的命令来实现,但是不保证在XenServer Tools工作异常的情况下,导致VM挂起(Hang),而且,这个应该也是VM挂起(XenCenter

前言        Openstack作为一个虚拟机管理平台,核心功能自然是虚拟机的生命周期的管理,而负责虚机管理的模块就是Nova. 本文就是openstack中Nova模块的分析,所以本文重点是以下三点:   先了解Openstack的整体架构,搞清楚为什么要用这样的架构: 然后再了解架构中的各个组件,组件提供的主要功能与各个组件之间的交互: 了解虚机的启动过程,能在遇到问题时发现问题出在哪个模块中的哪个组件.   Nova组件介绍 接下来进行详细介绍,如有错误,欢迎拍砖! 下图为创建虚拟机

和物理机一样,虚拟机包括几个重要的部分:CPU.内存.磁盘设备.网络设备等.本文将简要总结虚机磁盘设备有关知识. 1. Nova boot CLI 中有关虚机块设备的几个参数 nova boot CLI 的完整参数如下: usage: nova boot [--flavor <flavor>] [--image <image>] //boot from image with id [--image-with <key=value>] //image metadata p

参考链接:https://www.cnblogs.com/storymedia/p/4500186.html 1.nova 创建的虚机后端目录 其中的base是虚机基础镜像,创建虚机会根据这个基础镜像进行派生镜像,命令如下: qemu-img create -f qcow2 -o backing_file=/var/lib/nova/ instances/_base/1406c8d8631815b4e071939654c4d1cbc79c9ec3 查看镜像信息: disk格式是QEMU QCOW

宿主机调整 1. 关闭虚机, 2. 检查是否有存在的snapshot, 如果有, 需要删除, 否则不能调整磁盘容量 3. 虚机上编辑配置, 将磁盘容量调大后保存 虚机调整 参考这篇写得非常详细: 点击查看   To extend the logical volume: Note: These steps only apply to EXT3 file systems.   Caution: VMware recommends having a complete backup of the vir

原文链接:https://www.cnblogs.com/potato-chip/p/9127083.html OpenStack虚机网卡的创建过程 OpenStack最基本和常用的操作就是启动虚机.虚机启动的过程中涉及很多内容,其中非常重要的一个环节就是创建并绑定虚机的虚拟网卡.虚机的创建和管理是Nova的任务,虚机网络的创建和管理是Neutron的任务,而虚机网卡,作为连接虚机和虚机网络的桥梁,其创建和管理则同时涉及了Nova和Neutron 1.Neutron L2 Agent上线 首先是

OpenStack虚机网卡的创建过程 OpenStack最基本和常用的操作就是启动虚机.虚机启动的过程中涉及很多内容,其中非常重要的一个环节就是创建并绑定虚机的虚拟网卡.虚机的创建和管理是Nova的任务,虚机网络的创建和管理是Neutron的任务,而虚机网卡,作为连接虚机和虚机网络的桥梁,其创建和管理则同时涉及了Nova和Neutron 1.Neutron L2 Agent上线 首先是所有的服务上线,看neutron-openvswitch-agent的启动OpenVSwitch agent 启

1)关闭虚机# virsh  shutdown  vm1 2)编辑虚机配置文件# virsh  edit  vm1 <interface type='default'> 改为<interface type='bridge'>      <mac address='52:54:00:50:58:7e'/>      <source network='default'/>    改为<source bridge='br0'/>      <mo

背景: 生产环境下,发现windows虚机每次重启,时间都会倒退到虚机的格林威治时间(+8小时才是北京时间),也就是比当前时间晚8小时.测试发现,windows虚机所用的镜像,缺少了一个os_type参数. 制作镜像时,必须加入os_distro.image.os_type.os_type这三个参数.三个参数的作用如下: os_distro:os_dstro是镜像的发行版名称,也就是帮助识别它具体是什么操作系统的,这个参数可以填centos.debian.ubuntu等等具体的名字: image

Ubuntu Cloud Images Ubuntu官网会给各种公有云平台提供cloud镜像, 例如AWS, MS Azure, Google Cloud, 以及本地虚机环境例如 QEMU, VMware, Vagrant等, 这些镜像在 https://cloud-images.ubuntu.com 上可以下载. Ubuntu Cloud 镜像类型 cloud-images.ubuntu.com 上面的镜像主要可以分成两大类, daily 和 release, 每个大类里又区分为 minima

学习 Neutron 系列文章: (1)Neutron 所实现的虚拟化网络 (2)Neutron OpenvSwitch + VLAN 虚拟网络 (3)Neutron OpenvSwitch + GRE/VxLAN 虚拟网络 (4)Neutron OVS OpenFlow 流表 和 L2 Population (5)Neutron DHCP Agent (6)Neutron L3 Agent (7)Neutron LBaas (8)Neutron Security Group (9)Neutro

学习 KVM 的系列文章: (1)介绍和安装 (2)CPU 和 内存虚拟化 (3)I/O QEMU 全虚拟化和准虚拟化(Para-virtulizaiton) (4)I/O PCI/PCIe设备直接分配和 SR-IOV (5)libvirt 介绍 (6)Nova 通过 libvirt 管理 QEMU/KVM 虚机 (7)快照 (snapshot) (8)迁移 (migration) 1. QEMU/KVM 迁移的概念 迁移(migration)包括系统整体的迁移和某个工作负载的迁移.系统整理迁移

1. QEMU/KVM 迁移的概念 迁移(migration)包括系统整体的迁移和某个工作负载的迁移.系统整理迁移,是将系统上所有软件包括操作系统完全复制到另一个物理机硬件机器上.虚拟化环境中的迁移,可分为静态迁移(static migration,或者 冷迁移 cold migration,或者离线迁移 offline migration) 和 动态迁移 (live migration,或者 热迁移 hot migration 或者 在线迁移 online migration).静态迁移和动态

学习 Neutron 系列文章: (1)Neutron 所实现的虚拟化网络 (2)Neutron OpenvSwitch + VLAN 虚拟网络 (3)Neutron OpenvSwitch + GRE/VxLAN 虚拟网络 (4)Neutron OVS OpenFlow 流表 和 L2 Population (5)Neutron DHCP Agent (6)Neutron L3 Agent (7)Neutron LBaas (8)Neutron Security Group (9)Neutro

本系列会介绍OpenStack 企业私有云的几个需求: 自动扩展(Auto-scaling)支持 多租户和租户隔离 (multi-tenancy and tenancy isolation) 混合云(Hybrid cloud)支持 主流硬件支持.云快速交付 和 SLA 保证 大规模扩展性支持 私有云外围环境支持(包括支持CDN .商业SDN控制器.防火墙和VPN/专线等) 良好的可使用性(用户和运维 Dashboard 等) 向上扩展性(PaaS 和 SaaS 等支撑) 企业数据中心IT环境支持

学习 KVM 的系列文章: (1)介绍和安装 (2)CPU 和 内存虚拟化 (3)I/O QEMU 全虚拟化和准虚拟化(Para-virtulizaiton) (4)I/O PCI/PCIe设备直接分配和 SR-IOV (5)libvirt 介绍 (6)Nova 通过 libvirt 管理 QEMU/KVM 虚机 (7)快照 (snapshot) (8)迁移 (migration) 1. Libvirt 在 OpenStack 架构中的位置 在 Nova Compute 节点上运行的 nova-