Just on this, as far as i'm able to tell, i've not found an easy way to allow this, those users (myself included) that have thin provisioning on their san backends are in for a world of pain if they can't pre-allocate VM disks. :\

If this helps, I've worked through doing this via he API. I have a perl script which i've used in the past to allocate vm's from templates. I managed to piece together the following disk allocation xml, based on Red Hat's API docs.

<disk>
<clone>true</clone>
<storage_domains>
<storage_domain id=\\"%s\\"/></storage_domains>
<size>%s</size>
<type>system</type>
<interface>virtio</interface>
<format>RAW</format>
<bootable>true</bootable>
</disk>

The format = RAW flag is the key. That tells the API to create this disk as a preallocated type, and not a thin disk.

This should be possible via foreman. I'd guess it depends on whatever library foreman uses to interact with the oVirt API.

It looks like the functionality for this is there in the underlying code base, the default behavior comes from the rbovirt gems rbovirt-0.0.21/lib/ovirt/volume.rb which sets format to cow and sparse to true when no settings are being passed for those variables. The system should just need to be modified to pass the additional options for format and sparse as a part of the disk information sent by the web interface when requesting a new disk.

I see the status sitting at ready for testing.

Are you waiting for someone to test? If so, i'd be willing to do what I can. What's involved in getting the proper version of code running to test?

Thanks!

Nathan Lager wrote:

I see the status sitting at ready for testing.

Are you waiting for someone to test? If so, i'd be willing to do what I can. What's involved in getting the proper version of code running to test?

Yep, that'd be a great help.

You can do something like: cd /usr/share/foreman && curl https://github.com/theforeman/foreman/pull/1462.patch | patch -p1 and then restart Foreman/httpd.

Dominic Cleal wrote:

Nathan Lager wrote:

I see the status sitting at ready for testing.

Are you waiting for someone to test? If so, i'd be willing to do what I can. What's involved in getting the proper version of code running to test?

Yep, that'd be a great help.

You can do something like: cd /usr/share/foreman && curl https://github.com/theforeman/foreman/pull/1462.patch | patch -p1 and then restart Foreman/httpd.

Thanks! I'll see if I can give that a shot without affecting my production foreman. Give me some time to work out the best way to do that, and I'll report back with the outcome.

ok, I gave it a shot. Close, but Foreman was unable to create my vm's disk.

It gave me the option to preallocate the disk, but when I submitted it, it failed while creating the instance, with the following error:

Unable to save
Failed to create a compute Metal (oVirt) instance testprov-nonthin.dev.lafayette.edu: Cannot add Virtual Machine Disk. Disk configuration (COW Preallocated) is incompatible with the storage domain type.

The Storage domain is a RHEV Storage Pool, Fibre channel attached. Let me know what other info you need in order to troubleshoot.

Thanks!

i've created a pull request that should satisfy this if someone wants to test it, based off the previous pull request. https://github.com/theforeman/foreman/pull/1568/files

Hope this isn't breaking etiquette or something, I really need this in mainline asap.

I've verified it working against my RHEV cluster.

One thing of interest, in my development environment, I notice that the machine provisions fine, but it sometimes get rolled back after as it times out whilst waiting to power up the machine (as the disks are still locked on the rhev side), not sure what the best path forward for that is. (I just don't enable powering on the machine when thick provisioning).

Thoughts?

Known issue, locked volumes seems to be problematic.

Spam removed by Redmine administrator