Additional Hard Drives and Misc Custom Commands

[TheNotary]

Hi @josenk,

Thanks again for sharing this work, it's really well written and maintained! A couple months back, I started using Vagrant to build prod-like boxes on virtualbox. The virtualbox provider has some #customize method that seems to basically run one of the virtualbox CLIs to perform a task on the VM in the midst of it's creation.

For example, this uses storagectl to attach a stat controller to a virtualbox VM

v.customize ['storagectl', :id, '--name', controller_name, '--add', 'sata', '--portcount', 4] 

...more code available here

Do you have any plans to approach hard drive attachment in this plugin? Have you approached this problem a different way?

[josenk]

Thanks! I really appreciate the great feedback...

BTW: I already added options to extend the boot disk (guest_boot_disk_size ) and to create additional storage (guest_storage) with my plugin.

    #  OPTIONAL. Boot disk size.
    #    If unspecified, the boot disk size will be the same as the original
    #    box.  You can specify a larger boot disk size in GB.  The extra disk space
    #    will NOT automatically be available to your OS.  You will need to
    #    create or modify partitions, LVM and/or filesystems.
    #esxi.guest_boot_disk_size = 50

    #  OPTIONAL.  Create additional storage for guests.
    #    You can specify an array of up to 13 virtual disk sizes (in GB) that you
    #    would like the provider to create once the guest has been created.
    #esxi.guest_storage = [10,20]

Do these options satisfy your request? I really would be against adding an option to run a remote command on your esxi box from this plugin. It seems like such a high risk!

[TheNotary]

Oh nice, I read that section earlier today and must have been in a hurry because I missed the explanation about the ints being sizes of disks in GB.

I think that covers most use cases, but I'm re-writing a past project of manually created systems to be 100% infra-code (even the hypervisor has is an install image + a code repo that configures it). One of the systems on the hypervisor is a storage system that basically mounts 2 disks on 2 different physical HDDs and exposes an NFS share of a RAID 1 array made up of these two disks.

I can see why you would want to avoid having arbitrary remote commands run on the ESXi server, it feels messy to me as well, and felt uneasy about writing it in virtualbox, disbelieving that it was actually be reliable, though just barely it is. But the alternative to having vagrant responsible for running these external commands, I'll need to have a followup stage to deployment, conducted by a followup process. That is, I think my pipeline will look like...

Hypervisor installation (via the VMWare disk) ->
Hypervisor Provisioning (via a repo consisting of pyvimio code) -> 

Box Creation/ provisioning (via packer + shell provisioner) -> 
VM Deployment (via Vagrant) -> 
_VM Post-deployment provisioning (hdd stuff via python pyvimio stuff?)_ ->
Infrastructure Testing via serverpsec/ inspec

As you can see it would be ideal to eliminate the _VM Post-deployment provisioning (hdd stuff)_ phase. If I could specify the datastore and path for the storage VMDK item, that could give me the flexibility I need to keep my pipeline elegant.

[josenk]

How about using "guest_custom_vmx_settings"??? You can add or modify just about anything in the vmx.

esxi.guest_custom_vmx_settings = [['scsi1.virtualDev','pvscsi'], ['scsi1.present','TRUE'], ['floppy0.present','TRUE']]

Another solution could be to use a host-shell plugin. You can ssh to your esxi box and run any command you like.

https://github.com/phinze/vagrant-host-shell

BTW: I believe terraform is a much better choice for Infra-as-code. Vagrant was designed to bring up and tear-down Development environments really quickly.

[TheNotary]

Thanks for your comments on both issues! I read your response over the weekend on my phone but injured my back and haven't been able to get to my hobby laptop till now.

I'll look over those options next weekend and see if I can find a clean path forward. I agree about terraform, that's actually what I had my heart set on when I first set out on this, but it seems VMWare is doubling down on their corporate VRealize suite and not very interested in enabling API access without consumers paying the $5k license. That said, the terraform plugin for ESXi is nearly non-existant and needs to be built out unless things have changed over the past 6 months.

[TheNotary]

Good evening, @josenk. So I've been poking around the esxi.guest_storage configuration option and I have to say you have a really nice way of expressing algorithms. As such, to enable specifying the datastore name of additional volumes, all that's required is applying this 20-odd line patch:

The syntax can be the original way, or be specified in this format:

esxi.guest_storage = [ { size: 1, datastore: 'fast-drive'}, { size: 2, datastore: 'datastore1'}, { size: 3 }, 4 ]

This project's readme does not comment on paths to contribute, so please forgive me if I'm intruding, but if you're open to including this feature in your code-base I would consider it a privilege to rework this patch such that it meets any code quality expectations it doesn't meet in it's current form.

Also, I wanted to add a cross-reference node to any folks who may be following along with the ESXI-terraform front who may be interested in seeing this repo as well: https://github.com/terraform-providers/terraform-provider-vsphere/issues/268

[josenk]

Thanks for the contribution and the comments about my style. ;-) You're right. I don't really have a contribution path. So far I've been doing all the work on my own. My workflow is internal, so that's why you won't see my beta's on github.

Just looking at the code I think it should work OK. I really like the way you expanded the functionality of the existing guest_storage Vagrantfile config.

My take on 'incorrect' or 'bad' Vagrantfile entries is to use defaults or try to somehow continue without failing. So, I do have one question. What if someone specifies an incorrect Disk Storage name? Would you prefer to exit (Failed), or continue the build using defaults (put the vmdk in the default Guest directory?

I'll pass it through my battery of tests and include it in the next release.

[TheNotary]

| My take on 'incorrect' or 'bad' Vagrantfile entries is to use defaults or try to somehow continue without failing.

I think that's a good approach to things. Especially for basic configuration settings, you want things to go well for people just getting their feet wet. I don't have my very own image pipeline yet, so I don't have personal experience, but I'd imagine that if I put into my build configs a datastore, and that drive went offline, or I typoed the datastore, I think I'd lean towards wanting an early validation error over a warning. I'm pretty 50 / 50 on it. I personally treat warnings as errors/ tech debt that should be addressed before moving on to the next task so I think I'd be impacted equivalently by either of the design choices.

Also as a quick note before I head to work, I spent so much time towards learning how to configure multi-machine Vagrantfiles (and forcing arbitrary data into .vmx files) that the PR I opened might still need a tweak to around it's createvm.rb:378 to properly the storage size out of the hash during validation phase. Edit: Oops, just a groggy morning and installed from a different clone.

[josenk]

V2.3.0 has been released. I added a bit of validation to your code...

I also added a failonwarning Vagrantfile config option for advanced user that want more predictable results. The default (False) is the current prescription (if something was not specified or incorrect, then choose defaults, produce a warning and continue.)