| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-01-12 | |||
| 17:02:55 | sean-k-mooney | tkajinam: i think the main issue is the copy tiem if your using a raw image. obvioulsy there is no copy invoveld for qcow since we just share the backing file form the cache outise of the initial spawn | |
| 17:03:41 | jayaanand | We want to leverage copy on write technology from ONTAP | |
| 17:03:50 | tkajinam | ok but I think that can be also eased by image cache volume in cinder/glance I guess | |
| 17:03:55 | jayaanand | Instead of qcow2 format | |
| 17:04:48 | sean-k-mooney | i think we will need more context on hwo that work and if tis a generic feature in nfs itslef or some propeirty extnsion | |
| 17:04:51 | jayaanand | We explored cinder volumes. Direct ONTAP volumes give better performance | |
| 17:05:30 | sean-k-mooney | but you said using nfs right so taht woudl still just be a file of some form on disk | |
| 17:05:41 | sean-k-mooney | well a file on a file system | |
| 17:05:56 | jayaanand | It's propeirty on top of NFS | |
| 17:06:13 | sean-k-mooney | right os that also problematic | |
| 17:06:25 | jayaanand | Yes NFS on compute node | |
| 17:06:51 | jayaanand | File on ONTAP with better copy on write | |
| 17:07:40 | sean-k-mooney | ack can you create a draft spec, it does not have to be compelte with your problemstatemen use cases and any relvente context/info on the feature | |
| 17:07:49 | tkajinam | https://specs.openstack.org/openstack/nova-specs/ | |
| 17:08:00 | tkajinam | https://specs.openstack.org/openstack/nova-specs/readme.html | |
| 17:08:22 | jayaanand | Sure, i will create, thank you for the advice | |
| 17:08:53 | Uggla | Cool, we are already overtime, last minute thing to add ? If not then we will close. | |
| 17:09:03 | jayaanand | Need to understand how right OS that is problematic? | |
| 17:09:38 | womax | I had something I wanted to talk about but it can wait for next week | |
| 17:09:58 | womax | and i think it can be discussed outside of meetings | |
| 17:10:07 | Uggla | womax thanks, if you can update the agenda, so it will be identified. | |
| 17:10:10 | jayaanand | Sure | |
| 17:10:24 | womax | Uggla: ok i'll do that | |
| 17:11:15 | Uggla | Thanks for joining this meeting. Closing now. | |
| 17:11:24 | Uggla | #endmeeting | |
| 17:11:24 | opendevmeet | Meeting ended Mon Jan 12 17:11:24 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 17:11:24 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2026/nova.2026-01-12-16.05.html | |
| 17:11:24 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2026/nova.2026-01-12-16.05.txt | |
| 17:11:24 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2026/nova.2026-01-12-16.05.log.html | |
| 17:12:17 | jayaanand | Thank you | |
| 17:17:48 | sean-k-mooney | jayaanand: googleign thie a liitle ONTAP wafl filestiem when exported vis nfs 4.2 can transparently supprot servier side cloning when you use qemu-im or cp with the --reflink link flag | |
| 17:18:09 | sean-k-mooney | provided you have ONTAP 9.8 | |
| 17:19:20 | jayaanand | true, ONTAP handles RAW with native compression and dedupe. this with avoid double virtualization | |
| 17:20:04 | sean-k-mooney | so im wonderign if the flat backend woudl be enough for your usecase | |
| 17:20:07 | sean-k-mooney | or raw | |
| 17:20:34 | sean-k-mooney | if we ensure nova propelry uses that feature when nfs 4.2 is used | |
| 17:20:52 | jayaanand | raw is better handled at ONTAP | |
| 17:21:29 | sean-k-mooney | sure but we already supprot raw format | |
| 17:21:30 | jayaanand | file is facade hear, internally it is RAW at WAFL | |
| 17:21:52 | sean-k-mooney | what im saying is it may be possible to not add a new backend at all | |
| 17:22:08 | sean-k-mooney | and simple use the more efficnet copy method when tis supproted by the file systems | |
| 17:22:11 | jayaanand | we won't introduce new format. we will user RAW with ONTAP copy on write capabilities | |
| 17:22:55 | jayaanand | we will delegate any clone operation to ONTAP for quick VM creation | |
| 17:23:00 | jayaanand | on top of RAW | |
| 17:23:35 | jayaanand | these are NFS files at ONTAP on top of FlexGroup | |
| 17:24:01 | sean-k-mooney | right the feedback im providieng is im not sure that we will accpate a vendor speciics storage backend in nova | |
| 17:24:18 | sean-k-mooney | and im tryign to understand if we can achive the same thing by jsut doing "cp --reflink=always source.raw destination.raw" | |
| 17:24:31 | MaxLamprecht[m] | Interestingly I heard yesterday also about the nfs4.2 native server-side-copy/file-cloning feature. Sadly ONTAP 9.16 currently returns NFS4 error not supported. I guess it‘s not implemented by netapp or hidden by some config flag or so. | |
| 17:24:32 | sean-k-mooney | when doign the copy fo the image | |
| 17:25:11 | sean-k-mooney | well nfs v3 supprot is deprecated in general | |
| 17:25:23 | sean-k-mooney | we ahve recommend 4.2 or a bove for many years now | |
| 17:25:46 | sean-k-mooney | that recomendation orgianlly came form the qemu storage maintaienrs | |
| 17:25:58 | jayaanand | docs.netapp.com/us-en/ontap/nfs-admin/ontap-support-nfsv42-concept.html | |
| 17:26:01 | sean-k-mooney | i.e. to move to v4+ due to lockign issues | |
| 17:26:28 | jayaanand | Max, almost all of our customers on NFS 4+ | |
| 17:26:39 | jayaanand | you can look into your specific issue | |
| 17:26:58 | MaxLamprecht[m] | Yes we also use nfs4.2 :) | |
| 17:27:44 | jayaanand | we tried "if we can achive the same thing by jsut doing "cp --reflink=always source.raw destination.raw""... this is introducing conversion overhead at ONTAP | |
| 17:27:54 | sean-k-mooney | http://nfsv4bat.org/Documents/ConnectAThon/2010/ss-copy-spec.pdf that netaps presetion on the feature form 2010 | |
| 17:28:24 | sean-k-mooney | but maybe it never got enabeld or is behind a config flag | |
| 17:30:10 | jayaanand | For direct storage on the ONTAP backend, QCOW2 images are automatically converted to the raw format | |
| 17:31:03 | jayaanand | https://www.netapp.com/media/10720-tr-4067.pdf | |
| 17:31:54 | sean-k-mooney | ok but i am not suggestign you woudl use qcow im suggestign you configre nova to use raw format but when we copy the raw file from the casche we woudl do that with --reflink so that there would nto be a data copy | |
| 17:32:29 | sean-k-mooney | so you woudl set https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.force_raw_images to true | |
| 17:32:31 | jayaanand | https://www.irccloud.com/pastebin/OCDzzgTM/ | |
| 17:32:47 | sean-k-mooney | and images-type=raw or images_type=flat | |
| 17:36:01 | jayaanand | ok, let me check if reflink will trigger clone at ONTAP | |
| 17:36:25 | jayaanand | i will explore and share my findings | |
| 17:36:30 | sean-k-mooney | ack | |
| 17:37:10 | sean-k-mooney | simply supproting a generic nfs feature like server side copies would be a much smaller chnage if that is suffeient to fullfile the usecase | |
| 17:38:52 | jayaanand | sure, we want to use RAW format to take advantage of propitiatory de-dupe, compression and COW | |
| 17:39:38 | jayaanand | and avoid double virtualization at storage layer and save VM cycles for QCOW2 maintenance | |
| 18:05:59 | opendevreview | sean mooney proposed openstack/nova master: Support os-vif TAP pre-creation for OVS/OVN ports https://review.opendev.org/c/openstack/nova/+/973149 | |
| 18:06:12 | opendevreview | sean mooney proposed openstack/os-vif master: Add TAP device pre-creation support for OVS/OVN https://review.opendev.org/c/openstack/os-vif/+/971231 | |
| 18:25:09 | opendevreview | sean mooney proposed openstack/nova master: Support os-vif TAP pre-creation for OVS/OVN ports https://review.opendev.org/c/openstack/nova/+/973149 | |
| #openstack-nova - 2026-01-13 | |||
| 02:39:56 | mkuroha | Hi gibi, sorry to bother you just after you got back from PTO. I’ve updated this patch based on your feedback. Please take a look and share any comments when you have time. https://review.opendev.org/c/openstack/nova/+/948304 | |
| 03:01:17 | seyeongkim | could someone please review this patch or give me any advices about the approch? thanks so much. https://review.opendev.org/c/openstack/nova/+/963665 | |
| 08:52:55 | gibi | sambork: o/ I'm not sure you saw gmaan's post merge comments on the conductor eventlet series. https://review.opendev.org/c/openstack/nova/+/962478 I think it worth checking if there are dead code / missing cleanup based on his comments in that patch | |
| 08:55:53 | sambork | hey gibi, thanks for pointing out this one! yeah I will check them ! | |
| 09:30:23 | bauzas | Uggla: fancy mentioning today as implementation review day ? :) | |
| 09:39:33 | Uggla | bauzas, you are right, I forgot about it yesterday. | |
| 09:40:18 | bauzas | Uggla: can I use https://etherpad.opendev.org/p/nova-2026.1-status as a base for reviewing patches | |
| 09:40:20 | bauzas | ? | |
| 09:43:05 | Uggla | bauzas, I still not updated it (gonna do it). So unfortunately not. But you can have a look at r_taken's https://blueprints.launchpad.net/nova/+spec/generalize-sev-code patch | |
| 09:43:16 | bauzas | thanks | |
| 09:43:41 | bauzas | and I also said to tkajinam that I was wanting to review his patches, tkajinam any first ones I should look at ? | |
| 09:47:17 | bauzas | Uggla: can you please set https://blueprints.launchpad.net/nova/+spec/generalize-sev-code to approved as we agreed at the PTG ? | |
| 09:54:07 | Uggla | bauzas, yep | |
| 11:04:27 | tkajinam | bauzas, all of my patches are in single chain so please start from https://review.opendev.org/c/openstack/nova/+/969263 (I triggered recheck because the failure in threading job looks unrelated (and has never seen before) | |
| 11:05:01 | tkajinam | the first one is the preparation work which extends the existing functional test coverage so I believe it's not very controversial :-) | |
| 13:45:34 | sean-k-mooney | seyeongkim: so that is a feature rather then a bug. its alos possibel to specify the boot order via teh block device mappings today | |
| 13:50:13 | sean-k-mooney | lookign at the bug report this does not seam to be a nova bug | |
| 13:50:27 | sean-k-mooney | the behvario depend on ght grub config and grub config is out os scope of nova/openstack | |
| 13:51:13 | sean-k-mooney | in nova we also dont offically suprpot dual booting. | |
| 13:51:27 | sean-k-mooney | at lest not in multipel disks like this | |
| 13:52:08 | sean-k-mooney | we supprot a singel root disk(local or cidner volume) + additiaonl ephermal disks or cinder data volumes | |
| 13:52:31 | sean-k-mooney | the bug report state that if both device hav ea boot_index set then it works today | |
| 13:54:17 | sean-k-mooney | if you do not use cinder voluems for the non root disk that woudl also be lost on operations like shelve | |
| 16:25:22 | gibi | sean-k-mooney: fyi the py312-treading job error tkajinam mentioned above in https://review.opendev.org/c/openstack/nova/+/969263 is complaining to FairLockGuard. So you might have imediate context on that issue | |
| 16:25:26 | gibi | TypeError: Cannot enter FairLockGuard while it is already active. Create a new instance for nested usage or wait for the current context to exit. | |