In my case I think I was using a small Debian Squeeze image that I converted to OVA format using xenconvert (months ago). The image was fine and it booted w/ nova before this commit. Additionally my initial image was also resizable after it booted fully.
---
The work around for me was to manually create a new OVA image by hand using the VHD of the booted instance on XenServer. Creating a tar of that VHD with an empty manifest.ovf makes this issue go away.
My guess is that others might hit this same issue when using nova w/ XenServer. Specifically anyone booting an OVA image which wasn't created directly from a XenServer dom0.
Hope that helps. I didn't have time to track it any further.
Hi Glen,
It appears that the vhd_util resize operation doesn't like to work with some OVA images (ones not created on XenServer?).
https:/ /github. com/xen- org/blktap/ blob/master/ vhd/lib/ vhd-util- resize. c#L1052
In my case I think I was using a small Debian Squeeze image that I converted to OVA format using xenconvert (months ago). The image was fine and it booted w/ nova before this commit. Additionally my initial image was also resizable after it booted fully.
---
The work around for me was to manually create a new OVA image by hand using the VHD of the booted instance on XenServer. Creating a tar of that VHD with an empty manifest.ovf makes this issue go away.
My guess is that others might hit this same issue when using nova w/ XenServer. Specifically anyone booting an OVA image which wasn't created directly from a XenServer dom0.
Hope that helps. I didn't have time to track it any further.
Dan