Bug 1378579 - Deploying a New Host to vmware compute resource from existing template always ends up with thin provisioned disk
Summary: Deploying a New Host to vmware compute resource from existing template always...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Compute Resources - VMWare
Version: 6.2.1
Hardware: x86_64
OS: Linux
high
high with 8 votes
Target Milestone: 6.6.0
Assignee: Ondřej Ezr
QA Contact: Lukáš Hellebrandt
URL:
Whiteboard:
Depends On:
Blocks: 1541321
TreeView+ depends on / blocked
 
Reported: 2016-09-22 19:10 UTC by Jason Berry
Modified: 2023-03-24 13:42 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-10-22 12:46:40 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Foreman Issue Tracker 27015 0 High Resolved Deploying a New Host to vmware compute resource from existing template always ends up with thin provisioned disk 2020-04-03 08:46:02 UTC
Red Hat Bugzilla 1322481 1 None None None 2023-03-24 13:40:40 UTC
Red Hat Product Errata RHSA-2019:3172 0 None None None 2019-10-22 12:47:01 UTC

Internal Links: 1322481

Description Jason Berry 2016-09-22 19:10:22 UTC
Description of problem:
Create a New Host, destined for a Vmware compute resource, image based off an existing template in Vmware.  When the new host is deployed, it will always have thin provisioned disks.

Version-Release number of selected component (if applicable):
6.2.1

How reproducible:
Every Time

Steps to Reproduce:
1. Create a New Host, destined for a Vmware compute resource, image based off an existing template in Vmware.
2. Go into Vmware, right click settings, and look at disk
3. Disk will be thin provisioned, even though the template or any settings in WebUI are requesting thick


Additional info:
fog-vsphere gem, requests/compute/vm_cloen.rb, approx line 583, is looking for an 
options['transform'] setting that doesnt get set anywhere by Satellite it seems.  
            
`relocation_spec = RbVmomi::VIM.VirtualMachineRelocateSpec(:pool => resource_pool,:transform => options['transform'] || 'sparse')`

Since it's not set, it defaults to 'sparse' which makes it thin.  If I hard code this line to be ":transform => 'flat'", it'll deploy thick provisioned lazy zero, as I need.

Comment 8 Chris Roberts 2018-06-12 14:21:18 UTC
Users are hitting this upstream, did some tests:

I went ahead and built a host normally:

http://nimb.ws/grU8qG 1

I made sure to have the vm created with thick provisioning

http://nimb.ws/ZjXvNs 1

Sadly this does not look to be working, as you can see from here the vm is still in thin mode.

http://nimb.ws/LXzZlI 1

I tested a thick prov template and trying to make a new thin vm with that and it didnt work either:

Template: http://nimb.ws/L6rIW3 1

Thin checked: http://nimb.ws/MsBumD

Thin result: http://nimb.ws/xNEbR4 1

I tested a thin template and was able to create a thick vm ok

Thin thick create: http://nimb.ws/FtvS7Z

Thick result: http://nimb.ws/EBNzbt

When I tried to create a thin vm from a thin template it did not honor it:

Thin create: http://nimb.ws/SibMkE 1

Thin result: http://nimb.ws/0P3wO1 1

Comment 17 Marek Hulan 2019-06-11 07:09:44 UTC
Created redmine issue https://projects.theforeman.org/issues/27015 from this bug

Comment 18 Bryan Kearney 2019-07-21 22:05:53 UTC
Upstream bug assigned to oezr

Comment 19 Bryan Kearney 2019-07-21 22:05:54 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/27015 has been resolved.

Comment 24 Lukáš Hellebrandt 2019-09-17 14:08:20 UTC
Verified with Sat 6.6 snap 20.

Used reproducer from OP, used full matrix of {thin,thick}-{template,webui_setting}. The result was always correct in the VMWare WebUI.

Comment 26 errata-xmlrpc 2019-10-22 12:46:40 UTC
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/RHSA-2019:3172


Note You need to log in before you can comment on or make changes to this bug.