| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2026-06-18 | |||
| 05:26:39 | opendevreview | chandan kumar proposed openstack/cyborg master: Add NVMeVirt emulated NVMe device support for devstack https://review.opendev.org/c/openstack/cyborg/+/977083 | |
| 06:29:36 | opendevreview | chandan kumar proposed openstack/cyborg master: Add NVMeVirt emulated NVMe device support for devstack https://review.opendev.org/c/openstack/cyborg/+/977083 | |
| 07:13:56 | chandankumar | sean-k-mooney: https://123b844dd0bc940cd071-d2975a8f065f970ca29e743c021b8a36.ssl.cf1.rackcdn.com/openstack/5f698c9d53e44e52bbd22509f59b8b25/testr_results.html tempest test is working now with nvmevirt and pci-sim | |
| 07:30:58 | opendevreview | chandan kumar proposed openstack/cyborg-tempest-plugin master: [WIP] Add cyborg pci nvme test https://review.opendev.org/c/openstack/cyborg-tempest-plugin/+/979847 | |
| 07:32:38 | opendevreview | chandan kumar proposed openstack/cyborg-tempest-plugin master: [WIP] Add cyborg pci nvme test https://review.opendev.org/c/openstack/cyborg-tempest-plugin/+/979847 | |
| 07:40:13 | opendevreview | chandan kumar proposed openstack/cyborg-tempest-plugin master: [WIP] Add cyborg pci nvme test https://review.opendev.org/c/openstack/cyborg-tempest-plugin/+/979847 | |
| 07:40:47 | chandankumar | revived the old nvmevirt scenario tests, might not be ready for review, but seems to be working | |
| 07:41:08 | chandankumar | for pci-sim | |
| 07:44:13 | opendevreview | chandan kumar proposed openstack/cyborg-tempest-plugin master: [WIP] Add cyborg pci nvme test https://review.opendev.org/c/openstack/cyborg-tempest-plugin/+/979847 | |
| 10:02:03 | opendevreview | chandan kumar proposed openstack/cyborg-tempest-plugin master: [WIP] Add cyborg pci nvme test https://review.opendev.org/c/openstack/cyborg-tempest-plugin/+/979847 | |
| #openstack-cyborg - 2026-06-19 | |||
| 04:56:28 | opendevreview | chandan kumar proposed openstack/cyborg-specs master: Add generic NVMe driver spec with secure cleanup https://review.opendev.org/c/openstack/cyborg-specs/+/985349 | |
| 05:22:33 | opendevreview | chandan kumar proposed openstack/cyborg-specs master: Add generic NVMe driver spec with secure cleanup https://review.opendev.org/c/openstack/cyborg-specs/+/985349 | |
| #openstack-cyborg - 2026-06-22 | |||
| 06:09:32 | opendevreview | chandan kumar proposed openstack/cyborg-specs master: Add generic NVMe driver spec with secure cleanup https://review.opendev.org/c/openstack/cyborg-specs/+/985349 | |
| 09:44:19 | chandankumar | sean-k-mooney: Hello | |
| 09:44:29 | sean-k-mooney | o/ | |
| 09:44:32 | chandankumar | I wanted to discuss about nvme cleanup fallback strategy. | |
| 09:44:41 | chandankumar | In previous draft spec, we were checking whether the driver supports which of the cleaning strategy: nvme sanitize (CES, BES, OWS) or nvme format(SES2, SES1). If not then we can move it shred or dd. But shred or dd is not gurantee secure erase. | |
| 09:44:51 | chandankumar | Since In libvirt emuluted nvme, it supports SES2 and SES1. SES2 performs cypto erase | |
| 09:44:59 | chandankumar | It is the last cleaning strategy available for testing right now in our emulated env. | |
| 09:45:05 | sean-k-mooney | secure erase is not the goal | |
| 09:45:05 | chandankumar | Here is what I was thinking about new cleanup strategy: | |
| 09:45:16 | sean-k-mooney | cleaning is | |
| 09:45:22 | chandankumar | nvme sanitize (CES, BES, OWS) then nvme format(SES2) if not supported then move the device to error state and let' operator decide what to do that. | |
| 09:45:30 | sean-k-mooney | no | |
| 09:45:46 | sean-k-mooney | either we only suprpot device with sanitize | |
| 09:46:06 | sean-k-mooney | or we have a fallback that works for all devices | |
| 09:46:17 | sean-k-mooney | but its not ok for use to provision a device to a vm that we cant clean | |
| 09:46:28 | sean-k-mooney | we coudl use nvme format | |
| 09:46:49 | sean-k-mooney | but if the device will alwasy end up in error then we shoudl not allow ti to be managed by cybrog | |
| 09:47:42 | sean-k-mooney | also while we can have teird cleaning levels we should not fallback at runtime | |
| 09:48:35 | sean-k-mooney | we shoudl discover the clenaing supprot level and or allow specify the cleaning mode via the config but we shoudl only attpemt one method of cleaning in the runtime path | |
| 09:49:01 | sean-k-mooney | shread/dd woudl jusut overrite the entirly block device if we use that path | |
| 09:49:49 | sean-k-mooney | that is what we do for lvm volumes in cidner and nova | |
| 09:50:03 | chandankumar | Not all devices support nvme format also | |
| 09:50:17 | sean-k-mooney | right which is why im not really that intersted in supproting that | |
| 09:50:48 | sean-k-mooney | dd/sheread is a universal method that will work its just slow and consumes a full driver write cycle | |
| 09:51:29 | chandankumar | in that case, we have two options 1. use fallback as shread or dd (just like nova or cinder) or 2. provide cleanup method via config | |
| 09:51:59 | chandankumar | But if we pass the cleanup method via config, how os-triats will report to placement here | |
| 09:52:20 | sean-k-mooney | we woudl filter the triat based on the selected cleanup method | |
| 09:52:22 | chandankumar | if it might be something else other than snaitize or dd/shread | |
| 09:52:35 | sean-k-mooney | it wont be arbaitary | |
| 09:53:07 | sean-k-mooney | it would be and enuma of "sanitize", "format" or "zero" | |
| 09:53:14 | sean-k-mooney | zero beign shread or dd | |
| 09:53:34 | chandankumar | ok, in that case it will work | |
| 09:54:52 | sean-k-mooney | i have no interest in allowing oeprator to pass a cleaning command | |
| 09:55:03 | sean-k-mooney | that is a security nightmare so while i am ok with them chooing a policy | |
| 09:55:33 | sean-k-mooney | im not ok with giving them free rain to plug in anything they want fro the cleaning command | |
| 09:55:48 | sean-k-mooney | we can also supprot an auto value as the default | |
| 09:56:03 | sean-k-mooney | where we will use the best/fasted method the device supprots | |
| 09:56:45 | chandankumar | yes, that source better | |
| 09:56:49 | sean-k-mooney | so the config option (in the device-spec) would not be required its just an overried if the operaotr need to set it for soem reason i.e. there device is buggy | |
| 09:57:24 | chandankumar | so the cleanup option would be auto, santitize, format, zero | |
| 09:57:49 | sean-k-mooney | yep i think that woudl work again we can decied if we want to suprpot format or not | |
| 09:58:09 | sean-k-mooney | but that somethign we can refine at implemation time | |
| 09:58:13 | chandankumar | perfect | |
| 09:58:23 | sean-k-mooney | how common is it that sanatize is not supproted these days | |
| 09:59:39 | sean-k-mooney | most read intensive ssd are rated at 1 total drive write per day DWPD wer as mixed use drives are rated at 10 adn write intensive deves at 25+ | |
| 10:00:13 | sean-k-mooney | so on a moder driver just zeroing it with dd/shred is not terible for the lifetime of the drive | |
| 10:00:24 | sean-k-mooney | and if your passing a drive to a vm they can do that anyway | |
| 10:01:08 | sean-k-mooney | so i think having "zero" as the work for anything fallback is fine for legacy drives but i suspect almost everyting will work with on eof the sanitize levels | |
| 10:03:39 | sean-k-mooney | we could also looks at blockdiscard/trim but we can dicuss that later when it comes to reiving the zero implemation | |
| 10:04:20 | chandankumar | nvme sanitize was added nvme 1.3 specification, these days most of the nvme device comes with nvme 2.0 | |
| 10:04:25 | chandankumar | it should have sanitize | |
| 10:04:39 | sean-k-mooney | right that my thinkign as well | |
| 10:05:10 | chandankumar | The I have in my laptop have , it does not support cyrpot erase | |
| 10:05:40 | chandankumar | Block Erase Sanitize Operation Supported | |
| 10:06:59 | sean-k-mooney | ya so again cyrpto erase is nice to have but not required | |
| 10:07:18 | sean-k-mooney | if you want encypted storage you should just add luks on top of the nvme device in the gust | |
| 10:07:32 | sean-k-mooney | an not rely on the device cleaning to do that for you | |
| 10:08:00 | chandankumar | yes adding luks wuld do the job | |
| 10:08:09 | chandankumar | let me update the spec based on above discussion | |
| 10:08:13 | chandankumar | thank you! | |
| 10:08:15 | sean-k-mooney | my intuition is to just supprot sanatize and zero by the way | |
| 10:08:20 | sean-k-mooney | and skip format entirly | |
| 10:09:29 | sean-k-mooney | i do not like that format only works on the first namespace | |
| 10:09:42 | sean-k-mooney | or if a namespace still exists | |
| 10:10:19 | chandankumar | sure, I will drop format | |
| 10:11:22 | sean-k-mooney | cool any other question on any of the feedback i left on the spec? | |
| 10:11:43 | sean-k-mooney | ill try and do anohter full pass over it in the next day or two | |
| 10:11:48 | chandankumar | nope rest of them I have address | |
| 10:11:59 | chandankumar | I will try to get it updated by eod or tomorrow morning | |
| 10:12:15 | sean-k-mooney | cool ill plan to take a look tomorow or wednesday so | |
| 10:12:36 | sean-k-mooney | assuming there are no other issues and we are mostly aligned we will probly merge it end ro week or early next week | |
| 10:18:22 | chandankumar | sounds good | |
| 10:26:45 | sean-k-mooney | so thinking about this i wonder if cypto erase need to be configurable. the block erase version of sanitize and format is actully more secure then cypto erase alone | |
| 10:26:58 | sean-k-mooney | so we could consider 2 tuneable | |
| 10:27:30 | sean-k-mooney | clear_mode=block|crypto clear_method=sanatize|zero | |
| 10:28:04 | sean-k-mooney | clear_mode=block|crypto|auto clear_method=sanatize|zero|auto | |
| 10:28:41 | sean-k-mooney | chandankumar: it really is 2 seperate question so i think that might be a better way to model it | |
| 10:29:12 | sean-k-mooney | chandankumar: apprenly there is also a nvme write-zeroes command | |
| 10:29:38 | sean-k-mooney | chandankumar: so we can use that instead of dd or shred for the zero fallback if supproted | |
| 10:30:49 | chandankumar | yes, The Write Zeroes command is used to set a range of logical blocks to zero. | |
| 10:31:31 | sean-k-mooney | yep but it can zeor the entire device and its doe by the cornoler rather then the cpu | |
| 10:32:04 | sean-k-mooney | so in zero mode waht we could do is delete all namespace, create 1 namespace that cover the entire device and then zero it with write-zeors | |
| 10:32:17 | sean-k-mooney | i also think we need to do that namespace reset in general | |
| 10:32:42 | sean-k-mooney | so as part of cleaning we will need to ensure we have restored teh defivce to havign 1 namespace that uses the entire device | |
| 10:33:10 | sean-k-mooney | in case the tenatn had reconfigured it to soemthing else | |
| 10:34:40 | chandankumar | sudo nvme id-ctrl /dev/nvme0n1 -H | grep -A 10 "oncs" | |
| 10:34:42 | chandankumar | oncs : 0xdf | |
| 10:34:44 | chandankumar | [12:12] : 0 Namespace Zeroes Not Supported | |