[OpenStack (Train version) installation and deployment] win7 virtual machine creation, specified volume production, Mount test

This article is published by the public account [development pigeon]! Welcome to pay attention!!! Old rules - sister to...
This article is published by the public account [development pigeon]! Welcome to pay attention!!!
1. win7 virtual machine test in grace

This article is published by the public account [development pigeon]! Welcome to pay attention!!!


Old rules - sister town building:

1. win7 virtual machine test in grace

(1) - failed to upload the image in qcow2 format of win7 glance

        Upload the created qcow2 format image to the Controller node:

        Upload the image in qcow2 format to grace:

        Upload qcow2 format image:

glance image-create --name "win7_xshell_qcow2" --file /vhost/win7_xshell.qcow2 --disk-format qcow2 --container-format bare --visibility public --progress

        To view the mirror image in the current Grace:

        View the image in the image directory of the default Grace:

        / The image image in the var / lib / Grace / images directory has been uploaded:



(2) - failed - win7 virtual machine creation test (dashboard graphical)

        ERROR occurred while creating virtual machine test in dashboard:

        The following error occurred in nova-scheduler.log:

2021-09-29 15:56:26.588 6701 ERROR nova NoMatches: No 'nova.scheduler.driver' driver found, looking for 'nova.scheduler.filterscheduler.FilterScheduler' 2021-09-29 15:56:26.588 6701 ERROR nova 2021-09-29 15:56:29.204 6741 WARNING oslo_config.cfg [-] Deprecated: Option "scheduler_driver" from group "DEFAULT" is deprecated. Use option "driver" from group "scheduler". 2021-09-29 15:56:29.204 6741 WARNING stevedore.named [-] Could not load nova.scheduler.filterscheduler.FilterScheduler 2021-09-29 15:56:29.205 6741 CRITICAL nova [-] Unhandled error: NoMatches: No 'nova.scheduler.driver' driver found, looking for 'nova.scheduler.filterscheduler.FilterScheduler'

        Delete all filter configurations in the nova.conf configuration file:

scheduler_driver=nova.scheduler.filterscheduler.FilterScheduler scheduler_available_filters = nova.scheduler.filters.all_filters scheduler_default_filters = AvailabilityZoneFilter, RamFilter, DiskFilter, ComputeFilter

        Re create the virtual machine test in the dashboard. The creation fails again. Let's start viewing the log:

        Check that there is no error in nova-api.log;

        View the nova-compute.log log:

