Repository: kubernetes
Issue: pv is bound to pvc, but pvc is pending
Labels: kind/bug,sig/storage,needs-triage

### What happened?

I have a pvc1: `tmp-pvc-1d9c5916-c994-42e5-8060-99d563b43e3a`,  and bound to pv: `pvc-a4ec28db-8fed-4067-8a19-ba0ff65b4996`. I changed the claimRef of pv:`pvc-a4ec28db-8fed-4067-8a19-ba0ff65b4996` to pvc2:`f55bp1pq6y`, pv status is bound and bound to pvc2:`f55bp1pq6y`. But pvc2:`f55bp1pq6y` status is still pending, and pvc1:`tmp-pvc-1d9c5916-c994-42e5-8060-99d563b43e3a` status is lost.
```
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  annotations:
    cdi.kubevirt.io/clonePhase: Pending
    cdi.kubevirt.io/cloneType: csi-clone
    cdi.kubevirt.io/createdForDataVolume: 417bdae0-3eb3-4be1-a438-fcf972d7a0ff
    cdi.kubevirt.io/dataSourceNamespace: default
    cdi.kubevirt.io/storage.clone.token: eyJhbGciOiJQUzI1NiJ9.eyJleHAiOjE3MzA4MDQwOTksImlhdCI6MTczMDgwMzc5OSwiaXNzIjoiY2RpLWFwaXNlcnZlciIsIm5hbWUiOiJpbWctZjlqc242ZXMtY2VwaC1ibG9jayIsIm5hbWVzcGFjZSI6ImRlZmF1bHQiLCJuYmYiOjE3MzA4MDM3OTksIm9wZXJhdGlvbiI6IkNsb25lIiwicGFyYW1zIjp7InRhcmdldE5hbWUiOiJ2NzFnYmF1bXkzIiwidGFyZ2V0TmFtZXNwYWNlIjoid3l3LXRlc3QtZHYifSwicmVzb3VyY2UiOnsiZ3JvdXAiOiIiLCJyZXNvdXJjZSI6InBlcnNpc3RlbnR2b2x1bWVjbGFpbXMiLCJ2ZXJzaW9uIjoidjEifX0.SUaSFke9zXFcNDVLD1eM_3RrdbYl1qkmXROeshIbaP_ltrklDouOalJk7sROjGjTKDsUhdKqPfvjnNauM1JWxR1fGjzTuPi-GJVK8W9l8U9N6BTyze9swf4lsZMp0pY1GhFuqbPubfSvvUxvmQkg4Tc2GPGqCUYcm22w3N2zl5xBzGRi4Ugsr4vWdttu-ajTSlAb966LOL598AI5XUIDdOdL6wiu9QtHfR39amvRgxWpl_powtQlC1w8Jj0xta1I3BcGypi_KHhK6L36W7nJk6ko_-E0nxpNSy1bHzK_N8no0a3jYQJ1Sl0320aeeLvFwMB6BwIcCFttkLHjZ2opWA
    cdi.kubevirt.io/storage.condition.running: "false"
    cdi.kubevirt.io/storage.condition.running.message: Clone Pending
    cdi.kubevirt.io/storage.condition.running.reason: Pending
    cdi.kubevirt.io/storage.contentType: kubevirt
    cdi.kubevirt.io/storage.pod.restarts: "0"
    cdi.kubevirt.io/storage.populator.kind: VolumeCloneSource
    cdi.kubevirt.io/storage.preallocation.requested: "false"
    cdi.kubevirt.io/storage.usePopulator: "true"
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"cdi.kubevirt.io/v1beta1","kind":"DataVolume","metadata":{"annotations":{},"name":"v71gbaumy3","namespace":"wyw-test-dv"},"spec":{"pvc":{"accessModes":["ReadWriteOnce"],"resources":{"requests":{"storage":"50Gi"}},"storageClassName":"ceph-block","volumeMode":"Block"},"source":{"pvc":{"name":"img-f9jsn6es-ceph-block","namespace":"default"}}}}
    pv.kubernetes.io/bind-completed: "yes"
    pv.kubernetes.io/bound-by-controller: "yes"
    volume.beta.kubernetes.io/storage-provisioner: rook-ceph.rbd.csi.ceph.com
    volume.kubernetes.io/storage-provisioner: rook-ceph.rbd.csi.ceph.com
  creationTimestamp: "2024-11-05T10:50:07Z"
  finalizers:
  - kubernetes.io/pvc-protection
  labels:
    app: containerized-data-importer
    app.kubernetes.io/component: storage
    app.kubernetes.io/managed-by: cdi-controller
    cdi.kubevirt.io/OwnedByUID: e80fc9be-821f-452a-9b03-bb5bbadb5094
  name: tmp-pvc-1d9c5916-c994-42e5-8060-99d563b43e3a
  namespace: default
  resourceVersion: "10612580"
  uid: 11ee3bfa-a558-4464-9466-dc6d6fb6047c
spec:
  accessModes:
  - ReadWriteOnce
  dataSource:
    apiGroup: null
    kind: PersistentVolumeClaim
    name: img-f9jsn6es-ceph-block
  dataSourceRef:
    apiGroup: null
    kind: PersistentVolumeClaim
    name: img-f9jsn6es-ceph-block
  resources:
    requests:
      storage: 50Gi
  storageClassName: ceph-block
  volumeMode: Block
  volumeName: pvc-a4ec28db-8fed-4067-8a19-ba0ff65b4996
status:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 50Gi
  phase: Bound
```
after updating pv claimRef to pvc2:`f55bp1pq6y`:
```
# kubectl get pvc | grep -i lost
tmp-pvc-1d9c5916-c994-42e5-8060-99d563b43e3a   Lost      pvc-a4ec28db-8fed-4067-8a19-ba0ff65b4996   0                         ceph-block     153m

[root@rongqi-node01 batch-create]# kubectl get pv pvc-a4ec28db-8fed-4067-8a19-ba0ff65b4996 
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                    STORAGECLASS   REASON   AGE
pvc-a4ec28db-8fed-4067-8a19-ba0ff65b4996   40Gi       RWO            Retain           Bound    wyw-test-dv/f55bp1pq6y   ceph-block              158m
```

