Hi, hope you've followed my previous articles (over the last couple of days I've been pretty busy…), since this article builds on the previous ones.
Just in case you missed them, here, have a look:
- The fastest CentOS VM Deployment on MS Hyper-V Servers -- Pt.1 -- A Summary.
- Download the programs needed.
- Create the "Father" VM (a New, independent VM).
As of now, I'm assuming you've just followed what I've explained so far (you may have skipped the [OPTIONAL STEPS] from my last article, but that's alright: they're optional for a reason!).
Anyway, it's now time to create the "Child Virtual Machine", a new VM that, to function properly, will depend from the previous Father VM.
Why would you want to have 2 VMs depending one-another? Read my first article from the series, The Summary, then tell me what you think!
Preparing the Father VM for distribution.
Before creating new Children VMs based on our Father VM, we need to prepare the Father first.
The preparation process is just a matter of deleting some files (which will be recreated automatically upon boot, inside the new Child VM).
From the Hyper-V main Window, login to the terminal console, then launch the following commands:
rm -f /etc/udev/rules.d/70-persistent-net.rules
rm -f /etc/ssh/ssh_host*key*
- The first command will delete the udev rule used to assign the "ethX" tag to a new Ethernet device. By deleting this file, you're making sure that, upon the next reboot inside the new Child VM, the new Ethernet Device will automatically acquire the name "eth0" name. Please note that this file is automatically created upon reboot.
- The second command will delete the SSH keys automatically generated by the host. To prevent creating many Child VMs with the same SSH host keys, just delete them. Upon booting inside any new Child VM, those keys will be automatically re-generated (this way you'll have new Child VMs with new keys).
- The 3rd command will simply shutdown the Father VM.
After shutting down your Father VM, locate, use [Win]dows [E]xplorer to locate your Father VM's "VHD Image file" (i.e.: by opening D:\Data\HyperV\CentOS-6.2.vhd), Right Click on the "Father VHD image file", choose "Properties", then put a flag on the "Read-only" box and Click "Ok" to confirm.
Set your original Father VM VHD Image to "READ-ONLY".
Once you're sure your Father VM has been flagged as "Read-only" (this also implies you won't touch it anymore), you can proceed to create a New 2nd Child VM.
The procedure is similar to the one you've followed while creating the Father VM: first create a new VHD, then create a new VM, then attach the new VHD to your new VM.
I'll show you the step-by-step process, no worries.
New Child Differencing VHD.
From the Hyper-V Main Window:
This time we'll create a new "Differencing" Virtual Hard Disk Drive, which will technically store the differencing data not found inside the Father VM VHD Image. In other words, this Child VHD Image will contain only the files and the programs that you'll choose to install into this new Virtual Machine (which are not present on the Father VM). Also, any updated application or program will increase the size of the Child VM.
On the "New Virtual Hard Disk Wizard" you'll select "Differencing" Virtual Hard Disk.
Here you'll simply specify where the "Child Differencing VHD Image" will be located.
Name this Child Differencing VHD Image such as to help you easily identify it and pay attention not to confuse this image with the Father VHD-one, then Press Next to Continue.
Pay attention: here you'll specify which one is the "Father VHD Image" of the previously-defined "Child Differencing Image".
Press Next to continue, then you'll be presented with a Summary of your selected options. Verify that everything is correct, then press "Finish" to end the "New Virtual Hard Disk Wizard".
New Child Virtual Machine.
Now, from the Hyper-V main window, you'll create the Child Virtual Machine.
Click on "New" -> "Virtual Machine…" and the "New Virtual Machine Wizard" will begin.
Name your new Child Virtual Machine to something that will help you recognize it (i.e.:CentOS-6.2×64-diff), and specify where your new Virtual Machine configuration files will be located then click "Next" to continue.
Specify the amount of memory to assign to your VM, depending from the available memory on your computer.
Select a network adapter from your LAN capable of going online (i.e.:your "External Virtual Network" adapter). It is not essential, but it's good give your new VM internet connectivity after CentOS-minimal has been installed.
Pay attention here: Select "Use an existing virtual hard disk", then "Browse…" for your previously created Child VHD (i.e.:D:\Data\HyperV\CentOS6.2×64-diff.vhd), to be attached to your Child VM.
Press Next, have a look at the Summary page, then press Finish to end the "New Virtual Machine Wizard".
Well done: now those 2 virtual machines are linked by a Father-Child relationship.
IF the Father VM is modified or missing somehow -> the Child VM won't be able to boot anymore (that's why, at the beginning of this article, I showed you how to set the Father VHD image to "Read-only").
On the contrary, now you can do whatever you desire inside your Child VM -- not only: you can make as many children copies as you wish.
Simply repeat the procedure explained by this article to create additional Children VMs!
You can simply boot your New Child VM while the Father VM is OFF!
While the Child VM boots, it will first read the Father VM's VHD, then will act upon its own VHD.
This procedure brings obvious advantages that will help you streamline your VM deployment.
The only disadvantage that comes to mind is, say you have 10 Children VMs, all depending from a single Parent VM: the Storage device holding the Parent VM will be under more stress as a result.
This is not always true, it highly depends on how you're going to use your Children VMs, but rest assured that if you're booting 10 VMs at once you will experience some bottlenecks.
Say you create a Parent VM, then create a couple of Children VMs, then install additional software on your Children VMs and limit yourself using only the services provided to you by the additional software and keep adding/reading data localized to every Children VMs (i.e.:apache, mysql, etc.): no worries here, the Parent VM will be read once and forgotten.
On the opposite side, say you need to read a lot from the kernel (and in the meantime you didn't update it from inside your new Child VM -- which I'd say it is highly unlikely): on this particular scenario, the "reads" will be against your Parent VM and the "writes" will be against your Child VM.
That's the only scenario I can think of as a "disadvantage": a very specific situation that won't affect the majority of users!
Other than that, the process is safe and works perfectly fine for your development purposes.
But I'm not over yet: over my next article I will present you a practical solution on how to definitively BREAK this parent-child relationship and allow you to create independent VMs starting from Children VMs.
So, if you had doubts about the potential disadvantage described above, look no further.
Follow me on twitter at https://twitter.com/amatesi and you'll get free updates about my new articles!