kubevirt / kubevirt.github.io

KubeVirt website repo, documentation at https://kubevirt.io/user-guide/
https://kubevirt.io
MIT License
30 stars 112 forks source link

[lab2 cdi experiment] virtual image size is larger than 4Gb #693

Closed linsite closed 3 years ago

linsite commented 3 years ago

Is this a BUG REPORT or FEATURE REQUEST?:

Uncomment only one, leave it on its own line:

/kind bug /kind enhancement

What happened: lab2 failed

kubectl logs -f importer-fedora
I0219 06:32:59.395689       1 importer.go:52] Starting importer
I0219 06:32:59.395780       1 importer.go:139] begin import process
I0219 06:33:18.105169       1 data-processor.go:360] Calculating available size
I0219 06:33:18.105318       1 data-processor.go:372] Checking out file system volume size.
I0219 06:33:18.105373       1 data-processor.go:380] Request image size not empty.
I0219 06:33:18.105408       1 data-processor.go:385] Target size 4Gi.
I0219 06:33:18.218817       1 data-processor.go:241] New phase: Convert
I0219 06:33:18.218843       1 data-processor.go:247] Validating image
E0219 06:33:34.280955       1 data-processor.go:238] Virtual image size 4294967296 is larger than available size 4058744094 (PVC size 4294967296, reserved overhead 0.055000%). A
larger PVC is required.
Unable to convert source data to target format
kubevirt.io/containerized-data-importer/pkg/importer.(*DataProcessor).ProcessDataWithPause
        pkg/importer/data-processor.go:222
kubevirt.io/containerized-data-importer/pkg/importer.(*DataProcessor).ProcessData
        pkg/importer/data-processor.go:170
main.main
        cmd/cdi-importer/importer.go:194
runtime.main
        GOROOT/src/runtime/proc.go:203
runtime.goexit
        GOROOT/src/runtime/asm_amd64.s:1357
E0219 06:33:34.281029       1 importer.go:196] Virtual image size 4294967296 is larger than available size 4058744094 (PVC size 4294967296, reserved overhead 0.055000%). A larger
 PVC is required.
Unable to convert source data to target format
kubevirt.io/containerized-data-importer/pkg/importer.(*DataProcessor).ProcessDataWithPause
        pkg/importer/data-processor.go:222
kubevirt.io/containerized-data-importer/pkg/importer.(*DataProcessor).ProcessData
        pkg/importer/data-processor.go:170
main.main
        cmd/cdi-importer/importer.go:194
runtime.main
        GOROOT/src/runtime/proc.go:203
runtime.goexit
        GOROOT/src/runtime/asm_amd64.s:1357

What you expected to happen: importer pod should succeed.

Anything else we need to know?:

URL where the problem can be found ... If the issue is with a lab, please provide information about your environment, platform, versions, ...

mazzystr commented 3 years ago

We aren't doing inline virtual disk conversion yet. If your original virtual disk is 4 GiB then you have to have 8 GiB available in the storage class. The virtual disk gets uploaded into pvc then it gets optimized/converted.

Can you check your hostclass and make sure you have 8 GiB?

linsite commented 3 years ago

The PVC provided in the storage-setup.yml is 4GiB, I change it to 5GiB and the problem is solved. I guess this is not an issue, but the provided storage-setup.yml in lab needed to be updated to larger capacity, or the tutorial should be updated to check the PVC is large enough before creating the PVC for a better experience. If the advice is unnessasery, just close this issue :). I just start learning KubeVirt, so the advice may not be proper.

codificat commented 3 years ago

I believe you are right and the requested storage should be updated to accomodate the bigger image size.

mazzystr commented 3 years ago

https://github.com/kubevirt/kubevirt.github.io/blob/source/labs/manifests/pvc_fedora.yml#L8

Another option is to change the Fedora img because it's getting obnoxiously large. This is a reason that Alpine, Cirros, Ubuntu dominate containerized workloads.

codificat commented 3 years ago

Well, the Fedora image itself is relatively small (e.g. <200 MB vs 500+ MB for Ubuntu AFAICT from a quick look), but it as a virtual size of 4GiB that overflows the pvc by just a bit.

IMHO just increasing the requested PVC size is a simple straightforward change that will fix that and I'd vote for this (e.g. no need to update any references).