Resizing the PVC of OS volume does not reflect in the VM

[sanzende]

Is this a BUG REPORT or FEATURE REQUEST?:

Uncomment only one, leave it on its own line:

/kind bug

/kind enhancement

What happened: I did not find options to increase of the volume hence used the method described below.

Edited the pvc spec(yaml) that was created as part of virtctl image-upload command to increase the size from 80Gi to 100Gi. In the kubectl describe pvc it does show the modified value. If I exec into the pod that is hosting VM using the kubectl exec command, I see the increased size of the volume but but if I login to the VM which is running in this pod, I see the volume is still showing the old size(80Gi) in the output of fdisk and lsblk commands.

What you expected to happen:

The output of lsblk and/or fdisk command in the linux vm should have shown the new size.

How to reproduce it (as minimally and precisely as possible):

1. Create a Linux (for eg. Centos) VM using kubevirt wherein you upload centos.qcow2 image using the virtctl command which will create a PVC that will have centos.qcow2 image and apply VM spec file.
2. Start VM using virtctl start which will also create a pod to host a VM.
3. Log into the machine and verify the size of disk 'vda' (80Gi)
4. Stop VM using virtctl stop which will also delete the pod that was hosting the VM.
5. Edit the PVC that was created as part of virtctl image-upload command to reflect the new value(100Gi)
6. Start VM using virtctl command.
7. ssh to Centos VM and verify the disk which still shows 80Gi
8. kubectl exec to pod hosting the VM and verify the disk size. It shows the new value.

Anything else we need to know?:

Environment: -virtclt version: v0.30.6

KubeVirt version : v0.30.6 Kubernetes version : 1.16 VM or VMI specifications:

apiVersion: kubevirt.io/v1alpha3 kind: VirtualMachine metadata: name: centos1 spec: running: false template: metadata: labels: kubevirt.io/domain: centos1 spec: nodeSelector: kubernetes.io/hostname: test1 domain: ioThreadsPolicy: auto cpu: cores: 16 devices: blockMultiQueue: true disks: - disk: bus: virtio name: harddrive machine: type: q35 resources: requests: memory: 16G volumes: - name: harddrive persistentVolumeClaim: claimName: centos1-os

Cloud provider or hardware configuration: OS : CentOS Linux release 7.6.1810 (Core) Kernel : Linux appserv66 3.10.0-957.el7.x86_64 #1 SMP Thu Nov 8 23:39:32 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux Install tools: Others:

[awels]

I would say this is an enhancement not a bug. And we have this on our radar on how to provide a flow that gets you what you want, we just are not there yet. If you look at the actual disk inside the VM it is the new size. However the partition has not resized, and thus looking at the available space on the file system, nothing changed. You should be able to run pvresize inside the guest to resize the partition and increase the size available to the file system.

[sanzende]

Hi Alexander,

Is there a way to change this bug to enhancement?.

As I mentioned in the description above "I see the volume is still showing the old size(80Gi) in the output of fdisk and lsblk commands" . Should I be checking somewhere else too? Am I missing something here?

Thanks & Regards Sandeep

[awels]

lsblk should list the total size of the disk under (I am assuming its vda) and then the partitions should make up the 80Gi you are talking about.

I just re-read the steps you took. How are you 'editing' the PVC size? This? if so then currently CDI is not involved and will not resize the virtual disk to match.

[sanzende]

Yes. It is vda.

Yes I am using the same method you mentioned above. If CDI is not involved, then what is the way to resize the virtual disk containing OS?

[awels]

We are working on having CDI react to PVC resizes, but have not gotten around to implementing it. PVC is relatively new and not all storage classes support it yet. Only option I can give you (which is likely what CDI will do automatically when implemented) is to start a cdi-importer pod, mount the PVC in that pod, then exec into it and run qemu-img resize on the disk.img file.

[sanzende]

Thanks Alexander.

I gave a thought to resize disk.img using qemu-img resize command inside the pod(virt-launcher#) hosting the VM but I did not do yet but pardon for my ignorance, I haven't understood how resizing in cdi-importer pod will work and help. I think I will have to read more of cdi-importer.

[awels]

Well the CDI importer container has all the tools needed to do a disk image resize (not partition resize), as it already does a resize on import or upload.

[kubevirt-bot]

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[DhimanNeha]

Do we have any solution of it yet? I'm also facing this issue.

[awels]

/lifecycle frozen Not yet, but we are actively working on online resize, so soon.

[maya-r]

is kubevirt/kubevirt#5981 sufficient?

[sanzende]

Any solution for this yet?

[maya-r]

Yes, https://github.com/kubevirt/kubevirt/pull/5981 is merged, if you enable a kubevirt feature gate:

kubectl edit kubevirt -n kubevirt kubevirt

spec:
  configuration:
    developerConfiguration:
      featureGates:
      - ExpandDisks

resizing a PVC will be visible to a running VMI.

[sanzende]

Thanks Maya! Greatly appreciate. I will give it a try.

[alromeros]

Hello @maya-r @sanzende, since https://github.com/kubevirt/kubevirt/pull/5981 is merged I think we should close this issue. Are you ok with that? Thanks!

[aglitke]

Closing since kubevirt now supports this.