History

Converting a VM template to an Install VM

The install test process uses VM templates to create a clean OS install for the purposes of testing the installation of fossology packages. The configured VM is then saved as a template. This ensures that if the VM is lost or corrupted somehow, a new VM could be created in a short time using the template. Think of the templates as the backup of you VM.

The install test process uses VM snapshots, so normally the steps below won't be needed. There will be joy that a template exists when the VM gets hosed.

These are the steps need to convert an template vm to an install vm instance. These steps all involve using the VSphere Client software either on your windows computer or on ldozer. The fossology VM are found at: oslpv3.fc.hp.com. Speak with Dan S. about getting an account.

  1. Open the Templates folder
  2. Select the template to use
  3. Select Deploy a new virtual machine, NOT Convert. The templates should never be converted to a VM, that way they can be used over and over again.
  4. The name of the VM to create will be the same as the template. Don't use . in a name, networking doesn't like it. A different name can be used, but for install testing the names matter due to jenkins needing to contact them.
  5. Due to space issues, all new VM's should be created using foss-vmhost1 or 2. Don't use 3 or 4.
  6. For the Datastore screen pick foss-vmdata1 for now, it has the most space.
  7. take the defaults for most of the screens.
  8. for memory, make sure there is 2GB of main memory. It should already be set that way from the template, but check it.
  9. If Vsphere responds with cannot contact host when trying to create the vm, then start over... if you picked fosshost2 before use fosshost1.... the theory is that the problem is related to how either the template or original vm was made (and what storage it used).
  10. move the new VM to the FossologyVMs folder in vSphere.

There should now be an new virtual machine. Follow the next steps to configure the system to talk on the network.

  1. Power the new vm on, use vSphere to use the console
  2. look at the settings for this vm and note the network card MAC address, this is needed below.
  3. login as root (standard pw, iforgot).
  4. Depending on what flavor of OS it is follow the steps below:

The best way to reset for another test is to remove the vm and create another with the same name from the template. Make sure to give it the same name so the dhcp addresses work.

Debian

  • edit /etc/hostname
  • change the name of the system with sudo hostname <name> NOT using the domain.
  • edit /etc/hosts and adjust the name and domain as needed.
  • update the dhcp config on lart with the new MAC, be sure to run bind THEN dhcp on lart.
  • restart networking on the vm, check that the correct IP address and domain are in use.

RedHat

  • edit /etc/sysconfig/network to change the hostname
  • edit /etc/sysconfig/network-scripts/ifcfg-eth0, update the mac address
  • change name as needed on lart: (/etc/bind/) 'make USER=ostt'; sudo /etc/init.d/bind9 reload (this step might not be needed if the name is the same)
  • change MAC on lart: (/etc/dhcp3/include/ostt) sudo /etc/init.d/dhcp-restart
  • Make sure dhcp entry has the correct IP address.
  • restart networking 'service network restart'
  • ifconfig to check that the correct IP address was grabbed.
  • if the above fails, reboot to see if that fixes things. Make sure the system and what's on lart match!
  • if the above fails with eth0 not present error, this is a defect in vmware... the new ip is assigned to eth1. To fix one must edit the file: /etc/udev/rules.d/70-persistent-net.rules and make the eth0 line match the mac address and remove the eth1 entry and any other eth0 entries. Reboot and things should be OK. Another post says to just remove the file and reboot and the correct one will get regenerated.... did not try that but will next time.
  • Fedora: configure yum with a proxy, for RHEL, Need to configure Yum to use coe repo's and centos repos.