Dynamic Ramdisk with aim_ll

[homes32]

Is it possible to create a dynamic ramdisk using aim_ll?

I have created a .vhd to back the ramdrive and have tried aim_ll.exe -a -t vm -file X:\ramdrive.vhd -m B: without success. I can't seem to find any documentation or reference to creating a dynamic ramdisk via the commandline, so it's entirely possible I'm doing something wrong.

Thanks!

[homes32]

Another question, is it possible to use an un-formatted VHD template, and format it with /fs: during mount like with a regular fixed ramdrive? The use case would be from WinPE, so trying to save some space in boot.wim. NTFS filesystem takes 20-80 MB on an empty .vhd.

[LTRData]

There is no specific command line option for it, but it should be possible by referencing the relevant drivers in a chain, like: aim_ll -a -f \\?\vhdaccess\??\awealloc\??\C:\ramdisk.vhd -m B: -p "/fs:ntfs /q /y"`

This is essentially what the GUI application does behind the scenes when you select the menu option to create a dynamically allocated RAM disk from a vhd template.

[homes32]

Thanks for the reply.

I did some testing and aim_ll -a -f \\?\vhdaccess\??\awealloc\??\X:\ramdisk.vhd -m B: -p "/fs:ntfs /q /y" was not behaving properly (Error creating virtual disk: The system cannot find the path specified). I believe this is due to the WinPE cache overlay not registering as a volume (it's not visible in device/disk manager), being an overlay. I'm not sure how to resolve this.

I tried the -o awe option, but it doesn't expand the drive. How does the -o awe option differ from your example above?

[LTRData]

No, as long as the path from drive letter onwards is correct this should work even if the WinPE system volume is a bit special in that way. But you could get this error if awealloc or vhdaccess drivers are not loaded, so you could try net start awealloc etc first and see if that helps.

The -o awe option cannot be used in this case because as you have found out, it will allocate a fixed memory block for the entire virtual disk size. This is because this option adds the awealloc prefix first in the image file path, so it will see the disk contents above the vhd driver, that is the entire disk size after the vhd parser.

[homes32]

thanks for clarifying. both vhdaccess and awealloc were not running, and starting them fixed the issue.

that makes sense regarding the awe option as well. Thank you for your help and for developing the aim_ll tool. I like .net, but its also nice to have a lightweight no-frills tool for jobs like this, without the extra overhead.

[homes32]

Marking this solved as everything is working great when chaining the drivers after starting the relevant services. Thanks again!