So the CLI Reference is not very clear. If I am moving a volume to an NAE aggregate and specify the -encrypt-destination true, will it encrypt with a volume key or aggregate key?
#Difference between -encrypt-destination and -encrypt-with-aggregate-key during volume move
grave zealot
potent bronze
if you are using "volume move" and the -encrypt-destination, it will be volume encrypted
If you use -encrypt-with-aggr-key true that will encrypt the volume with the aggr key as an NAE volume
grave zealot
Even when the destination-aggregate is NAE?
Documenation also states every volume on an NAE aggregate will be NAE encrypted; I don't understand
potent bronze
so, with NAE all of the volumes on the aggregate have to be either aggr level or volume level
NAE encrypted volumes can use dedupe and it uses the aggr key
NVE is not
(dedupe that is)
grave zealot
I understand, but why would I create an NAE and use NVE; I just don't see the case
potent bronze
key use.
grave zealot
But by that logic, I should be able to move non-encrypted volumes to NAE's
potent bronze
no, when you move a volume to NAE it will auto-encrypt it with the aggregate key
NAE only allows encrypted volumes, but the key being used can be decided
grave zealot
Yes, except that now I have petabytes of volumes on NAE's that can't take advantage of NAE efficiencies
potent bronze
you moved them with -encrypt-dest? you can remove that with another move, in place. slower, but still
grave zealot
PB's worth? No. That was the dumbest thing NetApp did; if I create an NAE it should default to NAE keys, not NVE keys
potent bronze
it does, automatically
grave zealot
Or at least that should be the default, unless overriden
potent bronze
if the encryption license is installed, every aggregate created is NAE enabled, and everything put on that aggregate uses that key
by default
grave zealot
But not if you use the -encrypt-destination true parameter, which is what we've been using... There should be a warning or something that using that parameter will not get you NAE, is what I'm suggesting
In-place encryption does not work on a PB volume, or at least crawls so slow it is unusable...;)
potent bronze
we generally get warnings indicating a volume being moved is moving to a volume that doesn't support dedupe/etc.
Not sure why you wouldn't have gotten them, i don't think we have any settings specific for that
grave zealot
Perhaps in later releases... I am still on 9.14.1
potent bronze
The volume is enabled for inline deduplication, and this command will move it with no support for inline deduplication
(it is neither an AFFP nor a Flash Pool aggregate). Inline deduplication will be disabled. Do you want to continue? {y|n}
that's the message we get
grave zealot
That is dedup, not sure where NAE comes into play; I don't get such a message
potent bronze
running CVO, so dedupe is all we can get
potent bronze
cloud volume ontap
zenith finch
Bottom line here
When the aggregate has encrypt with aggregate key enabled, any volume on the aggregate must be encrypted. Period. With nae or NVE but must be encrypted
After the key manager is enabled, any newly created aggregates will have the encrypt with aggr key enabled. When you create any new volumes, ONTAP will automatically encrypt with aggregate key UNLESS you specify otherwise.
When you move volumes with encryption you must be cognizant of what you want the destination to be. Encrypt-destination will set NVE and encrypt-with-aggr-key will set NAE.
grave zealot
It would be nice if there was a warning or more information in the documentation
patent axle
The documentation seems to imply that if you have an aggregate with NAE enabled, it should not matter if you move volumes to it with -encrypt-destination or -encrypt-with-aggr-key and in both cases you should get the volume encrypted with the NAE key and participating in dedup
(this is from the "NetApp Volume Encryption and NetApp Aggregate Encryption Technical FAQ for ONTAP 9.14.1" from April 2024)
potent bronze
from the ontap docs
benefit of NAE is that volumes are included in aggregate level deduplication, whereas NVE volumes are excluded.
patent axle
yeah, that doesn't contradict the screenshot above 🙂
The screenshot just says that if you do -encrypt-destionation true or -encrypt-with-aggr-key true, you get an NAE volume. There might be other ways to get an NVE volume (that then obviously doesn't participate in aggr-wide dedup), for example by using the combination -encrypt-destination true -encrypt-with-aggr-key false or something
But my (naive?) assumptions about how ONTAP hsould work have been challenged in the past. I would have thought that as soon as you move any volume into an NAE aggregate, even without specifying any -encrypt... parameters, it would be NAE encrypted. But reading all that makes me wonder if that really is the case 🙂 time to deploy another VSIM I guess 😄
potent bronze
pretty sure everyting you move to NAE is using the aggr key, but to use NVE you have to use the -encrypt-destination true, as that triggers volume level encryption
patent axle
pretty sure everyting you move to NAE is using the aggr key, but to use NVE you ...
then that document I posted above is incorrect?
potent bronze
no clue, the stuff i posted was just from the current docs
karmic beacon
Afaik if you move a plaintext vol to an NAE-enabled aggr without adding anything like -encrypt-destination or -encrypt-with-aggr-key it will be a NAE-volume.
If you add -encrypt-destination true it should still result in a NAE-volume imo.
Only when using -encrypt-with-aggr-key false it should result in a NVE-volume.
Can you check if you really have NVE-volumes on your NAE-aggr:
aggr show -fields encrypt-with-aggr-key
vol show -fields encryption-type -sort-by encryption-type
Tried it, even though it was moved to an NAE, the vollumes are of volume-encryption-type
The only volume that is of aggregate encryption is the vserver root I moved and specified -encrypt-with-aggr-key
zenith finch
You cannot specify both options as true. One will force nae and the other will force NVE. Go ahead and try it. I did. It fails.
The other way though setting both to false…have not tried that but usually you just set encrypt-destination to false to unencrypt the volume
ONTAP responds differently depending on the source tie and destination type