Do not really understand openstack: 50 steps and 100 knowledge points for Virtual Machine creation (3)

Iv. Nova-compute

Step 17: After receiving the request from Nova-compute, use resource tracker to declare the occupation of resources required for creating the Virtual Machine. Step 18: Call the neutron API to configure the network. The virtual machine is in the networking state.

It should be noted that although this step is to configure the network, it is mainly to prepare the data structure, and the real device is not created.

When creating a virtual machine, we specify the private network to which the virtual machine is stored. Therefore, before creating a real device, all the information must be prepared.

The knowledge points here are designed to create a network. However, this step should be completed before the virtual machine is created.

The simplest scenario is to use the following script to create a network.

#! /Bin/bash
Tenant_name = "openstack"
Tenant_network_name = "openstack-Net"
Tenant_subnet_name = "$ {tenant_network_name}-subnet"
Tenant_router_name = "openstack-router"
Fixed_range = "192.168.0.0/24"
Network_gateway = "192.168.0.1"

Public_gateway = "172.24.1.1"
Public_range = "172.24.1.0/24"
Public_start = "172.24.1.100"
Public_end = "172.24.1.200"

Tenant_id = $ (keystone tenant-list | grep "$ tenant_name" | awk '{print $2 }')

(1) tenant_net_id = $ (neutron net-create -- tenant_id $ tenant_network_name -- provider: network_type gre -- provider: segmentation_id 1 | grep "ID" | awk '{print $4 }')

(2) topology = $ (neutron subnet-create -- tenant_id $ tenant_id -- ip_version 4 -- name $ tenant_subnet_name $ tenant_net_id $ fixed_range -- gateway $ network_gateway -- topology list = true 8.8.8.8.8 | grep "ID" | '{print $4 }')

(3) router_id = $ (neutron router-create -- tenant_id $ tenant_router_name | grep "ID" | awk '{print $4 }')

(4) neutron router-interface-add $ router_id $ tenant_subnet_id

(5) neutron net-create public -- router: External = true

(6) neutron subnet-create -- ip_version 4 -- gateway $ public_gateway public $ public_range -- Allocation-pool start = $ public_start, end = $ public_end -- disable-DHCP -- name public-Subnet

(7) neutron router-gateway-set $ {tenant_router_name} public

1. Create a private network for this tenant. Different private networks need to be isolated through VLAN tagging, and the broadcast cannot reach each other. Here we use the GRE mode, you also need something similar to a vlan id, called a segment ID.
2. Create a subnet for a private network. subnet is the place where the IP network segment is actually configured. For a private network, we often use the CIDR Block 192.168.0.0/24.
3. Create a router for this tenant to access the Internet
4. Connect the private network to the router
5. Create an external network
6. Create an exernal network subnet, which logically represents the physical network of our data center. Through this physical network, we can access the Internet. Therefore, public_gateway should be set as the gateway in the data center, and public_range should also be consistent with the CIDR of the physical network of the data center. Otherwise, the connection will fail, and the public_start and public_end should be set, it is because in the data center, it is impossible for all IP addresses to be used by openstack. In addition, VMWare vcenter may be set up, and there may be physical machines. Only one interval is allocated to openstack for use.
7. Connect the router to the external network

After this process, the physical network is connected logically from the virtual network to the physical network.

However, the actual creation of the underlying device is based on specific commands. I have summarized the following:

Commands executed by neutron to create a network

Of course, there are more complex scenarios. Refer to this article.

Multiple routers and multiple networks

Step 19: Generate MAC address step 20: Obtain DHCP server configuration step 21: Get network information step 22: Get security group information Step 23: hold all information, creating a port object is a tap device. Of course, the real device has not been created Step 24: Call libvirt driver to create a virtual machine.

Before creating an instance, you certainly need an image, which was later discovered to be a university question.

In openstack, the image format applied to KVM is mainly raw and qcow2,

The raw format is simple and easy to convert to other formats. Sparse file can be supported only by the file system, and the performance is relatively high.

Qcow2 is dynamic and has the following advantages over raw:

• Even if the file system does not support sparse file, the file size is small.
• Copy on write
• Snapshot
• Compression
• Encryption

For specific formats and features, refer to the following article

