GHBase Upgrade Plan

Hislop (Talk | contribs)
(Created page with "==GHBase Upgrade Plan== ===Questions=== #Does the boot loader boot the hypervisor? #Could vShere and KVM be dual booted? #How is security set up on the hypervisor and the VMs...")

---

GHBase Upgrade Plan

Questions

1. Does the boot loader boot the hypervisor?
2. Could vShere and KVM be dual booted?
3. How is security set up on the hypervisor and the VMs?

Inital Steps

1. Shut down GHMain VM
2. Full Back Up GHMain to tape
   • Ensure all backups prior were done without errors.
3. Backup GHMain.vmdk to user files on the new box.

Transfer Plan (Process should take about 2 hours 30 minutes to complete)

1. Log into ESXi client through vSphere as the root user.
2. Shutdown ghmain (if it has not been shutdown already).
3. Make an admin user for the base hypervisor from the client so you can log into the hypervisor itself later.
4. Enable ssh into base hypervisor from the client
   • Click on configuration
   • Select Security Profile
   • Click on properties in services section
   • Start SSH and ESXI Shell (make sure the manual start and stop bubble is still filled out).
5. ssh into base server you wish to move the .vmdk file to
   • In this case we will be logging into the KVM server
6. Look through the datastore(s) in the vSphere client to determine the file location of the .vmdk file for the VM you wish to transfer.
   • Verify the file locations by logging into the hypervisor from the terminal of the server you are transferring to
   • Use pwd to determine the absolute path of the current directory.
   • Remember the location, this step is needed for the actual transfer command
7. Create a folder in one of the users downloads directories for the new files.
8. While in the new folder execute the secure copy command to transfer the .vmdk file
   • scp -r the folder the .vmdk file is in
   • PLEASE NOTE AFTER THE *vmname*-flat.vdmk file is transferred in full you do not need to copy anything more. This will be a waste of time and resources.
     • Please note that we copy the whole folder so we can get the hidden *vmname*-fiat.vmdk file rather then guessing the location or making it visible.
   • To exit the download kill the process with a CTRL+C command.
9. Disable ssh into the base hypervisor from the vSphere client by manually stopping the services that were started earlier.
10. Convert the .vmdk disk (flat one) to .qcow2
    • Conversion line: sudo qemu-img convert -O qcow2 *vmname*-flat.vmdk *vmname*.qcow2
11. Open KVM and add a new VM as a generic VM (not as a fedora system) and customize the installation to fit the needs of the VM
12. Turn on the new VM, it should be set up as it was previously under the new configurations on KVM and the specific name given.
13. Set up the network connection
    • Turn on the network and set it to start up automatically
    • Get a DNS name pointed to the new location (contact Bill).

Check the new VM (Not estimated completion time)

1. Ensure everything is working properly on the new machine:
   • All Wiki’s
   • HFOSS
   • FOSS2Serve
2. Go through any installation necessary to bring the new machine up and running again.

Security (No estimated completion time)

1. Ensure SSL is working
2. Ensure root login to VM is disabled
3. Ensure other security features are intact
   • See Bill for this one
4. Disable root login to KVM

Set up backups (No estimated completion time)

1. Contact Bill about changing the way back ups work for the new machine.

Install KVM on ghbase machine

1. Install CentOS over the ESXi hypervisor.
2. Follow the CentOS installation guide here: http://ghmain.ischool.drexel.edu/team/index.php/Creating_KVMServer
3. Ensure the system is running properly.

Set up security for the new hypervisor

1. Yet to be talked about

Transfer VMs back to ghbase (now with KVM)

1. Repeat Steps in the transfer plan section above just the other way (from other box to ghbase).

Known Issues

1. Improper installation of CentOS 7
2. Backup issues - backups not completing properly or fully
3. Broken connection when transferring
4. Not enough space on hypervisor for both VMs.
   • In some cases you have to be careful where you load the .vmdk file. This should be done in a users folder NOT the root folder
5. Networking issues so that the VM’s cannot connect to the internet and no one can connect to the VM network.