Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2026-01-12
16:50:38 dansmith again, this is sounding more like a spec than a bug fix, given it's going to introduce new behavior and affect many operations
16:51:41 sean-k-mooney maybe but to me this was just restorign the behvior we orginally intended
16:51:57 sean-k-mooney but i agree its non trivial and we need to docuemnt the lifecylce
16:52:46 dansmith I didn't ever have intent for this, so don't lump me into that "we".. perhaps you mean what _you_ intended, and that's fine, but regardless it's going to be more of a change from where we are
16:52:56 dansmith especially if we're doing things like only recreating if rebuilding to a different image, etc
16:53:29 sean-k-mooney well that actully more of a a comment on the related vtpm feature rather then nvram
16:53:43 sean-k-mooney we said we wanted to adress both the same way
16:53:59 sean-k-mooney and for vtpm we very explcitly wanted to preserve the data across lifecycle operations
16:54:12 nicolairuckel I mean, there were a few bug reports were people expected the behaviour from my patch.
16:54:41 sean-k-mooney lets give the last 5 mins to jayaanand
16:54:49 Uggla guys, can we stop and let some time for jayaanand
16:54:51 jayaanand thank you
16:55:14 jayaanand We are planning to implement NetApp FlexGroup Backend for Ceph-like Ephemeral Storage Performance on NFS similar to Ceph by overriding RAW format
16:55:15 sean-k-mooney jayaanand: if i understand your propsoal form the list you want to intoduce nfs awarenes to the image_types backend by adding a new backend
16:55:40 dansmith jayaanand: I dunno what "override RAW" means, but that's almost certainly not going to fly.. either way, we need a detailed spec proposed to review to explain what you're planning and then we can review
16:56:04 jayaanand This cow operations will be taken care at storage
16:56:06 dansmith we're not going to get into the details of that in a meeting, and certainly not with five minutes left, until we have some context to build
16:57:18 jayaanand Ok, Has anyone explored or implemented storage-side cloning for other NFS vendors?
16:57:31 sean-k-mooney no not in nova
16:57:43 sean-k-mooney we do not creat vendor specific backend in nova in general
16:58:19 sean-k-mooney so for us to supprt that in nova we woudll ideally want ti wot work for any generic nfs server
16:58:23 jayaanand Ok, concerns is any architectural red flags with this approach in the Nova driver? NFS Ephemeral volumes
16:59:07 sean-k-mooney the main concern with adding a nfs images_type backend is there is a lot fo existing technial debt in that part of the code base
16:59:14 dansmith yes, I have red flag concerns because of what sean-k-mooney said and also because server-side snapshotting of files nova is accessing is already complicated and different when we do it with cinder
16:59:36 dansmith yes, I also don't really want to be adding new image backends to the current implementation
17:00:17 bauzas agreed
17:00:58 sean-k-mooney its something we can try and dicsus about more but if it would only work for netapp that proably not someting we would pursue. we would also need to dicuss how this will be tested in ci. all of witch would be captures in a spec
17:01:11 jayaanand Ok, we have multiple customers looking for this feature... What is way out?any suggestions
17:01:33 sean-k-mooney i think we need to know what the problem statement is first
17:01:49 tkajinam jayaanand, I think the general preference is to use cinder volume in case you want better features. I still don't understand why you really need it within ephemeral volumes
17:01:52 sean-k-mooney perhaps there si a way to adress that without requriing a new backend
17:01:58 tkajinam that's something I expect to be covered by that statement
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

Earlier   Later