Qemu KVM libvirt Manual (4)-Images

[Convert] The qcow2 image format

You can create an image in multiple ways.

One way is to use virt-install to set hard disk as an image file, start a virtual machine from CDROM, follow the normal installation process, and finally install the operating system, the image is then processed and compressed by qemu-IMG to form an image.

References

Qemu KVM libvirt Manual (1)

Of course, the more advanced method is libguestfs, which allows you to easily create an image based on an existing image version, that is, virt-builder.

References

Libguestfs Manual (3): virt command

Of course, an image that can be used in openstack is not as simple as installing an operating system.

The openstack virtual machine image Guide describes the requirements of a Linux image.

• Disk Partitions and resize root partition on boot (cloud-init)
• No hard-coded MAC address information
• Ensure SSH server runs
• Disable Firewall
• Access instance by using SSH Public Key (cloud-init)
• Use cloud-init to fetch the Public Key
• Process user data and other metadata (cloud-init)
• Ensure image writes boot log to console

Add several more:

• Contains MBR and bootloader, which can be started automatically
• Support for virtio disk and Network Driver
• Use DHCP to assign IP addresses

After a Linux image is installed, you must test it:

• Can I use key SSH?
• Can I inject files?
• Whether cloud-init is running
• Is the file system resize flavor?
• Is hostname set to the file name?
• Is timezone correct?
• /Etc/fstab clean and correct?
• Is the log of the Virtual Machine correctly output?
• /Tmp path clean?
• Can I use snapshot?
• Can I see and use block storage after it is added?

Windows images are much more complicated. Windows is really not cloud-friendly.

• First, you must use virt-install to install windows.
• To use virtio for Windows, you must install virtio for Windows. Update the driver in Device Manager even after installation.
• Remote Access should be enabled, or remote desktop.
• Install an SSH server. Sometimes you need to create a virtual machine and automatically execute scripts to install things. Remote Desktop cannot be used.
• Install cloud-init cloudbase-init for Windows
• Do not forget to run Windows Update to update Windows. Otherwise, there will be many security vulnerabilities.
• Add a serial console device to Device Manager.
• Windows hard disks usually occupy a lot. Run the disk cleanup tool to clear some hard disks.
• Microsoft has an sdelete tool that allows you to compress hard disks by setting the unallocated space to 0.
• Don't forget the license issue.
• When you configure the network in windows, a dialog box is displayed. Is this a home network, a work network, or a public network? This will cause the network configuration to die and kill it in the registry.
• Run sysprep

For cloud-init, refer to the following article

Http://cloudinit.readthedocs.org/en/latest/index.html

Http://www.scalehorizontally.com/2013/02/24/introduction-to-cloud-init/

In ubuntu, cloud-init mainly includes

The configuration file is under/etc/cloud. The default cloud. cfg is as follows:

[Email protected]:/etc/cloud # Cat cloud. cfg
# The top level settings are used as module
# And system configuration.

# A set of users which may be applied and/or used by various modules
# When a 'default' entry is found it will reference the 'default _ user'
# From the distro configuration specified below
Users:
-Default

# If this is set, 'root' will not be able to SSH in and they
# Will get a message to login instead as the above $ user (UBUNTU)
Disable_root: True

# This will cause the set + update hostname module to not operate (if true)
Preserve_hostname: false

# Example datasource config
# Datasource:
# EC2:
# Metadata_urls: ['blah.com ']
# Timeout: 5 # (defaults to 50 seconds)
# Max_wait: 10 # (defaults to 120 seconds)

# The modules that run in the 'init 'stage
Cloud_init_modules:
-Migrator
-Seed_random
-Bootcmd
-Write-Files
-Growpart
-Resizefs
-Set_hostname
-Update_hostname
-Update_etc_hosts
-Ca-Certs
-Rsyslog
-Users-groups
-Ssh

# The modules that run in the 'config' stage
Cloud_config_modules:
# Emit the cloud config ready event
# This can be used by upstart jobs for 'start on cloud-config '.
-Emit_upstart
-Disk_setup
-Mounts
-Ssh-import-ID
-Locale
-Set-passwords
-Grub-dpkg
-Apt-pipelining
-Apt-configure
-Package-Update-upgrade-install
-Landscape
-Timezone
-Puppet
-Chef
-Salt-minion
-Mcollective
Disable-ec2-metadata
-Runcmd
-Byobu

