Running NTLite inside a VM - File Access Issues?

GraphicHealer

GraphicHealer

New Member
Messages
15
Reaction score
1
Hello!

I have NT-Lite currently setup inside a Virtual Machine on a server for easy bulk storage and file access.
The issue I keep running into is that NT-Lite for whatever reason doesn't like accessing files on a Remote Share. I cannot get it to pull or push any files to the share.

I also tried mounting a folder with KVM, and it does show up as a "Disk" type device, but somehow NT-Lite still detects it's not a proper Disk and will not use it.

Is there any way around this? I am currently using a physical HDD mounted directly in the VM, but this loses me an entire slot in the Server that I could use for more storage, and the NT-Lite files don't even fill up 10% of the drive.

Thanks!
- G

EDIT:
By "Mounted a Folder" I mean that I used the VirtIO-FS driver with KVM to mount a specific folder as a virtual storage drive. I also did install the correct VirtIO-FS Drivers and utility in Windows, so it should have mounted properly.

See this article for reference: https://sysguides.com/share-files-between-the-kvm-host-and-windows-guest-using-virtiofs
I did pretty much what the article does, but directly configured the XML instead of "Virtual Machine Manager".
 
Last edited:
NTLite, or generally any Windows image modding tool that uses DISM, needs a "local" filesystem to process images. There is a kernel filter driver which is applied to the mounted image, and it doesn't play nice with SMB shares. Not to mention the major performance problems caused by file locking over the network.

Trying to trick out the image mount point by stacking virtual filesystem on virtual filesystem tends to break the Servicing Stack.

If it weren't for the Servicing Stack's filesystem driver, then you wouldn't need Windows to prepare images, or a specific release of Windows. But it's more than just accessing plain files on a generic filesystem.
 
garlin said:
NTLite, or generally any Windows image modding tool that uses DISM, needs a "local" filesystem to process images. There is a kernel filter driver which is applied to the mounted image, and it doesn't play nice with SMB shares. Not to mention the major performance problems caused by file locking over the network.

Trying to trick out the image mount point by stacking virtual filesystem on virtual filesystem tends to break the Servicing Stack.

If it weren't for the Servicing Stack's filesystem driver, then you wouldn't need Windows to prepare images, or a specific release of Windows. But it's more than just accessing plain files on a generic filesystem.
Click to expand...
Well, to answer your first point, It's not "Over the Network" persay, it's all internal to the KVM backend, but yes my first try was using SMB, and that makes a lot of sense why it wouldn't do that now that you mention it, even with the SMB server being the Host machine.

For your second point, I am not pushing a virtual filesystem over a virtual filesystem. It's just one virtual filesystem, the VirtIO-FS. That is mounted directly to the linux filesystem on the machine running the KVM instance. No extra inbetween.

Here's the relevant section of the KVM XML Config:
XML: 
<filesystem type='mount' accessmode='passthrough'>
    <driver type='virtiofs' queue='1024'/>
    <binary path='/usr/libexec/virtiofsd' xattr='on'>
        <cache mode='always'/>
        <sandbox mode='chroot'/>
    </binary>
    <source dir='/mnt/user/NTLite'/>
    <target dir='NTLite'/>
    <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</filesystem>
 
Just out of curiousity, run the following DISM commands as Admin:
Code: 
mkdir C:\TempMount
DISM /Mount-image /imagefile:C:\path\to\ISO\sources\install.wim /Index:1 /MountDir:C:\TempMount
DISM /Unmount-image /MountDir:C:\TempMount /Discard

This attempts to mount the image, and then unmount it without making changes.
 
garlin said:
Just out of curiousity, run the following DISM commands as Admin:
Code: 
mkdir C:\TempMount
DISM /Mount-image /imagefile:C:\path\to\ISO\sources\install.wim /Index:1 /MountDir:C:\TempMount
DISM /Unmount-image /MountDir:C:\TempMount /Discard

This attempts to mount the image, and then unmount it without making changes.
Click to expand...
Sorry for the late reply, I have been on other projects the last couple weeks. (I also honestly kinda forgot about it...)
I will test that tomorrow when I get a chance. I'll let you know how it goes!
 
garlin I tested those commands, and it worked just fine. I wonder if it was an issue of where NTLite was temporarily mounting the images. I'll double-check.
 
This proves that the Windows filter driver works for DISM. I'm not sure if NTLite is pickier than that.
 
Lol, I found a workaround. I copied the image folder to the "D:\" drive (An extra USB drive I was using with the VM), selected it in NTLite, and then edited the settings.xml file to replace "D:\" with "Z:\" (the letter for the virtual drive) and it worked! I can see and edit the wim files!
 
As far as I can tell, NTLite checks the folder-structure of the folder you select.
Something in the particular way it scans the folders looks at permissions, it asks for a resource that VirtIO-FS does not have implemented.

Here is a link to a list of all the features WinFSP (The Filesystem Backend for VirtIO-FS) uses, and which ones are missing:

NTFS Compatibility · WinFsp

winfsp.dev winfsp.dev

Maybe you can switch to an alternate method of scanning the directory, and this will allow NTLite to have greater compatibility with more systems. Especially VMs.

garlin Maybe a future update can remedy this?
 
This is a definite no-go for WinFsp:
WinFsp does not support the following NTFS features:
  • Hard links. Rather rarely used on Windows. However it might be worthwhile to implement them for WinFsp.
Click to expand...

That statement is super false. It sounds true if you're not a native Windows dev.

Hard links are the absolute underpinning of how Windows installation works. Component files are written to the WinSxS repository during deployment, and everything in the system is hard linked back to WinSxS. When updates are applied, new component files are written to WinSxS and the system's hard links are swapped. This allows you to rollback updates, by switching links.

When an install image is mounted for modification (by NTLite or Windows DISM), there's hard links everywhere. And those links are encoded into the WIM archive format. Sorry, you'll have to find a more normal NTFS filesystem for NTLite's temp folders.
 
garlin said:
This is a definite no-go for WinFsp:


That statement is super false. It sounds true if you're not a native Windows dev.

Hard links are the absolute underpinning of how Windows installation works. Component files are written to the WinSxS repository during deployment, and everything in the system is hard linked back to WinSxS. When updates are applied, new component files are written to WinSxS and the system's hard links are swapped. This allows you to rollback updates, by switching links.

When an install image is mounted for modification (by NTLite or Windows DISM), there's hard links everywhere. And those links are encoded into the WIM archive format. Sorry, you'll have to find a more normal NTFS filesystem for NTLite's temp folders.
Click to expand...
Oh! Nooo! I was not saying Temp Folders. I was saying when you Scan for an Image (Add Image Directory). The temp folders absolutely DO NOT need to be on a WinFSP share. That would be AWFUL.

When NTLite scans a windows installation folder for .wim files is when that error is thrown. I believe that particular part of NTLite would be OK for WinFSP.

I have been editing some .wim files on the WinFSP share, and it seems to be working. I put the temp folders under the C:\ drive on my VM.
 
You must log in or register to reply here.
Back
Top