#Instance declaration succeeded 2021-09-29 16:34:30.917 2032 INFO nova.compute.claims [req-ce75f8ce-65b5-4266-acca-e6cf8be864ab 9942eb4321644336a0c7383d9f1c2bed a7d812868cb74f1a978035530f55f1d0 - default default] [instance: 6ddd4885-6134-48ef-b5b4-17804346cb05] Claim successful on node computer 2021-09-29 16:34:31.179 2032 INFO nova.virt.libvirt.driver [req-ce75f8ce-65b5-4266-acca-e6cf8be864ab 9942eb4321644336a0c7383d9f1c2bed a7d812868cb74f1a978035530f55f1d0 - default default] [instance: 6ddd4885-6134-48ef-b5b4-17804346cb05] Ignoring supplied device name: /dev/vda. Libvirt can't honour user-supplied dev names #Start through the previously uploaded qcow2 format image of win7 2021-09-29 16:34:31.309 2032 INFO nova.virt.block_device [req-ce75f8ce-65b5-4266-acca-e6cf8be864ab 9942eb4321644336a0c7383d9f1c2bed a7d812868cb74f1a978035530f55f1d0 - default default] [instance: 6ddd4885-6134-48ef-b5b4-17804346cb05] Booting with volume-backed-image d5fde846-32c9-46d7-9132-20a92e72fa90 at /dev/vda #Volume creation failed 2021-09-29 16:34:32.297 2032 WARNING nova.compute.manager [req-ce75f8ce-65b5-4266-acca-e6cf8be864ab 9942eb4321644336a0c7383d9f1c2bed a7d812868cb74f1a978035530f55f1d0 - default default] Volume id: 034374e1-542b-4847-adad-5985b1644744 finished being created but its status is error. #The instance is not mounted to the volume 2021-09-29 16:34:32.472 2032 ERROR nova.compute.manager [req-ce75f8ce-65b5-4266-acca-e6cf8be864ab 9942eb4321644336a0c7383d9f1c2bed a7d812868cb74f1a978035530f55f1d0 - default default] [instance: 6ddd4885-6134-48ef-b5b4-17804346cb05] Instance failed block device setup: VolumeNotCreated: \u5728\u7b49\u5f850 \u79d2\u62161\u5c1d\u8bd5\u540e\uff0c\u5377034374e1-542b-4847-adad-5985b1644744\u4ecd\u7136\u6ca1\u6709\u521b\u5efa\u6210\u529f\u3002\u5b83\u7684\u72b6\u6001\u662ferror\u3002 2021-09-29 16:34:32.472 2032 ERROR nova.compute.manager [instance: 6ddd4885-6134-48ef-b5b4-17804346cb05] Traceback (most recent call last): 2021-09-29 16:34:32.472 2032 ERROR nova.compute.manager [instance: 6ddd4885-6134-48ef-b5b4-17804346cb05] File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 1912, in _prep_block_device 2021-09-29 16:34:32.472 2032 ERROR nova.compute.manager [instance: 6ddd4885-6134-48ef-b5b4-17804346cb05] wait_func=self._await_block_device_map_created) 2021-09-29 16:34:32.472 2032 ERROR nova.compute.manager [instance: 6ddd4885-6134-48ef-b5b4-17804346cb05] File "/usr/lib/python2.7/site-packages/nova/virt/block_device.py", line 882, in attach_block_devices 2021-09-29 16:34:32.472 2032 ERROR nova.compute.manager [instance: 6ddd4885-6134-48ef-b5b4-17804346cb05] _log_and_attach(device) 2021-09-29 16:34:32.472 2032 ERROR nova.compute.manager [instance: 6ddd4885-6134-48ef-b5b4-17804346cb05] File "/usr/lib/python2.7/site-packages/nova/virt/block_device.py", line 879, in _log_and_attach 2021-09-29 16:34:32.472 2032 ERROR nova.compute.manager [instance: 6ddd4885-6134-48ef-b5b4-17804346cb05] bdm.attach(*attach_args, **attach_kwargs) 2021-09-29 16:34:32.472 2032 ERROR nova.compute.manager [instance: 6ddd4885-6134-48ef-b5b4-17804346cb05] File "/usr/lib/python2.7/site-packages/nova/virt/block_device.py", line 769, in attach 2021-09-29 16:34:32.472 2032 ERROR nova.compute.manager [instance: 6ddd4885-6134-48ef-b5b4-17804346cb05] wait_func=wait_func, image_id=self.image_id) 2021-09-29 16:34:32.472 2032 ERROR nova.compute.manager [instance: 6ddd4885-6134-48ef-b5b4-17804346cb05] File "/usr/lib/python2.7/site-packages/nova/virt/block_device.py", line 367, in _create_volume 2021-09-29 16:34:32.472 2032 ERROR nova.compute.manager [instance: 6ddd4885-6134-48ef-b5b4-17804346cb05] self._call_wait_func(context, wait_func, volume_api, vol['id']) 2021-09-29 16:34:32.472 2032 ERROR nova.compute.manager [instance: 6ddd4885-6134-48ef-b5b4-17804346cb05] File "/usr/lib/python2.7/site-packages/nova/virt/block_device.py", line 724, in _call_wait_func 2021-09-29 16:34:32.472 2032 ERROR nova.compute.manager [instance: 6ddd4885-6134-48ef-b5b4-17804346cb05] {'volume_id': volume_id, 'exc': exc}) 2021-09-29 16:34:32.472 2032 ERROR nova.compute.manager [instance: 6ddd4885-6134-48ef-b5b4-17804346cb05] File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__ 2021-09-29 16:34:32.472 2032 ERROR nova.compute.manager [instance: 6ddd4885-6134-48ef-b5b4-17804346cb05] self.force_reraise() 2021-09-29 16:34:32.472 2032 ERROR nova.compute.manager [instance: 6ddd4885-6134-48ef-b5b4-17804346cb05] File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in force_reraise 2021-09-29 16:34:32.472 2032 ERROR nova.compute.manager [instance: 6ddd4885-6134-48ef-b5b4-17804346cb05] six.reraise(self.type_, self.value, self.tb) 2021-09-29 16:34:32.472 2032 ERROR nova.compute.manager [instance: 6ddd4885-6134-48ef-b5b4-17804346cb05] File "/usr/lib/python2.7/site-packages/nova/virt/block_device.py", line 714, in _call_wait_func 2021-09-29 16:34:32.472 2032 ERROR nova.compute.manager [instance: 6ddd4885-6134-48ef-b5b4-17804346cb05] wait_func(context, volume_id) 2021-09-29 16:34:32.472 2032 ERROR nova.compute.manager [instance: 6ddd4885-6134-48ef-b5b4-17804346cb05] File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 1571, in _await_block_device_map_created 2021-09-29 16:34:32.472 2032 ERROR nova.compute.manager [instance: 6ddd4885-6134-48ef-b5b4-17804346cb05] volume_status=volume_status) 2021-09-29 16:34:32.472 2032 ERROR nova.compute.manager [instance: 6ddd4885-6134-48ef-b5b4-17804346cb05] VolumeNotCreated: \u5728\u7b49\u5f850 \u79d2\u62161\u5c1d\u8bd5\u540e\uff0c\u5377034374e1-542b-4847-adad-5985b1644744\u4ecd\u7136\u6ca1\u6709\u521b\u5efa\u6210\u529f\u3002\u5b83\u7684\u72b6\u6001\u662ferror\u3002 2021-09-29 16:34:32.472 2032 ERROR nova.compute.manager [instance: 6ddd4885-6134-48ef-b5b4-17804346cb05] 2021-09-29 16:34:34.396 2032 ERROR nova.compute.manager [req-ce75f8ce-65b5-4266-acca-e6cf8be864ab 9942eb4321644336a0c7383d9f1c2bed a7d812868cb74f1a978035530f55f1d0 - default default] [instance: 6ddd4885-6134-48ef-b5b4-17804346cb05] Example 6 ddd4885-6134-48ef-b5b4-17804346cb05 The build of was aborted: Volume 034374 after waiting 0 seconds or 1 attempt e1-542b-4847-adad-5985b1644744 Still not created successfully. Its state is error. : BuildAbortException: \u5b9e\u4f8b6ddd4885-6134-48ef-b5b4-17804346cb05\u7684\u6784\u5efa\u5df2\u4e2d\u6b62\uff1a\u5728\u7b49\u5f850 \u79d2\u62161\u5c1d\u8bd5\u540e\uff0c\u5377034374e1-542b-4847-adad-5985b1644744\u4ecd\u7136\u6ca1\u6709\u521b\u5efa\u6210\u529f\u3002\u5b83\u7684\u72b6\u6001\u662ferror\u3002 #Remove the virtual IP of the instance 2021-09-29 16:34:34.399 2032 INFO os_vif [req-ce75f8ce-65b5-4266-acca-e6cf8be864ab 9942eb4321644336a0c7383d9f1c2bed a7d812868cb74f1a978035530f55f1d0 - default default] Successfully unplugged vif VIFBridge(active=False,address=fa:16:3e:d0:9b:25,bridge_name='brq9d470a6f-3b',has_traffic_filtering=True,id=1c293d4e-9e15-4cce-887d-0d12d94580b2,network=Network(9d470a6f-3b69-4105-b0eb-f6ef70a9dec3),plugin='linux_bridge',port_profile=<?>,preserve_on_delete=False,vif_name='tap1c293d4e-9e') #Revoke the network assigned by this instance 2021-09-29 16:34:36.226 2032 INFO nova.compute.manager [req-ce75f8ce-65b5-4266-acca-e6cf8be864ab 9942eb4321644336a0c7383d9f1c2bed a7d812868cb74f1a978035530f55f1d0 - default default] [instance: 6ddd4885-6134-48ef-b5b4-17804346cb05] Took 1.83 seconds to deallocate network for instance. 2021-09-29 16:34:36.538 2032 INFO nova.scheduler.client.report [req-ce75f8ce-65b5-4266-acca-e6cf8be864ab 9942eb4321644336a0c7383d9f1c2bed a7d812868cb74f1a978035530f55f1d0 - default default] Deleted allocation for instance 6ddd4885-6134-48ef-b5b4-17804346cb05

        It can be seen from the log that the volume creation failed. It is speculated that the storage space of the compute node is insufficient. Therefore, after deleting a large centos instance, check the resources of the compute node:

        It can be seen that the original set storage space of the compute node is very small (40G). Only 35G is available. Two cirros instances are set. 2G of storage space is used. 8G of memory is set before. Only 7.6G is available and 640MB is used;

        The controller node has a storage space of 40G, only 35G is available, 4G is set, 3.7G is available, and 512MB memory is used.

        Create the virtual machine in the dashboard again, and it is still in the ERROR state. Fuck, continue to view the log:

        Mainly the errors in the nova-compute.log log log in the compute node:

