I don't suppose this for kernel modules or portage trees, is it? That's what I've seen this mechanism used for...
So, sure enough it's easy to have all of your guests have a filesystem image file attached to them as a read-only block device. It's also very straightforward to have that mounted somewhere in the guest (/etc/fstab and all that Jazz). Ownerships you'll presumably take care of in the block device anyway (assuming you're using a filesystem type that stores that metadata -- but if you're using, say, VFAT, ownership is only a mount option away anyway).
The trick is handling updates. Once you've got your "block device" mounted in any guest, nothing can be allowed to update it. It just won't work, because nobody knows that someone else is updating the contents, so everything falls apart. Instead, you need to create a copy of the file with the filesystem image, make whatever changes are needed, and then trigger some sort of update action to make the guests unmount the old "filesystem", then the dom0 can detach the old file and attach the new one, before the guest remounts the filesystem.
In the cases I've used this, we actually had some code in the domU config files (since they're just Python anyway) to find the newest of these block devices and attach that, then the usual boot-time mounts did the right thing. So, for us, the "update process" was "reboot the guest". Whether that works for you, though, is a question I can't answer because I don't know what you're trying to use this for.
Alternately, just have a second NFS server that is only used for supplying these files to your domUs. It's probably easier than all this block device frufru (we had some pretty specific requirements that made it the least-worst option, but I don't expect they apply in your case -- in fact, I know they don't apply in your case, because you've already got an NFS server).
There are two types of errors in Powershell, terminating errors and non-terminating errors. Check out the help for about_try_catch_finally for more info.
If I try this
try
{
jimjim-cmdlet
}
catch
{
"It's a jimjim error!"
}
the nonsense cmdlet will generate a terminating error which will be caught by the catch block.
The code you are running is not throwing a terminating error, so execution throws the non-terminating error and continues after the catch block.
Also see this page, http://powershell.com/cs/forums/p/521/703.aspx, for more information.
I am still a little fuzzy on when exactly a terminating error is thrown as opposed to a non-terminating error (perhaps more knowledgable folks can help out).
Best Answer
Kernel Panic is correct about the PSDrive cmdlet being usable only within the PowerShell environment. The TechNet article ‘Using the New –PSDrive Cmdlet’ states ‘Mapped drives last only as long as your current Windows PowerShell session.’ However, you can create a configuration file that will re-map the drives every time you start PowerShell.
Further, the TechNet Article ‘Converting the Windows Script Host MapNetworkDrive Method’ also states that any drive created with the –PSDrive cmdlet ‘can be used exactly like any other mapped network drive as long as you are working in Windows PowerShell.’ This is a PowerShell Drive and not a true mapped drive. This article goes on to show that you can map drives in PowerShell using the Net Use command:
Hope this helps,