Resize vmware disk needs to catch/block 'shrink' scenarios

[Axelay-Prime]

miq-Utilities/Automate/RedHatConsulting_Utilities/Infrastructure/VM/Provisioning/StateMachines/Methods.class/methods/resize_disk.rb

For situations where new_size < orig_size vmware will fail the request, as it doesn't support shrink operations. Target disk size should be measured against request size and any requests to shrink should non-disruptively exit with (perhaps) a warn that the disk is already > request size.

[itewk]

PR welcome :)

[Axelay-Prime]

Sorry, I'm not really into the 'dev' mindset yet. Google says "PR" is a pull request, and that means you would like me to contribute a fix. If you think what I'm doing is useful, I can clone and do a pull request when I'm done, but I've touched a few areas, and altered core functions unrelated to the behavior in question. I commented out the default inputs disk & size and override them with variable domain presets, vs. user inputs to identify which disk to change. Then I pulled in the vm's memory size to add 2gb to it for my sizing. I haven't finished yet, but my plan is to grab miq_provision.vm_template.disk_3_size.to_i (shown in bytes) to see the current size, and compare it to the request size, then set an option on the provision object to pull out later to send to ansible (resize_p_drive = [true|false]) I wrote a step in ansible to read this in and act accordingly: - name: 'Resize partition and filesystem of P: to 100% of available space, if needed.' win_shell: | $cur_size = $(Get-Partition -driveletter p).size $max_size = $(get-partitionsupportedsize -driveletter P).sizemax if ( $cur_size -lt $max_size ) { Resize-Partition -DriveLetter P -Size $max_size } when: resize_p_drive

…