#Volume creation failed 2021-09-29 22:07:28.028 1843 ERROR nova.compute.manager [instance: dc030e38-1ad1-4318-b0df-a3df40daa4ef] VolumeNotCreated: \u5728\u7b49\u5f85132 \u79d2\u621643\u5c1d\u8bd5\u540e\uff0c\u53778e64cc5d-b20c-453e-8886-f57502ff2924\u4ecd\u7136\u6ca1\u6709\u521b\u5efa\u6210\u529f\u3002\u5b83\u7684\u72b6\u6001\u662ferror\u3002 2021-09-29 22:07:28.028 1843 ERROR nova.compute.manager [instance: dc030e38-1ad1-4318-b0df-a3df40daa4ef] #Because the volume creation failed, the instance creation also failed 2021-09-29 22:07:28.143 1843 ERROR nova.compute.manager [req-032b8463-1cc1-43d2-83c1-047b8d50db6e 9942eb4321644336a0c7383d9f1c2bed a7d812868cb74f1a978035530f55f1d0 - default default] [instance: dc030e38-1ad1-4318-b0df-a3df40daa4ef] example dc030e38-1ad1-4318-b0df-a3df40daa4ef The build of was aborted: after waiting 132 seconds or 43 attempts, Volume 8 failed e64cc5d-b20c-453e-8886-f57502ff2924 Still not created successfully. Its state is error. : BuildAbortException: \u5b9e\u4f8bdc030e38-1ad1-4318-b0df-a3df40daa4ef\u7684\u6784\u5efa\u5df2\u4e2d\u6b62\uff1a\u5728\u7b49\u5f85132 \u79d2\u621643\u5c1d\u8bd5\u540e\uff0c\u53778e64cc5d-b20c-453e-8886-f57502ff2924\u4ecd\u7136\u6ca1\u6709\u521b\u5efa\u6210\u529f\u3002\u5b83\u7684\u72b6\u6001\u662ferror\u3002

        View the log again in the volume.log of the cinder service of the compute node:

        The key information is as follows. The virtual size of the qcow2 format image of win7 we created earlier is 100G, while the volume size set here for the incoming image is only 20G. There may be a problem here.

