vsphere and veewee

[jedi4ever]

received this ping on twitter about integrating it

Notes on my approach to ISO boot, with some assumptions and limitations: http://gist.github.com/3856352 by @jasonberanek .

Servers a place holder

[jasonberanek]

Finally coming back to this after a few sidetracks. I need to get my older prototype code updated with the newer commits, and retested.

One item I've found, and do not see a way to work around, is that there appears to be no way to retrieve the created VMs IP address prior to VMware tools being installed. This means that VMware tools have to be installed as part of the kickstart %post section, rather than as a Veewee managed post install script. I'm not as familiar with non-kickstart installation automation approaches, so if anyone has examples of adding %post like actions to other installation files so the VMware tools installation can be scripted that would help speed up the testing process.

[jedi4ever]

@jasonberanek

Approach1:
For an ubuntu 12.04 we could make a test template vsphere-ubuntu12.04-amd64
We manually change the preseed.cfg file to execute the part below
(we can later make it conditional as .erb templates are supported)

Approach2: (if approach 1 fails)
we can get the IP address from the http request the client does to the temp http server to fetch the preseed.cfg file

Note: I don't have a vsphere handy, but maybe we need to create a fusion veewee template that installs the vsphere?
http://www.jedi.be/blog/2010/12/09/automated-vmware-esx-installation-even-in-vmware-fusion/

---

Would https://help.ubuntu.com/community/VMware/Tools be useful?

# on 12.04 LTS you can simply install the package:
apt-get install open-vm-tools
# on earlier versions, use this workaround:
# install kernel headers so modules will work
# needed this on a 10.04 guest running in a Fusion 3 host
apt-get install linux-headers-virtual
# install kernel modules
apt-get install --no-install-recommends open-vm-dkms
# EITHER: install tools for an xorg install
apt-get install open-vm-tools
# OR: a headless install
apt-get install --no-install-recommends open-vm-tools

Vsphere packages seem to be available here:

• http://www.vmware.com/download/packages.html
• http://packages.vmware.com/tools

[jasonberanek]

@jedi4ever

I think I've been able to get my changes cherry picked from my experimental branch, and I'm cleaning up a few aspects of it (mainly the credential management) and then will push to a branch on my fork of veewee this week. I'd like some eyes on before I issue a pull request, as there is still more testing to do. I'll also include a few sample definitions that show the provider specifics options that are needed in the definition.

Approach 1 is what I've done so far in my CentOS based experiments, adding a post section to the kickstart file that installs the RHEL 5 VMware tools from a mirror of the VMware yum repos. Effectively, that's the RHEL equivalent of the OS specific package example you provided. I think for the first attempt Approach 1 is the cleanest, and with the link you provided I should be able to make a definition and preseed.cfg file easily enough to test building Ubuntu.

(Note: I don't have VMware Fusion, so I don't have anything to build the veewee definition to install vSphere/esxi as you suggest. My test environment is an Ubuntu 12.04 VM as the veewee client installed on a vSphere server. Though, this use case might be an excuse to get fusion, assuming my MacBook Air won't choke on the load.)

[jedi4ever]

great! @ffeldhaus might be interested
On 15 Jan 2013, at 01:29, "Jason A. Beranek" notifications@github.com wrote:

@jedi4ever

I think I've been able to get my changes cherry picked from my experimental branch, and I'm cleaning up a few aspects of it (mainly the credential management) and then will push to a branch on my fork of veewee this week. I'd like some eyes on before I issue a pull request, as there is still more testing to do. I'll also include a few sample definitions that show the provider specifics options that are needed in the definition.

Approach 1 is what I've done so far in my CentOS based experiments, adding a post section to the kickstart file that installs the RHEL 5 VMware tools from a mirror of the VMware yum repos. Effectively, that's the RHEL equivalent of the OS specific package example you provided. I think for the first attempt Approach 1 is the cleanest, and with the link you provided I should be able to make a definition and preseed.cfg file easily enough to test building Ubuntu.

(Note: I don't have VMware Fusion, so I don't have anything to build the veewee definition to install vSphere/esxi as you suggest. My test environment is an Ubuntu 12.04 VM as the veewee client installed on a vSphere server. Though, this use case might be an excuse to get fusion, assuming my MacBook Air won't choke on the load.)

—
Reply to this email directly or view it on GitHub.

[jasonberanek]

Awesome, I'll make sure @ffeldhaus is copied once I get the change pushed out.

I have most of the changes ready to push for my branch, however my Ubuntu 12.10 tests have encountered an error my CentOS tests didn't see. For some reason in my environment (VMware ESXi/vSphere 4.0), Ubuntu 12.04 and 12.10 VMs trigger the following message in the vSphere Client when the guest OS attempts to eject the virtual cdrom (in this cases ISOs) from the VM:

msg.cdromdisconnect.locked:The guest operating system has locked the CD-ROM door and is probably using the CD-ROM, which can prevent the guest from recognizing media changes.

The VM locks up until this message is acknowledged within vSphere Client. In the case of my Ubuntu 12.10 installation test, this means the OS installation hangs when the system attempts to eject the installation media before rebooting the VM. I can successfully work around this in the Ubuntu 12.10 definition by adding cdrom-detect/eject=false to the boot_cmd_sequence.

I still want to understand more about why this scenario is occurring, but internet resources haven't proved fruitful so far. The only thing that seems reasonable is maybe the issues is occurring based on the age of the ESXi version, and I plan to do some additional tests. The question locking the system should be answerable via the APIs, so I'm going to try a solution that looks for this message specifically and acknowledges it and throws an error if it gets a different question. I don't strictly like that approach, but it may be reasonable to make sure multiple OSes can be supported without a plethora of individual test cases.

[ffeldhaus]

I would be glad if you could commit all your changes to your fork of veewee so that I could have a look at it and could help identify open issues. You could also already create a pull request in which we continue the discussion and testing. That would nicely keep track of all commits we make during testing.

[jasonberanek]

@ffeldhaus I was able to resolve the above issue today, so I'll get my changes out on the branch later this evening, including some early usage instructions. I'd appreciate any help in cleaning it up from there because there are a least a few items that I'm sure either have edge cases or better solutions for.

[jasonberanek]

I am unable to access my corporate remote tools in order to complete the push tonight, so that activity will have to be delayed until tomorrow. In the meantime, feel free to review the following gist that captures my initial notes for the vsphere.md readme file: https://gist.github.com/0b9d42d7179008c7842e.

Note, these notes were pulled from memory since I did not have the code available, so some of the assumptions (particularly the order of how credentials/hosts are chosen) may be 100% accurate with the actual code.

[mpapis]

closing in favor of #504