# The modules that run in the 'final' stage
Cloud_final_modules:
-Rightscale_userdata
-Scripts-vendor
-Scripts-per-once
-Scripts-per-boot
-Scripts-per-instance
-Scripts-user
-Ssh-authkey-fingerprints
-Keys-to-Console
-Phone-home
-Final-message
-Power-state-change

# System and/or distro specific settings
# (Not accessible to handlers/transforms)
System_info:
# This will affect which distro class gets used
Distro: Ubuntu
# Default User Name + that default users groups (if added/used)
Default_user:
Name: Ubuntu
Lock_passwd: True
GECOS: Ubuntu
Groups: [ADM, audio, CDROM, dialout, dip, floppy, netdev, plugdev, sudo, Video]
Sudo: ["All = (all) nopasswd: All"]
Shell:/bin/bash
# Other config here will be given to the distro class and/or path classes
Paths:
Cloud_dir:/var/lib/cloud/
Templates_dir:/etc/cloud/templates/
Upstart_dir:/etc/init/
Package_mirrors:
-Arches: [i386, amd64]
Failsafe:
Primary: http://archive.ubuntu.com/ubuntu
Security: http://security.ubuntu.com/ubuntu
Search:
Primary:
-Http: // % (ec2_region) s.ec2.archive.ubuntu.com/ubuntu/
-Http: // % (availability_zone) s.clouds.archive.ubuntu.com/ubuntu/
Security: []
-Arches: [armhf, Armel, default]
Failsafe:
Primary: http://ports.ubuntu.com/ubuntu-ports
Security: http://ports.ubuntu.com/ubuntu-ports
Ssh_svcname: SSH

The working folder is in/var/lib/cloud.

[Email protected]:/var/lib/cloud/instance # ls
Boot-finished datasource obj. pkl sem user-data.txt. I vendor-data.txt. I
Cloud-config.txt handlers scripts user-data.txt vendor-data.txt

The cloud-init command

/Usr/bin/cloud-init

If we open it and find it is a python file, if we run/usr/bin/cloud-init, cloud_init_modules will be run: The following module, we use resizefs as an Example

/Usr/bin/cloud-init will call main_init, which will call run_module_section

This is called to the Python code, so the other part of cloud-init is the Python code part.

/Usr/lib/python2.7/dist-packages/cloudinit

We found this file/usr/lib/python2.7/dist-packages/cloudinit/config/cc_resizefs.py.

Which is

Def _ resize_btrfs (mount_point, devpth): # pylint: Disable = w0613
Return ('btrfs', 'filesystem', 'resize', 'max ', mount_point)

Def _ resize_ext (mount_point, devpth): # pylint: Disable = w0613
Return ('resize2fs', devpth)

Def _ resize_xfs (mount_point, devpth): # pylint: Disable = w0613
Return ('xfs _ growfs', devpth)

Def _ resize_ufs (mount_point, devpth): # pylint: Disable = w0613
Return ('growfs', devpth)

Haha, I finally found the root cause of resize.

After creating an image, you also need to know how to modify the image. Our file injection is to modify the image.

There are three methods: mount a loop device, use the network block Device of qemu, or use libguestfs

Summarized into an article

How to modify an image file

For qemu-NBD, there are articles

Qemu KVM libvirt Manual (6)-network block Device

For libguestfs, I also wrote some notes

 

Libguestfs Manual (1): Architecture

Libguestfs Manual (2): guestfish command

Libguestfs Manual (3): virt command

For file injection, there are articles

Nova file injection

There are many articles on how to take a snapshot

Qemu KVM libvirt Manual (5)-snapshots

Snapshot types

External snapshot Management

[Convert] external (and live) snapshots with libvirt

[Convert] snapshow.libvirt for qcow2 Images

Step 26: Download the image from glance as the base Step 27: Create a qcow2 Image Based on the base image. Step 28: resize the image size, regardless of the filesystem size. Step 29: configure configuration drive step 30: configure file injection

Do not really understand openstack: 50 steps and 100 knowledge points for Virtual Machine creation (3)