2021-09-29 22:07:26.738 1802 ERROR cinder.volume.manager ImageUnacceptable: \u6620\u50cf d5fde846-32c9-46d7-9132-20a92e72fa90 \u65e0\u6cd5\u69f\u56e0\u662f\uff1a \u6620\u50cf\u865a\u62df\u5927\u5c0f\u4e3a 100GB\uff0c\u5728\u5927\u5c0f\u4e3a 20GB \u7684\u5377\u4e2d\u5c06\u65e0\u6cd5 2021-09-29 22:07:26.738 1802 ERROR cinder.volume.manager

(3) win7 virtual machine creation test (dashboard graphical)

        Therefore, we modify the win7 disk in qcow2 format to 20G:

qemu-img resize --shrink win7_xshell.qcow2 20G

        Upload the image in qcow2 format to grace:

        Upload qcow2 format image:

glance image-create --name "win7_xshell_qcow2" --file /vhost/win7_xshell.qcow2 --disk-format qcow2 --container-format bare --visibility public --progress

        Delete all filter configurations in the nova.conf configuration file:

scheduler_driver=nova.scheduler.filterscheduler.FilterScheduler scheduler_available_filters = nova.scheduler.filters.all_filters scheduler_default_filters = AvailabilityZoneFilter, RamFilter, DiskFilter, ComputeFilter

        Retry creating the virtual machine from dashboard:

        Set flavor as 2 cores, 2G memory and 20G disk;

        Unfortunately, another volume creation error occurred:

