Related to the Web UI. Description of problem: For some source VMWare VMs during v2v, the disk size is computed to a weird floating number (i.e. 9.5123123...) on the Storage wizard step. A PV of such size can not be successfully provisioned (at least not on gluster), so the flow fails. Version-Release number of selected component (if applicable): 2.0.0 How reproducible: 100% With a proper source VM Steps to Reproduce: 1. Launch Create VM Wizard, VMWare Import flow 2. Find a source VM with "weird" computed disk size 3. Finish the Wizard, check for error Actual results: Disk size is not in format/range acceptable by storage provider. Expected results: "Weird" values of storage class are rounded to acceptable value. Needs to be verified, but it is probably nearest higher integer number. Additional info: When fixing the issue, I can help in finding the source VM with such incorrect disk size.
Why exactly do you recalculate the size to GB? It should be possible to request PV with specified number of bytes, isn't it? Or are such requirements always present (e.g. provider requires sizes rounded to GBs or block size multiples)?
Prior v2v, the only source for the disk size value was the input from user, which is in GiBs. We can either change the unit internally used or recalculate. In the fix I propose, we recalculate to whatever reasonable unit when creating PVC.
Patch: https://github.com/kubevirt/web-ui-components/pull/452
Marek, Can you please help in exact reproduce steps, when using local storage? Thanks, Ilanit.
Verified fix on version HCO 27. VM had 2 disks, one usual with OS, second small, 1MB without filesystem. During migration wizard showed second disk with its proper size.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2019:1850