SSD and native boot VHD: and happiness was so close ...
Colleagues, I would like to again discuss the issue of increasing the resource SSD.
The idea, I think, is not new and is this: create a differential VHD, the basic part of which will be stored on the SSD, and the difference (relatively small) on the HDD. Thus, the number of entries on the SSD is significantly reduced, and Since a working system does not write as much data (and, accordingly, it doesn’t read much from this area), placing this information on the HDD should not lead to a significant drop in performance. Next, you only need to periodically merge disks to maintain system performance at the proper level. However, not everything was so simple ...
The main task is to have on hand a fairly productive and responsive environment (which is ensured by the presence in the SSD system) in the form of a host and virtual machines for various purposes.
The main problem is the many write operations that the host and virtual machines generate during operation, which adversely affects the SSD resource.
')
Rather fresh Windows 2012 Server R2 was chosen as the main experimental subject (there is a lot of interest in RemoteFX). But the same idea of ​​increasing the SSD resource will be true for Windows 8.1 Pro (only since this edition the native boot is supported, but RemoteFX is missing). The option of placing only a hypervisor on a host (for example, VMWare ESXi on a fast USB 3.0 flash drive) was rejected due to the urgent need to use the full power of the host in games and other hardware-demanding software.
There are many articles on the Internet about how to install an operating system on VHD and run it in native mode. But all articles describe either installation on a fixed-size VHD, or on a differential disk on the same volume as the base one. About this feature of working with differential disks said on the tech .
Studying the VHD format specification showed that the relative and absolute path to the parent image can be specified in the VHD format file.
The relative path is immediately rejected, but the absolute has become an interesting option. But practice has shown that there is an obvious problem with the fact that the drive letter is assigned at an unknown moment of the system boot and, the first thought, that is why it does not work. But in the Windows environment there is another way of addressing - by explicitly specifying the GUID of the volume instead of a letter, for example: \\? \ Volume {d460911b-7eb4-11e2-b6f8-806e6f6e6963} \ image.vhd
To simplify the verification, a virtual disk with a long name (C: \ 1234567890123456789012345678901234567890123456image.vhd) and a differential disk (D: \ image_diff.vhd) were created. Opening the differential VHD hex editor you can find the corresponding link to the parent VHD and change the path to \\? \ Volume {d460911b-7eb4-11e2-b6f8-806e6f6e6963} \ image.vhd ... After that, the disk is mounted to the system via diskpart. But ... The system installed on it does not work: error 0xC03A000D (problem with the chain of disk images). At the first approximation, it seemed that the problem lies in the fact that when using a hard disk with the MBR, the system generates random GUIDs for the volumes and what GUID is assigned to the volumes is not known.
Further study of the issue revealed that since Windows 8/2012, the VHDX disc format has appeared and they also support the Native boot. The VHDX specification found mention of the fact that the files of this format initially provided for saving the path to the parent VHDX in the path format with an indication of the volume's GUID (the so-called volume path). In this case, even the order of the parent disk search is specified: relative path, volume path, absolute win32 path.
After studying the created differential disk of the VHDX format and in the hex editor, it became clear that this information was indeed stored in a file. However, there is a problem with the GUID of the MBR volumes of the disks. But this was decided by partitioning the disk under GPT. With this partitioning option, the volume GUID becomes permanent. In this case, the basic disk should be located on the GPT volume, and the differential disk can be placed both on the GPT disk and on the MBR disk.
Experiments were conducted on the launch of the system with different combinations of disks and boot loaders (BIOS, EFI), but they did not bring results. The system still refuses to boot when the VHDX disk files are posted.
It was decided to spend a couple of hours and examine the loader itself under a microscope (Windows \ System32 \ winload.exe and Windows \ System32 \ winload.efi) starting with Windows 7. After that, everything went to its disappointing places:
Thus, it turns out that Windows 8/2012 contains in its arsenal the technology of creating hybrid disk systems, which can potentially increase the resource SSD + HDD at times. But for some reason this technology is not fully implemented in the loader, which is why it is impossible to put it into practice. One can only hope that in the next update (or release) the bootloader will be finalized.
So far, it remains to consider only the option with the classic acceleration of virtual machines: the host OS is placed on the HDD, the base disk of the virtual machines is placed on the SSD and snapshot is created on the HDD, which is periodically combined with the basic disk (by task or, for example, 1GB). Well, or just wait until the SSD at least equal to the HDD price / volume.
I would also like to know the opinion of readers on the question of whether it makes sense in this way to increase the resource SSD? Maybe the community has any other ideas on how to organize the scheme described? Maybe I missed something?
Thank you very much for the attention paid!
The idea, I think, is not new and is this: create a differential VHD, the basic part of which will be stored on the SSD, and the difference (relatively small) on the HDD. Thus, the number of entries on the SSD is significantly reduced, and Since a working system does not write as much data (and, accordingly, it doesn’t read much from this area), placing this information on the HDD should not lead to a significant drop in performance. Next, you only need to periodically merge disks to maintain system performance at the proper level. However, not everything was so simple ...
Environment
The main task is to have on hand a fairly productive and responsive environment (which is ensured by the presence in the SSD system) in the form of a host and virtual machines for various purposes.
The main problem is the many write operations that the host and virtual machines generate during operation, which adversely affects the SSD resource.
')
Rather fresh Windows 2012 Server R2 was chosen as the main experimental subject (there is a lot of interest in RemoteFX). But the same idea of ​​increasing the SSD resource will be true for Windows 8.1 Pro (only since this edition the native boot is supported, but RemoteFX is missing). The option of placing only a hypervisor on a host (for example, VMWare ESXi on a fast USB 3.0 flash drive) was rejected due to the urgent need to use the full power of the host in games and other hardware-demanding software.
There are many articles on the Internet about how to install an operating system on VHD and run it in native mode. But all articles describe either installation on a fixed-size VHD, or on a differential disk on the same volume as the base one. About this feature of working with differential disks said on the tech .
We study the question
Studying the VHD format specification showed that the relative and absolute path to the parent image can be specified in the VHD format file.
The relative path is immediately rejected, but the absolute has become an interesting option. But practice has shown that there is an obvious problem with the fact that the drive letter is assigned at an unknown moment of the system boot and, the first thought, that is why it does not work. But in the Windows environment there is another way of addressing - by explicitly specifying the GUID of the volume instead of a letter, for example: \\? \ Volume {d460911b-7eb4-11e2-b6f8-806e6f6e6963} \ image.vhd
To simplify the verification, a virtual disk with a long name (C: \ 1234567890123456789012345678901234567890123456image.vhd) and a differential disk (D: \ image_diff.vhd) were created. Opening the differential VHD hex editor you can find the corresponding link to the parent VHD and change the path to \\? \ Volume {d460911b-7eb4-11e2-b6f8-806e6f6e6963} \ image.vhd ... After that, the disk is mounted to the system via diskpart. But ... The system installed on it does not work: error 0xC03A000D (problem with the chain of disk images). At the first approximation, it seemed that the problem lies in the fact that when using a hard disk with the MBR, the system generates random GUIDs for the volumes and what GUID is assigned to the volumes is not known.
Further study of the issue revealed that since Windows 8/2012, the VHDX disc format has appeared and they also support the Native boot. The VHDX specification found mention of the fact that the files of this format initially provided for saving the path to the parent VHDX in the path format with an indication of the volume's GUID (the so-called volume path). In this case, even the order of the parent disk search is specified: relative path, volume path, absolute win32 path.
After studying the created differential disk of the VHDX format and in the hex editor, it became clear that this information was indeed stored in a file. However, there is a problem with the GUID of the MBR volumes of the disks. But this was decided by partitioning the disk under GPT. With this partitioning option, the volume GUID becomes permanent. In this case, the basic disk should be located on the GPT volume, and the differential disk can be placed both on the GPT disk and on the MBR disk.
Experiments were conducted on the launch of the system with different combinations of disks and boot loaders (BIOS, EFI), but they did not bring results. The system still refuses to boot when the VHDX disk files are posted.
It was decided to spend a couple of hours and examine the loader itself under a microscope (Windows \ System32 \ winload.exe and Windows \ System32 \ winload.efi) starting with Windows 7. After that, everything went to its disappointing places:
- Windows 7 - the bootloader has code only for working with VHD format disks
- Windows 8/2012 - in the bootloader there is a code to work with both VHD and VHDX disks ... but it only has work with relative path (relative_path) to the parent disk. And even writing a path with a GUID to this parameter does not give a positive result.
- Windows 8.1 / 2012R2 - the bootloader has grown somewhat in size, but has never acquired a full-fledged implementation of work with VHDX
Conclusion
Thus, it turns out that Windows 8/2012 contains in its arsenal the technology of creating hybrid disk systems, which can potentially increase the resource SSD + HDD at times. But for some reason this technology is not fully implemented in the loader, which is why it is impossible to put it into practice. One can only hope that in the next update (or release) the bootloader will be finalized.
So far, it remains to consider only the option with the classic acceleration of virtual machines: the host OS is placed on the HDD, the base disk of the virtual machines is placed on the SSD and snapshot is created on the HDD, which is periodically combined with the basic disk (by task or, for example, 1GB). Well, or just wait until the SSD at least equal to the HDD price / volume.
I would also like to know the opinion of readers on the question of whether it makes sense in this way to increase the resource SSD? Maybe the community has any other ideas on how to organize the scheme described? Maybe I missed something?
Thank you very much for the attention paid!
Source: https://habr.com/ru/post/213935/
All Articles