Exception during message handling: ImageCopyFailure: \u672a\u80fd\u5c06\u6620\u50cf\u590d\u5236\u5230\u5377\uff1aqemu-img: error while writing sector 38797312: Input/output error

        It seems that the problem of volume creation again. The image replication fails. I recall that the instance was created through the image in qcow2 format, but I also chose to create a new volume for persistent storage. This option may be used to copy the image to the volume volume volume for persistence, which leads to the problem of image replication errors.

        Therefore, this time we choose to create an instance directly through the image image instead of creating a new volume. Sure enough, the creation is successful, careless!!!

        Connect the virtual machine just created through the console. As shown below, the document when creating the image of the win7 virtual machine appears. Therefore, it can be concluded that the virtual machine is created through the previous qcow2 format image, which is completely consistent:

        View the IP address of the virtual machine:

        To view the current virtual resource usage:


(4) win7 virtual machine creation test (xshell command)

openstack server create --image win7_xshell_qcow2 --flavor win7_xshell win7_xshell

        The virtual machine is created as follows:



(5) dashboard create and mount volume test

        Create a volume directly in the dashboard and give it to win7_ The dash virtual machine creates a 2G blank volume and mounts it on the virtual machine. Connect to the virtual machine through the console, but no 2G disk is found, only a 10G root disk.

        View the disk status in the virtual machine through cmd command:

        Call the command diskpart first;

        Then execute the command list disk;

        You can see the number of disks as follows:

        View disk status through disk management:

        Control Manager - management tools - disk management

        You can partition the disk manually in disk management, select set as disk D, and then display the disk D in the computer:

        Create a document in disk D as a sign;

        Perform backup test on the volume. Separate instances of the volume directly in the dashboard to make the status of the volume available. Try to create a backup for the volume and upload the volume to grace:

        Create a chrome volume from the image image image again_ IMG, and then mount the volume to another instance win7_ In xshell:

        Connect the instance through the console. It is found that in the disk management of the virtual machine, in addition to a 10G root disk, the 2G disk is directly displayed as disk D. is this because we are in win7_ After a 2G disk is directly mounted in the dash virtual machine, it is backed up and uploaded to grace as an image. Then, a new volume Chrome is created through the image_ IMG is directly mounted to another instance win7_xshell. The new volume does not need to be partitioned and can be used directly.

        As you can see, the disk contains the logo document we created earlier, which indicates that this is the disk we created earlier.

        Expand the original chrome volume to the size of 3G in the dashboard, and mount the volume to win7 again_ On a dash instance, connect to the instance to view the disk usage:

        And view the attached disks of the virtual machine through the cmd command:

        It can be seen that the 3G expansion volume is indeed mounted, but the new 1G volume is not partitioned, so it cannot be used. It also needs to be manually allocated in disk management. Expand the original D disk to 3G;

        Continue to check the usage of disks, and you can see that 3G disks appear:


