kubevirt failed to encrypt storage classes using ceph-csi rbd #3945
Assignees
Labels
Comments
|
Could you add the following annotation to the StorageClass and try again? |
nixpanic
added
question
Thank you for the information |
|
The volume should be of AccessType Block (as opposed to Filesystem) for VMs, that seems fine: Mapping the rbd-image and decrypting seems to work too, but resizing fails: Because the volume has accesstype=Block, a resize of the filesystem (if any) on the block device should not get attempted. This could be a bug in the NodeStageVolume procedure. |
|
I think this could make it work: diff --git a/internal/rbd/nodeserver.go b/internal/rbd/nodeserver.go
index 825f9bc61..7fcdb8166 100644
--- a/internal/rbd/nodeserver.go
+++ b/internal/rbd/nodeserver.go
@@ -512,6 +512,11 @@ func resizeNodeStagePath(ctx context.Context,
if err != nil {
return status.Error(codes.Internal, err.Error())
}
+
+ // if this is a AccessType=Block volume, do not attempt filesystem resize
+ if isBlock {
+ return nil
+ }
}
// check stagingPath needs resize.
ok, err = resizer.NeedResize(devicePath, stagingTargetPath)Are you comfortable applying that change to the devel branch and building a test image? If not, I can create an image for you too (likely tomorrow or next week). |
Yes, I modified and tested my virtual machine according to your suggestion, and it worked. |
|
The issue that you have seen is related to the following, rather uncommon (but perfectly valid) scenario:
This particular case was not handled in the |
nixpanic
added a commit
to nixpanic/ceph-csi
that referenced
this issue
Jun 30, 2023
When a volume has AccessType=Block and is encrypted with LUKS, a resize of the filesystem on the (decrypted) block-device is attepmted. This should not be done, as the application that requested the Block volume is the only authoritive reader/writer of the data. In particular VirtualMachines that use RBD volumes as a disk, usually have a partition table on the disk, instead of only a single filesystem. The `resizefs` command will not be able to resize the filesystem on the block-device, as it is a partition table. When `resizefs` fails during NodeStageVolume, the volume is unstaged and an error is returned. Resizing an encrypted block-device requires `cryptsetup resize` so that the LUKS header on the RBD-image is updated with the correct size. But there is no need to call `resizefs` in this case. Fixes: ceph#3945 Signed-off-by: Niels de Vos <ndevos@ibm.com>
nixpanic
added a commit
to nixpanic/ceph-csi
that referenced
this issue
Jun 30, 2023
When a volume has AccessType=Block and is encrypted with LUKS, a resize of the filesystem on the (decrypted) block-device is attempted. This should not be done, as the application that requested the Block volume is the only authoritive reader/writer of the data. In particular VirtualMachines that use RBD volumes as a disk, usually have a partition table on the disk, instead of only a single filesystem. The `resizefs` command will not be able to resize the filesystem on the block-device, as it is a partition table. When `resizefs` fails during NodeStageVolume, the volume is unstaged and an error is returned. Resizing an encrypted block-device requires `cryptsetup resize` so that the LUKS header on the RBD-image is updated with the correct size. But there is no need to call `resizefs` in this case. Fixes: ceph#3945 Signed-off-by: Niels de Vos <ndevos@ibm.com>
Thank you for everything you 've done for this |
nixpanic
added a commit
to nixpanic/ceph-csi
that referenced
this issue
Jul 3, 2023
When a volume has AccessType=Block and is encrypted with LUKS, a resize of the filesystem on the (decrypted) block-device is attempted. This should not be done, as the application that requested the Block volume is the only authoritive reader/writer of the data. In particular VirtualMachines that use RBD volumes as a disk, usually have a partition table on the disk, instead of only a single filesystem. The `resizefs` command will not be able to resize the filesystem on the block-device, as it is a partition table. When `resizefs` fails during NodeStageVolume, the volume is unstaged and an error is returned. Resizing an encrypted block-device requires `cryptsetup resize` so that the LUKS header on the RBD-image is updated with the correct size. But there is no need to call `resizefs` in this case. Fixes: ceph#3945 Signed-off-by: Niels de Vos <ndevos@ibm.com>
mergify bot
pushed a commit
that referenced
this issue
Jul 3, 2023
When a volume has AccessType=Block and is encrypted with LUKS, a resize of the filesystem on the (decrypted) block-device is attempted. This should not be done, as the application that requested the Block volume is the only authoritive reader/writer of the data. In particular VirtualMachines that use RBD volumes as a disk, usually have a partition table on the disk, instead of only a single filesystem. The `resizefs` command will not be able to resize the filesystem on the block-device, as it is a partition table. When `resizefs` fails during NodeStageVolume, the volume is unstaged and an error is returned. Resizing an encrypted block-device requires `cryptsetup resize` so that the LUKS header on the RBD-image is updated with the correct size. But there is no need to call `resizefs` in this case. Fixes: #3945 Signed-off-by: Niels de Vos <ndevos@ibm.com>
mergify bot
pushed a commit
that referenced
this issue
Jul 3, 2023
When a volume has AccessType=Block and is encrypted with LUKS, a resize of the filesystem on the (decrypted) block-device is attempted. This should not be done, as the application that requested the Block volume is the only authoritive reader/writer of the data. In particular VirtualMachines that use RBD volumes as a disk, usually have a partition table on the disk, instead of only a single filesystem. The `resizefs` command will not be able to resize the filesystem on the block-device, as it is a partition table. When `resizefs` fails during NodeStageVolume, the volume is unstaged and an error is returned. Resizing an encrypted block-device requires `cryptsetup resize` so that the LUKS header on the RBD-image is updated with the correct size. But there is no need to call `resizefs` in this case. Fixes: #3945 Signed-off-by: Niels de Vos <ndevos@ibm.com> (cherry picked from commit f60a358)
nixpanic
added a commit
that referenced
this issue
Jul 4, 2023
When a volume has AccessType=Block and is encrypted with LUKS, a resize of the filesystem on the (decrypted) block-device is attempted. This should not be done, as the application that requested the Block volume is the only authoritive reader/writer of the data. In particular VirtualMachines that use RBD volumes as a disk, usually have a partition table on the disk, instead of only a single filesystem. The `resizefs` command will not be able to resize the filesystem on the block-device, as it is a partition table. When `resizefs` fails during NodeStageVolume, the volume is unstaged and an error is returned. Resizing an encrypted block-device requires `cryptsetup resize` so that the LUKS header on the RBD-image is updated with the correct size. But there is no need to call `resizefs` in this case. Fixes: #3945 Signed-off-by: Niels de Vos <ndevos@ibm.com> (cherry picked from commit f60a358)
mergify bot
pushed a commit
that referenced
this issue
Jul 4, 2023
When a volume has AccessType=Block and is encrypted with LUKS, a resize of the filesystem on the (decrypted) block-device is attempted. This should not be done, as the application that requested the Block volume is the only authoritive reader/writer of the data. In particular VirtualMachines that use RBD volumes as a disk, usually have a partition table on the disk, instead of only a single filesystem. The `resizefs` command will not be able to resize the filesystem on the block-device, as it is a partition table. When `resizefs` fails during NodeStageVolume, the volume is unstaged and an error is returned. Resizing an encrypted block-device requires `cryptsetup resize` so that the LUKS header on the RBD-image is updated with the correct size. But there is no need to call `resizefs` in this case. Fixes: #3945 Signed-off-by: Niels de Vos <ndevos@ibm.com> (cherry picked from commit f60a358)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
When using an encrypted StorageClass (SC) to create an RBD device with ceph-csi and using it in a kubevirt virtual machine, the following error occurs during volume mapping:
Environment details
fuseorkernel. for rbd itskrbdorrbd-nbd) :Steps to reproduce
Steps to reproduce the behavior:
user-secret.yaml
kms-config.yaml
stroageclass.yaml
2.Configure virtual machine files
Actual results
Expected behavior
successfully mounted pvc to the virtual machine
Logs
If the issue is in PVC mounting please attach complete logs of below containers.
plugin pod from the node where the mount is failing.
csi-rbdplugin csi-rbdplugin log
csi-rbdplugin driver-registrar log
Note:- If its a rbd issue please provide only rbd related logs, if its a
cephFS issue please provide cephFS logs.
Additional context
Add any other context about the problem here.
For example:
Any existing bug report which describe about the similar issue/behavior
The text was updated successfully, but these errors were encountered: