| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-03-01 | |||
| 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 | |
| 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 | |
| 13:54:28 | sean-k-mooney | legochen: in that case i dont think there is any way to fuly elid the copy although cinder also has an image cache. | |
| 13:54:28 | legochen | we don’t use ceph :) | |
| 13:55:07 | sean-k-mooney | legochen: in general its not a great idea to have multiple sotrage solution deployed in a single openstack cloud it prevent some optimnisation form being done | |
| 13:57:10 | sean-k-mooney | ok i have to go do some work downstream for a while so ill be semi away from irc for a while o/ | |
| 13:57:35 | legochen | got it. thank you for your knowledge | |
| 13:57:48 | legochen | sean-k-mooney :) | |
| 13:59:29 | sean-k-mooney | legochen: in your spcific case createing vms form volumne snapshots might be the most effecinct | |
| 14:00:31 | sean-k-mooney | but do follow up with the cinder folks they may be able to help more. i belvie cinder has some config option to optimise this somewhat but im not super familar with all the options they have | |
| 14:01:40 | legochen | sean-k-mooney, stephenfin - as my misunderstanding about —block-device option, I thought it can be used to root partition. So, I think to support —volume-type in OSC become a more useful feature … we need to have. otherwise, we’ll need to create image volume first and use that volume to boot an instance. | |
| 14:02:39 | legochen | sean-k-mooney, got it. will check with cinder channel about that. thank you. “volume snapshots” could be a good idea, let me try it more. | |
| 14:08:04 | sean-k-mooney | legochen: it can be used for the root disk but --block-device is not only used for cinder it is used for advance block device configuration in general | |
| 14:08:51 | legochen | so, sounds like —block-device is also an ideal option? | |
| 14:08:53 | sean-k-mooney | i think that is what you missed if the dest type is local for exaple its used to configure epmermal storage | |
| 14:10:23 | legochen | I guess I can use nova command to test that, right | |
| 14:10:24 | legochen | --block-device source=volume,id=33ecc63a-ccc1-496b-ae9a-61babe615568,dest=volume,shutdown=preserve | |
| 14:11:53 | legochen | ,bootindex=0 | |
| 14:11:57 | legochen | need to add this | |
| 14:13:36 | sean-k-mooney | well that will bot with an exsiting volumn | |
| 14:13:41 | sean-k-mooney | it wont create a new one | |
| 14:13:58 | sean-k-mooney | but ya anyway sorry got to go. | |
| 14:14:25 | legochen | ERROR (BadRequest): Block Device Mapping is Invalid: Boot sequence for the instance and image/block device mapping combination is not valid. (HTTP 400) (Request-ID: req-c004edcf-0deb-4354-8358-c78cdf7f6c08) | |
| 14:14:36 | legochen | okay, I got this error when add “,bootindex=0" | |
| 14:14:47 | legochen | sure, you busy first. | |
| 14:17:25 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Deprecate disable_native_luksv1 and rbd_volume_local_attach https://review.opendev.org/c/openstack/nova/+/778004 | |
| 14:19:36 | sean-k-mooney | lyarwood: i thought ^ was alredy dperecated when we added them | |
| 14:20:04 | sean-k-mooney | ik guess you did not formally do it but that was the intent of your comment | |
| 14:20:14 | sean-k-mooney | to so we could actully remove them in W | |
| 14:21:18 | lyarwood | sean-k-mooney: yeah I didn't formally do it at the time, was about to do it now and noticed so thought I'd follow normal procedure and remove them early in Xena | |
| 14:21:46 | sean-k-mooney | ok i guess it does not matter too much | |
| 14:21:59 | sean-k-mooney | it proably makes upgrades slightly simpler for 17 | |
| 14:22:00 | lyarwood | yeah, would be nice to remove them now for my sanity but that's about it | |
| 14:22:05 | sean-k-mooney | since they can disable this after upgrade instead | |
| 14:22:07 | lyarwood | right | |
| 14:22:20 | lyarwood | well they can disable it after they move to 16.2 downstream | |
| 14:22:28 | lyarwood | we've backported the perf fixes to 8.3 | |
| 14:23:40 | sean-k-mooney | ah ya good point | |
| 14:24:55 | sean-k-mooney | lyarwood: also no worries about lunch, if we can move the os-vif backport forward that would be good as we need it before 16.2 is release but we have a few months to work on that | |
| 14:26:25 | lyarwood | kk | |
| 15:00:51 | openstackgerrit | Jessie Lass proposed openstack/nova master: Add emulation support if host arch != guest arch. https://review.opendev.org/c/openstack/nova/+/772156 | |