ceph key migration on ceph-fs

freshdomi

Member
Oct 20, 2022
4
1
23
Hello,

i currently trying to rotate the keys of my ceph storage; all vms on all hosts have been rotated successfully exepect 4 hosts having the ceph-fs mount and i cant get them using the new keys.. i already tried Live Migration, Stop/Start the VM, Stopping all vms having the ceph-fs mount and umounted the ceph-fs on all px hosts.. nothing worked..
is there something i have missed?

next step would be Stopping the vms and start the script with the option '--confirm-all-clients-refreshed' and hoping that everything goes up again..



Code:
root@px01:~# /usr/share/pve-manager/migrations/pve-cephx-rotate-service-keys --rotate-all-storage-keys --rotate-admin-key --verbose
INFO: This is a dry run. No Ceph key, cipher setting, or daemon will be changed. Session observations can update the migration journal.
INFO: the new key of 'client.admin' is staged next to its current one; both authenticate until it is committed with '--confirm-clients-refreshed client.admin' or, once every open record is ready, '--confirm-all-clients-refreshed'
PASS: Every service key uses 'aes256k', and so do the service tickets.

Client keys awaiting action:
  'client.admin': 4 session(s) still authenticate with a previous key (172.26.233.46: 1,
    172.26.233.47: 1, 172.26.233.48: 1, 172.26.233.50: 1). Both keys remain valid. Refresh these
    clients, then rerun without options.
Refresh clients of the affected Ceph users:
  Live-migrate affected VMs to another up-to-date node with the new keyring, including VMs with
    kernel RBD disks. A guest reboot does not reload the key. Fully stop and start only VMs that
    cannot be migrated.
  Remount affected kernel CephFS mounts. A container on RBD keeps the key its disks were mapped
    with until it is fully stopped and started. Restart other clients after updating any external
    key copies.
The Ceph CLI and Proxmox VE storages without a dedicated user normally use 'client.admin'. VMs and mounts on those storages can retain its previous key.
Session absence does not prove that disconnected clients or external key copies were refreshed.