### What did you expect to happen?

after updating pv claimRef to pvc2:`f55bp1pq6y`, pvc2:`f55bp1pq6y` status is bound.

### How can we reproduce it (as minimally and precisely as possible)?

I encountered this problem when using the cdi project:
[https://github.com/kubevirt/containerized-data-importer/issues/3470](url)

### Anything else we need to know?

_No response_

### Kubernetes version

<details>

```console
$ kubectl version
WARNING: This version information is deprecated and will be replaced with the output from kubectl version --short.  Use --output=yaml|json to get the full version.
Client Version: version.Info{Major:"1", Minor:"27", GitVersion:"v1.27.6", GitCommit:"741c8db18a52787d734cbe4795f0b4ad860906d6", GitTreeState:"clean", BuildDate:"2023-09-13T09:21:34Z", GoVersion:"go1.20.8", Compiler:"gc", Platform:"linux/amd64"}
Kustomize Version: v5.0.1
Server Version: version.Info{Major:"1", Minor:"27", GitVersion:"v1.27.6", GitCommit:"741c8db18a52787d734cbe4795f0b4ad860906d6", GitTreeState:"clean", BuildDate:"2023-09-13T09:14:09Z", GoVersion:"go1.20.8", Compiler:"gc", Platform:"linux/amd64"}

```

</details>


### Cloud provider

<details>

</details>


### OS version

<details>

```console
# On Linux:
$ cat /etc/os-release
# centos 8
$ uname -a
5.10.0-136.12.0.86.4.hl202.x86_64


</details>


### Install tools

<details>

</details>


### Container runtime (CRI) and version (if applicable)

<details>

</details>


### Related plugins (CNI, CSI, ...) and versions (if applicable)

<details>
# kubectl exec -it -n rook-ceph rook-ceph-tools-5877f9f669-n8nfb -- ceph --version
ceph version 18.2.1 (7fe91d5d5842e04be3b4f514d6dd990c54b29c76) reef (stable)
</details>