(6) The xshell command creates and mounts a volume test

        The volume command is as follows:
Volume backup:

volume backup create volume backup delete volume backup list volume backup restore volume backup set volume backup show

Volume operation:

volume create volume delete volume host set volume list volume migrate

Volume qos:

volume qos associate volume qos create volume qos delete volume qos disassociate volume qos list volume qos set volume qos show volume qos unset

Distributed services for volume:

volume service list volume service set

Volume settings:

volume set volume show

Snapshot of volume:

volume snapshot create volume snapshot delete volume snapshot list volume snapshot set volume snapshot show volume snapshot unset volume transfer request accept volume transfer request create volume transfer request delete volume transfer request list volume transfer request show

Type of volume:

volume type create volume type delete volume type list volume type set volume type show volume type unset volume unset

Create volume:

openstack volume create --size 2 --image chrome_img chrome_3

        After a period of creation, the volume was successfully created:

        Add volume to chrome_3 mount to instance win7_ On dash:

openstack server add volume win7_dash chrome_3

        As you can see, win7_ The volume is mounted in / dev/vdc in the dash instance;

        View win7 through console_ The dash instance does not see the mounted second volume:

        Check the disk mounting status through the cmd command again:

        Why is the disk offline?

        Remove the volume chrome from win7_ When the dash instance is offline, you can see that the disk is automatically offline from the instance:

openstack server remove volume win7_dash chrome

        Add the volume to chrome again_ 3 from instance win_ When you go offline in dash and mount it again, you can see that the displayed volume Chrome has not been mounted before_ 3 reappears:

        By volume chrome_3 to create image image chrome_img_2:

openstack image create --container-format bare --disk-format qcow2 --volume chrome_3 chrome_img_2

        Through this image, chrome_img_2 create a new volume chrome_4:

openstack volume create --size 2 --image chrome_img_2 chrome_4

        The status of the volume is ERROR;

        Re align the volume chrome_3 create a new chrome image_ img_ 3:

openstack image create --container-format bare --disk-format raw --volume chrome_3 chrome_img_3

        It can be seen that the size of the image is 2G, which is obviously compared with the previous 640KB qcow2 format:

        Re run chrome through the mirror_ img_ 3 create a new volume chrome_4:

openstack volume create --size 2 --image chrome_img_3 chrome_4

        The status of the created volume is still ERROR;

        Therefore, try the following command to create an image mirror of the volume_ img_ 2:

cinder upload-to-image --disk-format raw --visibility shared chrome_3 chrome_img_2

        Create a new volume chrome from the mirror again_ four

openstack volume create --size 2 --image chrome_img_2 chrome_4

        The status still fails. Forget it. If you don't try, there shouldn't be many places for volume backup;

(7) Making vhd format virtual disk with specified content by win machine

        Create a new virtual disk in vhd format in disk management and display it as a new E disk;

        Load the file to be transferred into the new virtual disk E, and then separate the disk from the win machine:

        Upload the vhd format file to the Controller node and then to grace as an image:

glance image-create --name "chrome_vhd" --file /image/chrome.vhd --disk-format vhd --container-format bare --visibility public --progress

        Then create a volume through the vhd format image:

        Mount the volume to instance win7_ In dash, connect the instance through the console to view:

        You can see that the volume is directly mounted on the instance and can be viewed and used directly.

(8) Specifies the creation of the software volume

        Create two vhd virtual disks in the Win machine, put the specified exe program into the virtual disk, and upload the disk to grace as a volume in the above way:

        Then create the volume from the mirror:

        It can be directly mounted on the instance;

(9) Control node program embedded virtual machine image test

        Microservices are java programs, so they need to be installed on the virtual machine win7_ Install JDK and IDEA in dash;

4 October 2021, 21:59 | Views: 2041

Add new comment

For adding a comment, please log in
or create account

0 comments