Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-03-01
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
15:09:18 kashyap Strange, before rebasing, I didn't see this exception when running unit tests; but after rebase, I see:
15:09:26 kashyap "Exception: This test uses methods that set internal oslo_db state, but it does not claim to use the database [...]"
15:10:32 kashyap [https://zuul.opendev.org/t/openstack/build/0347425ea0d74725a73f41ee4eaf6dd1]
15:17:55 sean-k-mooney likely not mocking something you should
15:18:57 lyarwood yeah it should be in the trace
15:19:23 lyarwood ah it's my stuff that's causing this for you
15:19:24 lyarwood _register_instance_machine_type
15:19:35 lyarwood just mock that out
15:19:43 lyarwood kashyap: ^
15:20:03 kashyap lyarwood: Oh, I see. That's the change the rebase brought
15:20:24 kashyap sean-k-mooney: It came only after the rebase; it was not there before.
15:20:25 sean-k-mooney lyarwood: that might want to be mocked in the setup funciton
15:22:35 lyarwood sean-k-mooney: I assume kashyap's tests are calling init_host directly
15:23:16 kashyap lyarwood: Indeed, I noticed that removing the call to init_host "fixes" it - drvr.init_host("dummyhost")
15:23:33 kashyap lyarwood: I don't even think it's required to call here. Because, I checked in the PDB --
15:23:51 kashyap My test asserts expected results w/o the init_host() call
15:24:21 kashyap So I'm actually going to remove it; it's not required in this case, near as I can tell
15:24:49 kashyap Thanks for looking, folks!
15:25:03 lyarwood kashyap: https://review.opendev.org/c/openstack/nova/+/774240/10/nova/tests/unit/virt/libvirt/test_driver.py@1478
15:25:17 lyarwood kashyap: looks like you removed the mock from test__check_cpu_compatibility_start_ok
15:25:44 kashyap lyarwood: Urgh; that was accidental damage during rebase. Sloppy me.
15:25:52 kashyap I thought I double-checked, and still I failed
15:28:39 kashyap That's it; it's the missing mock
15:34:50 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: libvirt: Allow disabling CPU flags via `cpu_model_extra_flags` https://review.opendev.org/c/openstack/nova/+/774240
15:43:06 openstackgerrit Balazs Gibizer proposed openstack/nova stable/pike: rt: Make resource tracker always invoking get_inventory() https://review.opendev.org/c/openstack/nova/+/778014
15:45:06 openstackgerrit Balazs Gibizer proposed openstack/nova stable/pike: Update resources once in update_available_resource https://review.opendev.org/c/openstack/nova/+/612295
16:23:59 openstackgerrit Merged openstack/nova master: apidb: Compact Mitaka database migrations https://review.opendev.org/c/openstack/nova/+/759400

Earlier   Later