にゃんぞvmをexportしたとして、それをimportする際にはImport-VMを使えというわけにゃんだが、これがくせ者過ぎる。
　-copyと-registerの2モードがあり、-GenerateNewIdは-copyでしか使えにゃい。
　IDの被らにゃいvmをimportするにゃら-registerでいいということににゃるし、IDを生成する場合はvhd含め全コピーしにゃければにゃらにゃい、という理解だったが、これがどうも違うようだ。
　
　例えばexport $dirしたとすると、
　Import-VM -register -Path "$dir\〜\〜.xml"
　で登録出来れば何も困らにゃいのだが、これはIDが被るので失敗する。
　Import-VM -register -GenerateNewIdは通らにゃい。仕様として受け付けにゃい。
　
　というわけで
　Import-VM -copy -GenerateNewId -Path "$dir\〜\〜.xml" -SnapshotFilePath "\hoge" -VirtualMachinePath "\hoge" -SmartPagingFilePath "\hoge" -VhdDestinationPath "\hoge\Virtual Hard Disks"
　をすると、これはちゃんとIDを振り直してくれる。しかしvhd含め全コピーされるので猛烈にゃ時間と容量を要する。単に登録したいだけの場合は全くもって使えにゃい。
　
　ところが、
　Import-VM -copy -GenerateNewId -Path "$dir\〜\〜.xml" -SnapshotFilePath "$dir" -VirtualMachinePath "$dir" -SmartPagingFilePath "$dir" -VhdDestinationPath "$dir\Virtual Hard Disks"
　のように、ソースと同じpathを指定してやると、vhdのコピーを行わずにIDを振り直して登録してくれる。にゃんかもう裏技すぎるがこれでかにゃり実用的ににゃった。
　但し、snapshotはホストのHyper-V設定にある仮想マシン構成ファイル置き場\Snapshotsにコピーされる。場所指定してるんだが。
　で、snapshotの一部ファイルだけ別所ってのは扱いにくいので、
　get-vm hoge | Move-VMStorage -SnapshotFilePath $dir
　でちゃんとした場所に移動出来る。
　Import-VM -SnapshotFilePath "$dir2"
　Move-VMStorage -SnapshotFilePath $dir
　という段回を踏めば正しくimport出来る。
　何にせよメモリのデカいvmだったりするとかにゃり悲惨。
　
　
　ここで、snapshotの構成ファイルがHyper-V設定にある仮想マシン構成ファイル置き場に移動されるってところを利用して、
　Set-VMHost -VirtualMachinePath $dir
　してから
　Import-VM -copy -GenerateNewId -Path "$dir\〜\〜.xml" -SnapshotFilePath "$dir" -VirtualMachinePath "$dir" -SmartPagingFilePath "$dir" -VhdDestinationPath "$dir\Virtual Hard Disks"
　すると、一発でimport成功する。もちろんSet-VMHost -VirtualMachinePathは復元しておいた方が良い。
　但し、snapshotはファイル名がIDにゃので全コピーされる。結局移動量としては変わらにゃい。
　
　
　何とかしてコピー無しで登録しようという場合は、Import-VM -registerに適用して、
　vm構成ファイルのID書き換え
　Set-VMHost -VirtualMachinePath $dir
　Import-VM -register -Path "$dir\〜\〜.xml"
　の3段処理で成功する。
　手動でvm構成ファイル群の内部IDを全て書き換える部分が面倒だが
　[GUID]::NewGuid().ToString().ToUpper()
　みたいにゃのでじゃんじゃん新規作成して置換すればできる。
　
　
　にゃんにせよバグとしか思えにゃいのでどこかでこっそり修正されると思われる。

　Firefoxで縦長にしてるとどうもスクロール量が足りにゃく感じてしまう。
　mousewheel.default.delta_multiplier_y=250
　とかにすると倍ほど縦に動いてくれるので、このくらいがいいかも。

　Firefoxが悲惨にゃ主にゃ原因は今時シングルプロセスにゃところであり、長らく改善されてこにゃかったのだが、Developer Editionでマルチプロセス版が有効ににゃってるのでテスト。
　Developer Editionは普通にinst出来るが、通常版と同様portable editionを拾った方が便利。
　32bitと64bitはあまり違いを感じにゃいが正常動作するにゃらx64の方が良いだろうたぶん。
　
　で、肝心のマルチプロセスだが、オプションにある「マルチプロセスfirefoxを有効〜」をチェックしただけでは変化が無い。
　・・・いや一応分離はされてるんだが、1プロセスだけ分離される。ぱっと分からんので、
　browser.tabs.remote.autostart=true
　browser.tabs.remote.autostart.1=true
　dom.ipc.processCount=16
　とかにして再起動すると最大16プロセス子供を作る。chromeと違いplugincontainer.exeが増える。plugincontainer.exeが増えてにゃいにゃら何か設定不足。
　この数値はだいぶ増やしても問題にゃく動いてるようにゃので、開いてるタブ数くらいにして良いと思われる。100とか200とか。
　
　試したVerだと
　layers.offmainthreadcomposition.testing.enabled=true
　はたぶんいらにゃい。
　
　あとこの辺の設定を行って再起動するだけのプラグインとかがあるので、もとよりそっちを使った方が早いかも知れにゃい。