前言：
当neutron-server创建了port信息，将port信息写入数据库中。流程返回到nova服务端，接着nova创建的流程继续走。在计算节点中neutron-agent同样要完成很多的工作来支持主机的通信。
简要流程：
详细代码分析：
spawn()作用：
- 准备磁盘信息
- 获取镜像的获取路径
- 准备启动xml文件
- 创建主机和网络，调用create_domain_and_network()函数获取网络信息。
准备启动xml文件的过程稍后有详细分析。
create_domin_and_network()
作用：
创建虚拟机过程中neutron工作主要体现的地方，详细的说明在下面的截图中。主要的工作是创建调用底层驱动libvirt创建虚拟机。
-------------------------------------------------------------------------------------------------nova创建xml文件-------------------------------------------------------------------------
xml文件如下所示，其中定义了主机必要信息如mac地址，内核，磁盘，分区信息，网卡等。
<domain type='qemu' id=''>
<name>instance-</name>
<uuid>8d812f63-573c-4f2c-a991-dfa68b844d20</uuid>
<metadata>
<nova:instance xmlns:nova="http://openstack.org/xmlns/libvirt/nova/1.0">
<nova:package version="13.1.0-1.el7"/>
<nova:name>myInstanceWithVolume</nova:name>
<nova:creationTime>-- ::</nova:creationTime>
<nova:flavor name="m1.small">
<nova:memory></nova:memory>
<nova:disk></nova:disk>
<nova:swap></nova:swap>
<nova:ephemeral></nova:ephemeral>
<nova:vcpus></nova:vcpus>
</nova:flavor>
<nova:owner>
<nova:user uuid="6383b14b190d422ab3079e4e63c62e16">demo</nova:user>
<nova:project uuid="478a18506673406db8abc360cdc2f202">demo</nova:project>
</nova:owner>
<nova:root type="image" uuid="9bf97139-7760-4ace-b3d1-5bcd0ff30f55"/>
</nova:instance>
</metadata>
<memory unit='KiB'></memory>
<currentMemory unit='KiB'></currentMemory>
<vcpu placement='static'></vcpu>
<cputune>
<shares></shares>
</cputune>
<resource>
<partition>/machine</partition>
</resource>
<sysinfo type='smbios'>
<system>
<entry name='manufacturer'>Fedora Project</entry>
<entry name='product'>OpenStack Nova</entry>
<entry name='version'>13.1.-.el7</entry>
<entry name='serial'>acb2b380-0bb5--f93d-107563ca227e</entry>
<entry name='uuid'>8d812f63-573c-4f2c-a991-dfa68b844d20</entry>
<entry name='family'>Virtual Machine</entry>
</system>
</sysinfo>
<os>
<type arch='x86_64' machine='pc-i440fx-rhel7.0.0'>hvm</type>
<boot dev='hd'/>
<smbios mode='sysinfo'/>
</os>
<features>
<acpi/>
<apic/>
</features>
<cpu mode='host-model'>
<model fallback='allow'/>
<topology sockets='' cores='' threads=''/>
</cpu>
<clock offset='utc'/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>destroy</on_crash>
<devices>
<emulator>/usr/libexec/qemu-kvm</emulator>
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2' cache='none'/>
<source file='/var/lib/nova/instances/8d812f63-573c-4f2c-a991-dfa68b844d20/disk'/>
<backingStore type='file' index=''>
<format type='raw'/>
<source file='/var/lib/nova/instances/_base/86f82a7c75893f6ce52678cc7f7991aecc4aa9aa'/>
<backingStore/>
</backingStore>
<target dev='vda' bus='virtio'/>
<alias name='virtio-disk0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</disk>
<disk type='block' device='disk'>
<driver name='qemu' type='raw' cache='none' io='native'/>
<source dev='/dev/disk/by-path/ip-192.168.8.8:3260-iscsi-iqn.2010-10.org.openstack:volume-13db53ea-475b-471d-bbb1-a0daffbf25ef-lun-0'/>
<backingStore/>
<target dev='vdb' bus='virtio'/>
<serial>13db53ea-475b-471d-bbb1-a0daffbf25ef</serial>
<alias name='virtio-disk1'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</disk>
<controller type='usb' index=''>
<alias name='usb'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>
</controller>
<controller type='pci' index='' model='pci-root'>
<alias name='pci.0'/>
</controller>
<serial type='file'>
<source path='/var/lib/nova/instances/8d812f63-573c-4f2c-a991-dfa68b844d20/console.log'/>
<target port=''/>
<alias name='serial0'/>
</serial>
<serial type='pty'>
<source path='/dev/pts/3'/>
<target port=''/>
<alias name='serial1'/>
</serial>
<console type='file'>
<source path='/var/lib/nova/instances/8d812f63-573c-4f2c-a991-dfa68b844d20/console.log'/>
<target type='serial' port=''/>
<alias name='serial0'/>
</console>
<input type='tablet' bus='usb'>
<alias name='input0'/>
</input>
<input type='mouse' bus='ps2'/>
<input type='keyboard' bus='ps2'/>
<graphics type='vnc' port='' autoport='yes' listen='0.0.0.0' keymap='en-us'>
<listen type='address' address='0.0.0.0'/>
</graphics>
<video>
<model type='cirrus' vram='' heads=''/>
<alias name='video0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
</video>
<memballoon model='virtio'>
<stats period=''/>
<alias name='balloon0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
</memballoon>
</devices>
</domain>
spawn()
作用：
调用get_guest_xml()函数创建生成虚拟机的xml文件。
get_guest_xml()
作用：
- 获取xml文件需要的信息，有网络信息，磁盘信息，镜像元数据等。
- 调用get_guest_config()函数进一步生成xml
get_guest_config()
作用：
- 调用libvirt驱动层函数生成一个guest变量，或者说是对象。
- 向guest对象中填充各种信息
- 调用driver.get_config()函数生成tap设备
get_config()
作用：
生成tap设备。
tap设备解释（经典）：
tap是linux虚拟出来的设备，表现为一个字符设备，用户可以通过对该设备读写，实现数据交互。
tun/tap 驱动程序实现了虚拟网卡的功能，tun表示虚拟的是点对点设备，tap表示虚拟的是以太网设备，这两种设备针对网络包实施不同的封装。
利用tun/tap 驱动，可以将tcp/ip协议栈处理好的网络分包传给任何一个使用tun/tap驱动的进程，由进程重新处理后再发到物理链路中。做为虚拟
网卡驱动，Tun/Tap驱动程序的数据接收和发送并不直接和真实网卡打交道，他在Linux内核中添加了一个TUN/TAP虚拟网络设备的驱动程序和
一个与之相关连的字符设备 /dev/net/tun，字符设备tun作为用户空间和内核空间交换数据的接口。当内核将数据包发送到虚拟网络设备时，数据
包被保存在设备相关的一个队列中，直到用户空间程序通过打开的字符设备tun的描述符读取时，它才会被拷贝到用户空间的缓冲区中，其效果
就相当于，数据包直接发送到了用户空间。通过系统调用write发送数据包时其原理与此类似。
在linux下，要实现内核空间和用户空间数据的交互，有多种方式：
1 可以通用socket创建特殊套接字，利用套接字实现数据交互；
2 通过proc文件系统创建文件来进行数据交互；
3 还可以使用设备文件的方式。访问设备文件会调用设备驱动相应的例程，设备驱动本身就是内核空间和用户空间的一个接口，
Tun/tap驱动就是利用设备文件实现用户空间和内核空间的数据交互。
get_config_bridge()
作用：
生成网桥设备