GHBase Upgrade Plan
From Temp
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?
Inital Steps
- Shut down GHMain VM
- Full Back Up GHMain to tape
- Ensure all backups prior were done without errors.
- Backup GHMain.vmdk to user files on the new box.
Transfer Plan (Process should take about 2 hours 30 minutes to complete)
- Log into ESXi client through vSphere as the root user.
- Shutdown ghmain (if it has not been shutdown already).
- Make an admin user for the base hypervisor from the client so you can log into the hypervisor itself later.
- 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).
- ssh into base server you wish to move the .vmdk file to
- In this case we will be logging into the KVM server
- 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
- Create a folder in one of the users downloads directories for the new files.
- 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.
- Disable ssh into the base hypervisor from the vSphere client by manually stopping the services that were started earlier.
- Convert the .vmdk disk (flat one) to .qcow2
- Conversion line: sudo qemu-img convert -O qcow2 *vmname*-flat.vmdk *vmname*.qcow2
- 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
- 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.
- 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)
- Ensure everything is working properly on the new machine:
- All Wiki’s
- HFOSS
- FOSS2Serve
- Go through any installation necessary to bring the new machine up and running again.
Security (No estimated completion time)
- Ensure SSL is working
- Ensure root login to VM is disabled
- Ensure other security features are intact
- See Bill for this one
- Disable root login to KVM
Set up backups (No estimated completion time)
- Contact Bill about changing the way back ups work for the new machine.
Install KVM on ghbase machine
- Install CentOS over the ESXi hypervisor.
- Follow the CentOS installation guide here: http://ghmain.ischool.drexel.edu/team/index.php/Creating_KVMServer
- Ensure the system is running properly.
Set up security for the new hypervisor
- Yet to be talked about
Transfer VMs back to ghbase (now with KVM)
- Repeat Steps in the transfer plan section above just the other way (from other box to ghbase).
Known Issues
- Improper installation of CentOS 7
- Backup issues - backups not completing properly or fully
- Broken connection when transferring
- 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
- Networking issues so that the VM’s cannot connect to the internet and no one can connect to the VM network.
