Control Panel, Programs and Features, Turn Windows Features On or Off:
Expand "Hyper-V" Check "Hyper-V Management Tools"
Preserving VirtualBox VM’s and Configurations on a Multi-disk Host
Important background information:
My desktop computer has been running Windows 10 since I bought it about five years ago. It was clear to me that I needed to reinstall the OS but that always involves lots of backups and configuration changes. I’d rather not go through this but sometimes you need to.
My system has two drives: a 225G SSD for the OS install and a 2T hard drive for data. When I originally set VirtualBox up, I configured it to store my VM’s and the ISO farm on the 2T HD. This, it turns out, made my OS refresh easy. I currently have 19 VM’s for my various playgrounds, which would have been a real mess to deal with.
How to:
Before reinstalling the OS, you should update VirtualBox (and the Guest Additions if you also install them) to the latest edition. Make sure everything is working OK by spinning up at least one VM. Once you shut all the VM’s down, you need to locate and copy the VirtualBox configuration directory to a safe backup location. This is a hidden folder typically in your user profile named “.VirtualBox”. This folder holds both your VirtualBox configuration settings and the latest VirtualBox Extensions installer file, both of which you will need later.
Once you shut all the VM’s down, you should consider if you want to back everything up. What I did was to shutdown my computer and disconnect my HD.
WARNING: This may cause issues later. In my case after I installed the new OS and reconnected my HD, my HD assumed a different drive letter. You need to reassign drive letters immediately if this happens. I used Windows “Disk Management” tool to do this.
Once you have installed and updated the new OS, and also have your drive letter changes corrected (see warning above), do the following:
1). Install the latest VirtualBox, it should match the version you updated to prior to the OS reinstall.
2) Start VirtualBox. You will not see any VM’s listed because you have not copied the config file yet. But you should do this before copying the old config file over to the new install.
3) Stop VirtualBox.
4) Copy both the “VirtualBox.xml” and VirtualBox Extension Pack file to the new .”VirtualBox” configuration folder under your user profile, replacing the new config file with your old one.
5) Start VirtualBox and reinstall the VirtualBox Guest Additions.
6) Start up some VM’s. Hopefully everything works. If needed, you could make changes to the VirtualBox.xml file, but you shouldn’t have to.
What Domains(VM’s) are Using what Hard Drive Volumes in KVM/Libvirt?
I noticed in my well-used test KVM virtual environment that I had a few volumes that had different names than did the existing domain (VM) names. I also noticed that I had more volumes than domains. So how do I tell which volumes are being used by which VM? And how can I tell what volumes are orphaned? Note for path purposes, my host is running Ubuntu 18.04.
I tried several “virsh” commands and spent time looking in the man pages. Nothing stood out so here is what I ended up doing.
First: I needed to list and locate the volumes in the “default” pool:
virsh vol-list --pool default
This also provides the path to the “default” pool where the volumes are located. I also noticed that I had a volume listed that was not shown when I did “ls -l” on the “/var/lib/libvirt/images/” directory. No problem, just update the pool listing:
virsh pool-refresh default
Solved that problem. Now I need to tie the volumes back to the VMs:
virsh dumpxml "my vm name"
That works but is cumbersome for multiple VMs and multiple volumes. So where are the VM configuration files located? A quick look around the directories where the volumes are stored turned up nothing, so best guess is /etc:
grep - ir "my vm name" /etc
That returns “/etc/libvirt/qemu/” and looking in that directory indicates we have found the VM config files. So now I need a list of VMs and their associated volume drives. Note that I am literally grepping for “source file” here:
grep -i "source file" /etc/libvirt/qemu/*
That allows me to tie the VM names to volume names that don’t match.
Now I can double check to make sure that a volume is or is not associated to a VM:
grep -i "name.qcow2" /etc/libvirt/qemu/*