I had the same problem and believe the issue is that you probably have a trap server configured and are using the same snmp-server group for the trap server and your queries. I created another group for SNMPv3 queries and the configuration no longer seems to get overwritten. Here's what I did.
Go into config mode and create a group just for the trap server - let's call it TRAPS. I used priv and it looks like that's what you use. Don't worry about defining any MIB views as this group will automatically populate the notifyview once the trap servers below are added to the config. (...and will remove the readview and writeview entries after reboot - that's why a second group is needed). Remove your old trap server entries and set up the new trap server using the new group called TRAPS.
snmp-server group TRAPS v3 priv
snmp-server host version 3 priv TRAPS
Now create another group for queries only - (let's call it QUERIES but you could just use your current group XXX since it's already set up) - I like the v1default MIB view for both reads and writes but you can limit the MIBs with the snmp-server view command. I am using md5 and des56 here - your case may be different - and set up the user (or keep the one you already have configured)
snmp-server group QUERIES v3 priv read v1default write v1default access
snmp-server user QUERIES v3 auth md5 priv des56
Exit and check the config.
The group TRAPS should have the notifyview set. The group QUERIES should have the readview and writeview set to v1default (or whatever view you chose to enter here). The two SNMPv3 groups should look like this:
#sh snmp group
groupname: TRAPS security model:v3 priv
readview : writeview:
notifyview: *tv.FFFFFFFF.FFFFFFFF.FFFFFFFF.F
row status: active
groupname: QUERIES security model:v3 priv
readview : v1default writeview: v1default
notifyview:
row status: active access-list: 4
The old trap server entry using the old group XXX should have been removed already. Verify that the user: entry says TRAPS
#sh snmp host
Notification host: xxx.xxx.xxx.xxx udp-port: 162 type: trap
user: TRAPS security model: v3 priv
Finally make sure the user is in the correct group (QUERIES):
#sh snmp user
User name:
Engine ID: xxxxxxxxxxxxxxxxxxxxxxxxxx
storage-type: nonvolatile active
Authentication Protocol: MD5
Privacy Protocol: DES
Group-name: QUERIES
If all is well - write the config. You should now be able to perform a coldstart without losing your SNMPv3 config.
Please, let me know if this worked for you.
