| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-03-01 | |||
| 13:20:24 | sean-k-mooney | 2 is done in https://review.opendev.org/c/openstack/python-openstackclient/+/771699/3/openstackclient/compute/v2/server.py | |
| 13:20:26 | legochen | otherwise, the current OSC doesn’t have the ability to use an available & existing block-storage volume as root partition to boot an instance. | |
| 13:20:30 | sean-k-mooney | still unmerged | |
| 13:21:16 | legochen | okay, understood, do we have timeline to merge it :D | |
| 13:21:26 | sean-k-mooney | we are deprecating --block-device-mapping in fravor of --block-device | |
| 13:21:31 | sean-k-mooney | am not sure | |
| 13:22:00 | sean-k-mooney | stephenfin: ^ any idea when you expect the osc bfv change to merge | |
| 13:22:09 | sean-k-mooney | will it happen this cycle | |
| 13:22:25 | legochen | do you mean you recommend --block-device instead of “ --block-device-mapping” ? | |
| 13:23:01 | sean-k-mooney | legochen: osc does not curently have --block-device but we are adding it and it will replace teh use fo teh existing --block-device-mapping command in osc | |
| 13:23:20 | lyarwood | sean-k-mooney: ack sorry was out at lunch | |
| 13:23:40 | legochen | okay, thanks. clear now. | |
| 13:24:07 | legochen | about 1) … I feel if it cannot specify “volume-type”, it will be not that useful. | |
| 13:24:14 | sean-k-mooney | legochen: the imporant point form your point of view will be the abllit to set volume_type | |
| 13:24:40 | sean-k-mooney | legochen: that could be added | |
| 13:25:40 | sean-k-mooney | well looking at it its proably not possible actuly | |
| 13:26:00 | sean-k-mooney | currently --boot-from-volume is defiend as an int | |
| 13:26:11 | sean-k-mooney | we could proably add a --volumn-type however | |
| 13:26:20 | sean-k-mooney | so you would use both | |
| 13:27:18 | sean-k-mooney | so somthign like --boot-from-volume 100G --image <my-image> --volume-type=<my-volume-type> | |
| 13:27:42 | legochen | yes, that would be better ! | |
| 13:28:05 | sean-k-mooney | you should file a bug with osc or if you have time a patch? | |
| 13:28:20 | sean-k-mooney | otherwise see if stephenfin has time to adress it in a follow up. | |
| 13:28:37 | sean-k-mooney | legochen: currently he is trying to close the remaining gaps between nova clinet and osc | |
| 13:29:01 | sean-k-mooney | so that has priorty over adding syntatic sugar. this would be nice to have but less of a priorty then his other patches | |
| 13:29:18 | legochen | thanks, about 2) is not that require to me beacuse I feel 1) is much better in my use cases. | |
| 13:29:55 | sean-k-mooney | 2 is needed for other usecase and what stephen has already implmented | |
| 13:30:09 | sean-k-mooney | 1 i would guess he wont have time to work on in the near future | |
| 13:30:48 | legochen | understood….btw, if you don’t mind, I’d like to go back to talk the performance questions with you. | |
| 13:31:08 | legochen | https://docs.openstack.org/nova/latest/user/launch-instance-from-volume.html | |
| 13:31:46 | sean-k-mooney | sure | |
| 13:32:03 | legochen | basically, one OpenStack cluster could be split into two parts 1) Control Plane 2) Hypervisors . | |
| 13:32:12 | legochen | in that document | |
| 13:32:34 | legochen | These two options “Create a volume from an image and boot an instance from that volume.” and “Boot from an existing source image, volume, or snapshot.” | |
| 13:33:00 | legochen | Looks like the image download stuff happens on the Control Plane side. | |
| 13:33:29 | legochen | Only this otion “Boot an instance from an image and attach a non-bootable volume.” is happen on the hypervisor side | |
| 13:34:06 | sean-k-mooney | the first option https://docs.openstack.org/nova/latest/user/launch-instance-from-volume.html#boot-instance-from-image-and-attach-non-bootable-volume | |
| 13:34:16 | sean-k-mooney | is stanard boot. e.g. not boot form volumn | |
| 13:34:38 | openstackgerrit | Lee Yarwood proposed openstack/nova master: nova-manage: Add libvirt get_machine_type command https://review.opendev.org/c/openstack/nova/+/769548 | |
| 13:34:38 | openstackgerrit | Lee Yarwood proposed openstack/nova master: nova-manage: Add libvirt update_machine_type command https://review.opendev.org/c/openstack/nova/+/774896 | |
| 13:34:39 | openstackgerrit | Lee Yarwood proposed openstack/nova master: nova-manage: Add libvirt list_unset_machine_type command https://review.opendev.org/c/openstack/nova/+/774897 | |
| 13:34:40 | openstackgerrit | Lee Yarwood proposed openstack/nova master: nova-status: Add hw_machine_type check for libvirt instances https://review.opendev.org/c/openstack/nova/+/770643 | |
| 13:34:41 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Add a config update workflow test for [libvirt]hw_machine_type https://review.opendev.org/c/openstack/nova/+/774898 | |
| 13:34:42 | openstackgerrit | Lee Yarwood proposed openstack/nova master: docs: Add admin docs for configuring and updating machine types https://review.opendev.org/c/openstack/nova/+/774899 | |
| 13:34:43 | sean-k-mooney | so the image donwload happens on the compute node and we create a raw or qcow 2 file by defualt | |
| 13:35:07 | sean-k-mooney | the download only happens if we dont have the image in teh compute nodes image cache already | |
| 13:35:29 | legochen | nova boot --flavor a5.8 --image rhel-7.9.11 --block-device source=volume,id=33ecc63a-ccc1-496b-ae9a-61babe615568,dest=volume,shutdown=preserve --availability-zone my-az --nic | |
| 13:35:30 | legochen | net-name=my-network boot-volume-instance-01 | |
| 13:35:39 | sean-k-mooney | in the other cases the image may or may not be downloaded to the compte | |
| 13:35:54 | legochen | sean-k-mooney, okay, I mean this command | |
| 13:36:31 | legochen | this command will use an existing block volume attach to instance’s root partition to install the OS. | |
| 13:37:06 | legochen | So, that’s why I say the image download behavior happen on the hypervisor side. | |
| 13:37:37 | sean-k-mooney | no this will create a root disk form the image and attach a second data volumn | |
| 13:39:21 | sean-k-mooney | legochen: that command is the same as doing "nova boot --flavor a5.8 --image rhel-7.9.11 --availability-zone my-az --nic et-name=my-network non-boot-volume-instance-01 | |
| 13:39:34 | sean-k-mooney | then attaching a volumn | |
| 13:39:41 | sean-k-mooney | you are not create a boot form volun instance | |
| 13:39:59 | sean-k-mooney | you creatting a non boot form volumn instance with an addtion cinder volumn that is not used for the root disk | |
| 13:40:26 | sean-k-mooney | https://docs.openstack.org/nova/latest/user/launch-instance-from-volume.html#create-volume-from-image-and-boot-instance create a boot form volumn image using an image as a source | |
| 13:40:40 | sean-k-mooney | nova boot --flavor FLAVOR --block-device \ | |
| 13:40:41 | sean-k-mooney | source=SOURCE,id=ID,dest=DEST,size=SIZE,shutdown=PRESERVE,bootindex=INDEX \ | |
| 13:40:43 | sean-k-mooney | NAME | |
| 13:41:30 | legochen | okay, thanks. that’s my misunderstanding | |
| 13:41:46 | sean-k-mooney | e.g. source=image,id=<glance image uuid>,dest=volumn,size=100G,shutdown=PRESERVE,bootindex=0 \ | |
| 13:42:27 | sean-k-mooney | legochen: basically the first workflow is used in 2 cases | |
| 13:42:37 | sean-k-mooney | 1 you do not want boot form volume | |
| 13:42:53 | legochen | then, seems like the follow would always require to create an image volume first and then use this volume to boot an instance. | |
| 13:42:58 | sean-k-mooney | 2 the image is an iso and you want to install it to a volumn which you will use later for a different vm | |
| 13:43:21 | legochen | follow = flow (typo) | |
| 13:44:44 | sean-k-mooney | legochen: well you have 4 options 1 dont use boot form volumn, 2 boot form a new volumn created form an iamge, 3 boot form an existing volumne, 4 boot form a new volumne created as a volume snapshot form an existing volumne | |
| 13:45:26 | sean-k-mooney | the last 3 all use https://docs.openstack.org/nova/latest/user/launch-instance-from-volume.html#create-volume-from-image-and-boot-instance | |
| 13:45:56 | sean-k-mooney | but the source changes e.g. image,volumn or snapshot | |
| 13:46:13 | legochen | our requirement is just wanted to let VM instance can use our block storage as root partition to boot. | |
| 13:46:31 | sean-k-mooney | that is the default if you dont use --block-device | |
| 13:46:44 | sean-k-mooney | unless you mean cinder | |
| 13:47:07 | sean-k-mooney | if you want to use cinder as teh root disk then you can use https://docs.openstack.org/nova/latest/user/launch-instance-from-volume.html#create-volume-from-image-and-boot-instance | |
| 13:47:12 | legochen | block storage - yes, managed by cinder | |
| 13:47:28 | sean-k-mooney | then yes follow ^ and it will create a bfv guest | |
| 13:47:40 | legochen | what’s bfv? | |
| 13:47:49 | sean-k-mooney | boot form volumn | |
| 13:48:21 | sean-k-mooney | *boot from volume | |
| 13:48:43 | sean-k-mooney | it gets tiresome to type so we usually use bfv as a shorthand | |
| 13:48:57 | legochen | ok, thanks. I just feel this flow is not that efficient. because it needs to | |
| 13:49:04 | legochen | 1) copy the image from glance to cinder image conversation folder | |
| 13:49:06 | legochen | 2) mount cinder block storage on control plance | |
| 13:49:21 | legochen | 3) create image volume | |
| 13:49:28 | legochen | 4) create VM by this volume | |
| 13:49:32 | sean-k-mooney | it wont do that in all cases | |
| 13:50:07 | sean-k-mooney | as i said if cinder and glance share teh same sotrage backend or if glance uses cinder volumns to store the image then cinder can do a more effect process | |
| 13:50:20 | legochen | feel the first two steps take time and cause disk-io loading during copy images. | |
| 13:50:42 | sean-k-mooney | cinder does not need to do a copy in all cases | |
| 13:51:00 | sean-k-mooney | if you you ceph for glance and cidner then no copy happens provided they both use the same ceph cluster | |
| 13:51:31 | sean-k-mooney | cinder will insted create a new volume as a thin snapshot of the image | |
| 13:51:56 | sean-k-mooney | it will also do this in most cases when cinder is used as the glance image store backend | |
| 13:51:59 | legochen | do I need to configure something on both cinder and glance config? let them can identify they don’t need to do copy stuff | |
| 13:52:00 | gibi | stephenfin: thanks for the comment on the vnc series. I'm glad we had the tempest test to show that we have a more complicated situation than what I thought | |
| 13:52:24 | sean-k-mooney | it need driver support but the copy should be elided. | |
| 13:52:47 | sean-k-mooney | legochen: am for ceph i dont think so but you would be better asking that question in the cinder channel | |
| 13:53:02 | legochen | do you have example … I’d like to look into more about this. | |
| 13:53:05 | sean-k-mooney | they can explaine how to configure ciner/glace to avoid the copy | |
| 13:53:39 | legochen | our glance is using NetApp filer to store images, but cinder is using EMC VxFlex block storage | |