The parent virtual disk has been modified since the child was created

Some VMs in my environment had virtual-mode RDMs on them, along with multiple nested snapshots. Some of the RDMs were subsequently extended at the storage array level, but the storage team didn’t realize there was an active snapshot on the virtual-mode RDMs. This resulted in immediate shutdown of the VMs and a vSphere client error “The parent virtual disk has been modified since the child was created” when attempting to power them back on.

I had done a little bit of work dealing with broken snapshot chains before, but the change in RDM size was outside of my wheelhouse, so we logged a call with VMware support. I learned some very handy debugging techniques from them and thought I’d share that information here. I went back into our test environment and recreated the situation that caused the problem.

In this example screenshot, we have a VM with no snapshot in place and we run vmkfstools –q –v10  against the vmdk file
-q means query, -v10 is verbosity level 10

The command opens up the disk, checks for errors, and reports back to you.

1_vmkfstools

 

In the second example, I’ve taken a snapshot of the VM. I’m now passing the snapshot VMDK into the vmkfstools command. You can see the command opening up the snapshot file, then opening up the base disk.

 

2_vmkfstools

 

In the third example, I  pass it the snapshot vmdk for a virtual-mode RDM on the same VM –  it traverses the snapshot chain and also correctly reports that the VMDK is a non-passthrough raw device mapping, which means virtual mode RDM.

 

3_vmkfstools

Part of the problem that happened was the size of the RDM changed (increased size) but the snapshot pointed to the wrong smaller size.  However, even without any changes to the storage, a corrupted snapshot chain can  happen  during an out-of-space situation.

I have intentionally introduced a drive geometry mismatch in my test VM below – note that the value after RW in the snapshot TEST-RDM_1-00003.vmdk  is 1 less than the value in the base disk  TEST-RDM_1.vmdk

4_vmkfstools

 

Now if I run it through the vmkfstools command, it reports the error that we were seeing in the vSphere client in Production when trying to boot the VMs – “The parent virtual disk has been modified since the child was created”. But the debugging mode gives you an additional clue that the vSphere client does not give– it says that the capacity of each link is different, and it even gives you the values (20368672 != 23068671).

5_vmkfstools
The fix was to follow the entire chain of snapshots and ensure everything was consistent. Start with the most current snap in the chain. The “parentCID” value must be equal to the “CID” value in the next snapshot in the chain. The next snapshot in the chain is listed in the “parentFileNameHint”.  So TEST-RDM_1-00003.vmdk is looking for a ParentCID value of 72861eac, and it expects to see that in the file TEST-RDM_1.vmdk.

If you open up Test-RDM_1.vmdk, you see a CID value of 72861eac – this is correct.  You also see an RW value of 23068672. Since this file is the base RDM, this is the correct value. The value in the snapshot is incorrect, so you have to go back and change it to match.  All snapshots in the chain must match in the same way.

4_vmkfstools

 

I change the RW value in the snapshot back to match  23068672 – my vmkfstools command succeeds, and I’m also able to delete the snapshot from the vSphere client6_vmkfstools

 

VDI for Education

There are countless arguments against deploying Virtual Desktop Infrastructure (VDI). Traditional desktops are cheap. VDI means you buy both a thin client and a rack of expensive servers and storage for your server room. You need a solid network backbone. You need substantial bandwidth for your remote sites. This all adds up to a significant capital expenditure.

Even in the face of these objections, VDI can be an attractive option for education. You need to go into it with the mindset that you’re not going to save capital expenses over a traditional desktop deployment. What you can achieve are substantial savings in operational expenses, major improvements in reliability and (typically) an increase in user satisfaction.

A few reasons why educational institutions should consider a VDI deployment:

  • With Microsoft’s Enrollment for Education and Software Assurance, schools have a simple, low-cost way to acquire the required Microsoft licenses. You pay a fixed cost based on the total number of full time employees you have. You count them once annually and you are covered for the entire year, even if you add staff. You can license Windows 7, Office, Windows Server, Exchange, Sharepoint, SCCM, Lync, and Forefront through the agreement. Your students are included at no charge. You read correctly – the district doesn’t pay one penny for student licensing. Every student is fully licensed to use the entire suite of Microsoft software that your staff is entitled to use.
  • Your computer magically follows you – at least that’s what it will feel like to your users. When you sit down at a thin client in the library, your profile loads and it feels like your own computer. Your preferences are all saved, your files are all there, your browser bookmarks are all available. When you move to the teacher lounge and log in, it’s the same. Classroom? Same. How about logging on to the desktop from the Internet? Still the same. This might be the number one feature that generates genuine excitement from your staff. Once they start getting used to having their profile follow them everywhere, they’ll never want to go back. Your users who travel from building to building are typically thrilled with this – no need to lug a laptop around.
  • Thin clients have no moving parts and no hard drive to fail. They don’t fail very often. If you do have to replace one, it’s a simple 5-10 minute process. No need to push a desktop image down, no need to reconfigure a user’s local profile or recover documents from their USB sticks. You won’t be performing hardware CPR for 2 days trying to resurrect a user’s machine. All you do is yank out the old thin client, install the new, and let the user log on. They see the same desktop that they saw before the hardware failure. If the user happens to have some critical task to complete before you can pull a spare thin client off your shelf, they can sit down at any thin client in the building and see their own desktop.
  • District IT staff doesn’t have to waste countless hours updating Macs. Macintosh computers are simply not geared for enterprise management. Think about running software updates on one Mac. Now run them on a whole lab full of Macs. Now run them on 10 labs full of Macs. Suddenly an entire work week is gone. With VDI, the process of manually updating each machine is eliminated. Instead, you update once and automatically deploy the updated image to your users. This, of course, assumes that you’re using a centralized image. VMware calls it linked clones, and Citrix calls it pooled desktops.
  • Everybody has the same version of installed software. There is no need to save your files down a version because the whole district has the same version of the Office suite. The benefits of this are difficult to quantify as it’s nearly impossible to calculate how much time people used to spend district-wide sending and resending documents due to compatibility problems. Your users will still be happy to never deal with that issue again.
  • Users aren’t going to like this at first, but if you use linked clones, it makes the IT department the gatekeeper for application installation. There is no way for users to install unauthorized applications. This can be both a blessing and a curse. On the plus side, users can’t sneak a garbage app into the environment. What will typically happen is a user gets grant money for some app, they install it themselves and then IT is stuck trying to band-aid it because it’s not a fit for the environment. With a linked clone environment, users quickly learn that they have to involve IT in the process before purchasing an application.
  • Users are typically blown away by the speed and responsiveness of the VDI desktops. It’s very common to go into an environment and see boot times of 5+ minutes, and logon times of 2-5 minutes. Replace that with a thin client boot time of 10 seconds and a logon time of 15-30 seconds and your users are overjoyed. A significant improvement in response time would be seen in any hardware refresh, virtual or not. However, pooling all of your CPUs, memory, and storage in the datacenter allows you to harness the computing power that would otherwise be sitting idle.
  • Electricity savings can be substantial. You would definitely have to take specific power readings in your environment before calculating ROI, but a desktop computer draws between 65-250 watts of power. A thin client such as the Wyse P20 draws 15 watts. If you multiply the savings by hundreds or thousands of workstations, you can get into some serious money. The savings is at least partially offset by the increase in power draw at your datacenter. In many cases, the cost savings is still significant.

Virtual desktop technology is mature enough to deploy into Production without concern. With a properly designed infrastructure, you can support your entire district and provide faster response and repair times to your users. If you’re looking for more information, my employer can help. Contact us and let us know what you’re looking for.