________________________________ From: Ian Tewksbury <notifications@github.com> Sent: Thursday, March 29, 2018 5:14 PM To: RedHatOfficial/miq-Utilities Cc: Axelay-Prime; Author Subject: Re: [RedHatOfficial/miq-Utilities] Resize vmware disk needs to catch/block 'shrink' scenarios (#61) PR welcome :) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#61 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AQw2jBF9fWsGHjrgCyKAE4EdjOvr8R1Cks5tjVzKgaJpZM4TBBaI>.

[Axelay-Prime]

To the existing resize method I grabbed, I did the following changes: //////// #Commented out by Alex Mayberry - overriding user input values below, not asking in dialog. ## get parameters #disk_number = options['dialog_disk_number'] || options[:dialog_disk_number] || options['disk_number'] || options[:disk_nubmer] || 1 #disk_size = options['dialog_disk_size'] || options[:dialog_disk_size] || options['disk_size'] || options[:disk_size] disk_size = miq_provision.get_option(:p_drive_size_gb) || nil disk_number = miq_provision.get_option(:p_drive_number) || nil ////////// To do the size comparisons, I focused on the VM vs looking at the template, and put the resize operation after the VM was deployed so that the data would be available. Here's what I came up with on my end. If any of this is of value to anyone else, I'm happy to share it. //////// #Added by Alex Mayberry # Pull the vm memory size from the vm (this method is a post-provision step), and add 2gb # Running this before the VM is created would require relying on user input values, which could be mb/gb or anything the dialog allows. # # I will put the customizations here, and supply the `disk_number` and `disk_size` at the end, letting the rest of the code do its thing. # I will test memory size, memory size +2, and vm disk size to ensure we aren't shrinking # If it looks like we are shrinking the disk, or will be close to shrinking the disk, we won't modify it. # Vmware breaks if you ask it to shrink the volume, so if we are less, or closs to, it's not worth trying. # # vm_mem_mb is going to come from the extant vm, and presents as MB. We'll convert this to GB to match expected inputs for the resize method. vm_mem_mb = miq_provision.vm.ram_size.to_i # pg_goal_mb is the "memory size +2gb" that the customer is requesting for the new windows paging file volume size. pg_goal_mb = vm_mem_mb + 2048 pg_goal_gb = vm_mem_mb / 1024 + 2 #Disable the ansible role that resizes the drive by default, enable later if it is proven to be needed. miq_provision.set_option(:resize_p_drive, false) #Find our "p_drive" by parsing through the list of instance variables collected by the class # Check all disks from instance relationships and set p_drive if found # These values are defined in the variables domain / operating systems # The initial run of this has volumes 1 - 6 specified. (templates use 3 currently) evm_object_vars = 1..6 evm_object_vars.each do |varnum| diskvar = 'cf_vm_disk_' + varnum.to_s if $evm.object[diskvar] && $evm.object[diskvar].include?('p_drive') $evm.log(:info, "w2k12_resize_p_drive: Found p_drive on #{diskvar}") vm_disk_key = 'disk_' + varnum.to_s + '_size' $evm.log(:info, "w2k12_resize_p_drive: Setting disk key to #{vm_disk_key}") vm_vol_mb = miq_provision.vm.send(vm_disk_key).to_i / 1024 / 1024 $evm.log(:info, "w2k12_resize_p_drive: VM volume size is #{vm_vol_mb}MB") if pg_goal_mb > vm_vol_mb miq_provision.set_option(:p_drive_size_gb, pg_goal_gb) miq_provision.set_option(:p_drive_number, varnum) miq_provision.set_option(:resize_p_drive, true) end end end

…

________________________________ From: Axelay Bekker <fsckwindows@hotmail.com> Sent: Thursday, March 29, 2018 6:32 PM To: RedHatOfficial/miq-Utilities; RedHatOfficial/miq-Utilities Cc: Author Subject: Re: [RedHatOfficial/miq-Utilities] Resize vmware disk needs to catch/block 'shrink' scenarios (#61) Sorry, I'm not really into the 'dev' mindset yet. Google says "PR" is a pull request, and that means you would like me to contribute a fix. If you think what I'm doing is useful, I can clone and do a pull request when I'm done, but I've touched a few areas, and altered core functions unrelated to the behavior in question. I commented out the default inputs disk & size and override them with variable domain presets, vs. user inputs to identify which disk to change. Then I pulled in the vm's memory size to add 2gb to it for my sizing. I haven't finished yet, but my plan is to grab miq_provision.vm_template.disk_3_size.to_i (shown in bytes) to see the current size, and compare it to the request size, then set an option on the provision object to pull out later to send to ansible (resize_p_drive = [true|false]) I wrote a step in ansible to read this in and act accordingly: - name: 'Resize partition and filesystem of P: to 100% of available space, if needed.' win_shell: | $cur_size = $(Get-Partition -driveletter p).size $max_size = $(get-partitionsupportedsize -driveletter P).sizemax if ( $cur_size -lt $max_size ) { Resize-Partition -DriveLetter P -Size $max_size } when: resize_p_drive

________________________________ From: Ian Tewksbury <notifications@github.com> Sent: Thursday, March 29, 2018 5:14 PM To: RedHatOfficial/miq-Utilities Cc: Axelay-Prime; Author Subject: Re: [RedHatOfficial/miq-Utilities] Resize vmware disk needs to catch/block 'shrink' scenarios (#61) PR welcome :) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#61 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AQw2jBF9fWsGHjrgCyKAE4EdjOvr8R1Cks5tjVzKgaJpZM4TBBaI>.

[itewk]

@Axelay-Prime you should be able to commit those changes up to your fork of the project and then click the button to do a pull request. that will make it so we can easier review and merge.

Just so you know I actually stopped using this method and instead have started using templates with no attached disks and then using the add_new_disk method to dynamically add disks pre and post kickstart. Did this for multiple reasons, mostly because this resize code is a mess, and not provider agnostic like the add_disk code is. But still happy to review and merge any changes :)

[itewk]

@Axelay-Prime wondering if you were still interested in doing a PR for this?

[Axelay-Prime]

Lynn Dixon has produced a large amount of output with rbvmoni, including a resize function. He's still working on preparing this for public consumption, so I put in a check for smaller disks here #142 , as requested, but long term, I think we should support his methods once he releases.

[itewk]

@Axelay-Prime alrighty, should we assign this to Lynn?

[Axelay-Prime]

He has done an impressive amount of work with rbvmoni, if his work is not definitive, it is at least going to be comprehensive.
@lynndixon interested?

[lynndixon]

Sure. I have a LOT of neat RbVmomi methods, including resizing a disk. I'd be glad to get them in the repo, once I scrub the customer data out. Many of my methods rely on an RbVmomi embedded method that I also wrote, would we want all the methods in the VMware namespace to be stand-alone? Or are we OK with them relying on an embedded method (given that method is included somewhere in the repo)?

[itewk]

@lynndixon i dont 100% follow, but whatever works that doesn't break old things is good with me

[jeffwarnica]

Embedded methods are the way to go, @lynndixon . Anything that is in already in StdLib should be reused, or improved, and general purpose helpers you have should be there, too.

That may trigger refactoring to class style.