| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-03-01 | |||
| 13:03:23 | gibi | sean-k-mooney: ack | |
| 13:03:48 | legochen | thank you | |
| 13:04:56 | sean-k-mooney | ok so your asking about osc and block device mappings | |
| 13:05:16 | sean-k-mooney | stephenfin: has a patch up to rework how osc supports this currently | |
| 13:06:08 | sean-k-mooney | https://review.opendev.org/c/openstack/python-openstackclient/+/771696 | |
| 13:07:55 | sean-k-mooney | so there are several ways to create a vm as im sure your aware | |
| 13:08:18 | sean-k-mooney | you can create a vm with local root disk and have seperate data volumes | |
| 13:08:45 | sean-k-mooney | or you can replace the root disk with a cinder volume instaed of having it stored locally on the compute node. | |
| 13:09:02 | sean-k-mooney | the later can be done several ways and is what we refer to as boot form volume | |
| 13:09:40 | sean-k-mooney | nova support eighter using a prexisting bootable volume, or a new volumn created by nova form either an image of volume snapshot | |
| 13:10:31 | sean-k-mooney | the efficncy fo each depend on 1 how you judge efficncy and 2 whatn nova, glance and cinder backends you have configured | |
| 13:11:00 | sean-k-mooney | for example if you are using ceph for cinder nova and glance then boot form volume and non boot form volume are basically the same | |
| 13:11:29 | sean-k-mooney | in all cases teh root disk will just be a thin snapshot over the orignial image | |
| 13:12:21 | sean-k-mooney | similarly you use cider as the glance backend and your cinder driver support it then bfv volumes created from images can simialrly be a thin provisioned volumn | |
| 13:13:49 | sean-k-mooney | the presence of addtional data volumne in any configuration is largely irrelvent to effincincy or perfroamce since in bfv or non bfv cases you should keep all data you care about in a cinder data volumn anyway so you can tree the root disk as ephemeral | |
| 13:14:19 | sean-k-mooney | legochen: not sure if that help but if you have a specific question i can try and answer that | |
| 13:15:25 | sean-k-mooney | im not really sure how you are gaugeing effiency (storage space? perfroamce(troughtput,latency,boot time)? network bandwith utilisation?) or what your usecase is | |
| 13:18:16 | legochen | hey sean-k-mooney, sorry just back. I think my major questions are about OSC stuff. | |
| 13:18:41 | legochen | 1) let “—boot-from-volume <volume-size>” option can specify volume-type | |
| 13:19:04 | legochen | 2) support —block-device option as what ocata version has. | |
| 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 update_machine_type command https://review.opendev.org/c/openstack/nova/+/774896 | |
| 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: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 | |