| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2026-06-17 | |||
| 12:59:04 | chandankumar | The error I hit earier while enabling cyborg then I hit while enabling both nova and cyborg | |
| 13:05:22 | sean-k-mooney | chandankumar: so my current todo list for that moduel was add the ablity to create mdevs, add the ablity to emulate an e1000 nic adn then possibel add the ablity to emulate an nvme device | |
| 13:05:52 | sean-k-mooney | the secodn two are more asperationall but i think ti woudl be possibel to do by reusing some of the nvmevirt work | |
| 13:06:26 | sean-k-mooney | but im not currently willing to commit to the latter in a short itme frame becasue that is very non tirival | |
| 13:07:03 | sean-k-mooney | addign the ablity for the PFs to supprot mdpy mdevs shoudl be realitivly simple | |
| 13:07:28 | sean-k-mooney | emulating a nic that works enough for neturon sriov testing is somewhere in between | |
| 13:07:44 | sean-k-mooney | we dont stricly need that but it is simpler then pretending to be a nvme device | |
| 13:31:29 | chandankumar | nmvevirt has no iommu group support On which I am kind of blocked to see nvme with in the guest . From pci-sim work, I think i can reuse some of your work to add the support there | |
| 13:32:23 | chandankumar | or I can do opposite, take some of the work from nvmevirt and add it into pci-sim | |
| 13:32:29 | chandankumar | But I need to think on that | |
| 13:33:02 | chandankumar | on another note, I was writting some tests to validate cyborg placemnt workflow with pci scenario test https://review.opendev.org/c/openstack/cyborg-tempest-plugin/+/992210 it might be useful | |
| 13:33:23 | chandankumar | I will update my above review with pci-sim work for the tempest tests | |
| 13:33:26 | chandankumar | brb | |
| 13:46:51 | sean-k-mooney | oh cool | |
| 13:47:35 | sean-k-mooney | ya i was plannign to focus on scenairo test to validate the vm lifecycle | |
| 13:47:50 | sean-k-mooney | so the placmeent reporting tests will complement that | |
| 14:02:44 | opendevreview | Merged openstack/cyborg master: devstack: add pci-sim fake SR-IOV PCI passthrough test fixture https://review.opendev.org/c/openstack/cyborg/+/989470 | |
| 14:02:46 | opendevreview | Merged openstack/cyborg master: Add pci-sim developer guide https://review.opendev.org/c/openstack/cyborg/+/991177 | |
| 14:55:44 | opendevreview | chandan kumar proposed openstack/cyborg master: Rename devstack CYBORG_CONF_FILE to CYBORG_CONF for consistency https://review.opendev.org/c/openstack/cyborg/+/979805 | |
| 14:55:45 | opendevreview | chandan kumar proposed openstack/cyborg master: Add NVMeVirt emulated NVMe device support for devstack https://review.opendev.org/c/openstack/cyborg/+/977083 | |
| 14:57:40 | opendevreview | chandan kumar proposed openstack/cyborg master: Add NVMeVirt emulated NVMe device support for devstack https://review.opendev.org/c/openstack/cyborg/+/977083 | |
| 15:30:27 | opendevreview | chandan kumar proposed openstack/cyborg master: Rename devstack CYBORG_CONF_FILE to CYBORG_CONF for consistency https://review.opendev.org/c/openstack/cyborg/+/979805 | |
| 15:30:28 | opendevreview | chandan kumar proposed openstack/cyborg master: Add NVMeVirt emulated NVMe device support for devstack https://review.opendev.org/c/openstack/cyborg/+/977083 | |
| #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 | |