4 ms·

With a large storage space, once your installation is done, from a linux: cat /dev/sde3 > /storage/windows-vr-installation.bin Then when the install dies for

With a large storage space, once your installation is done, from a linux: cat /dev/sde3 > /storage/windows-vr-installation.bin Then when the install dies for some reason, restore it with: cat /storage/windows-vr-installation.bin > /dev/sde3 You will say it is inefficient. Maybe. On an optane 900, the burst write speed will be decent enough. Keeping .bin images that are a few Tb is not really a problem with modern setup (zfs, raid, etc.) I know there are commercial solutions doing that, but I wouldn't bother much with that. A simple free software setup will end up being more efficient if you know some basics. If I were you, I really wouldn't bother more than that with automation for reinstalls. You are not deploying to N identical devices (in which case the above trick may still work by having sufficiently similar workstations, and a special licensing scheme - I often buy a few similar laptops for the same reason). Regarding native performance, since being able to reconfigure windows quickly seems very important, if I were you I would do a GPU passthrough. KVM on computers with VT-d etc offers near native performance. That's what gamers do, and I trust them for their insane attention to fps performance :-) It may take some time for the initial tweaking (recompiling kernels, selecting some hardware etc) but it very possible, and also very stable. And it is more and more common. (disclamer: I sell such solutions, and do various weird things for my clients -- including supporting Wine when their need for a very stable solution is greater than the costs of the time I will bill them + the specific hardware I will have them buy to guarantee the speed of the results)

gt_ 9y ago
Thanks the response! It makes sense. It sounds like a similar result operationally to using something like Macrium for a master image backup. This is something I wanted to prevent because modifying that master image backup on a regular basis is such a task. With my scripting solution, it's just editing a few json files. My working environment is constantly changing, especially these days. My preferences also change as I optimize my workflows. My thoughts were to use the approach of For each change in implementation, make a change in code. The other important thing, to me, is that I am free to install any wacky software I may need to try without worrying what it's doing to my system. Something like intermittent backups will lead to accumulation of garbage files when doing this. And if I choose to adopt the software, I add it to my setup package. How do I modify the VM on a regular basis? I trust the input but maybe my understanding is limited by lack of context. I wish I could find a decent training source on this.
- devereaux 9y ago
  If your environment is changing every few day, just do a snapshot when you think the new environment is better. Keep a few snapshots to be able to go back to a previous image - like after installing some wacky software. When you overwrite the image, it will revert to the previous state, that's guaranteed :-) I also lack the context to recommend you a better solution. I do not like adding complexity unless it is needed. Hard drives are cheap. It may not worth the hassle to do something more complicated. Honestly, if the above is sufficient, don't even bother with a VM at first. Just reboot to Linux when you need to go back to a given image. It will take a few minutes, half an hour top, and you're good to go. A VM makes sense if you are short on space for the snapshot AND you would benefit from it -- like if you are doing half your work in Linux anyway, or if you have some specific security constraints. It could also be because you can't even tolerate the minutes it take to restore an image. Setting a VM with GPU passthrough/eGPU/kvm/Windows hosts/etc. is very tricky, especially when performance matters. I can't point you to a training source because it depends so much on the situation -- and it's evolving quickly too. If you want training or a dedicated solution, I offer results oriented consulting services. Let me know your email and we can discuss a solution more tailored to your specific situation - I will recommend a specific setup, get it running for you, and train you on how to use and change it, so that you don't end up needing me after that.
  - gt_ 9y ago
    Yeah that GPU passthrough sounds pretty awesome. As for the environment reload solution, your solution sounds like the best one for most people, and probably the best one for me in practice, to be honest. But there is some value the scripted solution serves which snapshots cannot. Updates to the snapshots require some planning. If a wacky software is tried and uninstalled, it is no longer safe to run updates to the snapshot until implementing another refresh. My scripting solution is just a code mod and git push and I can freely test wacky software and update my configuration in any order I like. I guess you could say image snapshots have an accumulation cost. A refresh is not a refresh to new but a refresh to old on a certain date. When I have a failure, I want to isolate issues as soon as possible. Determining whether it's a hardware issue or software issue can cost a lot of time and distraction. The fastest and surest way I know to do this is with an OS reinstall from the distributed source (Original Windows ISO). Image snapshots only theoretically isolate from system changes made since original OS install, and that level of isolation is getting harder to confirm as software deliveries get more common. These probably qualify as edge cases, but edge cases are most of what this is about. Edge cases are notorious for undermining production deadlines in an environment not prepared for them. A funny thing about that is they are also one of the hardest for people to admit or understand. Telling a non-technical client the job won't be done in time because of a software bug carries a burden of understanding hard to put into words. Of course, studios are prepared. But freelancers are generally not. A particular pain point with GPU rendering has been depending depending on driver/hardware/OS compatibility which has different needs than the priorities of gamers. That is changing, thankfully. But, the value of isolating software issues from the hardware is big to me. I juggle hard drives like nobody's business as it is, so I'm not opposed to that. And while it's nice, source control might be overkill for something I might not even need for months on end.

gt_ 9y ago

Thanks the response! It makes sense. It sounds like a similar result operationally to using something like Macrium for a master image backup. This is something I wanted to prevent because modifying that master image backup on a regular basis is such a task. With my scripting solution, it's just editing a few json files. My working environment is constantly changing, especially these days. My preferences also change as I optimize my workflows. My thoughts were to use the approach of For each change in implementation, make a change in code. The other important thing, to me, is that I am free to install any wacky software I may need to try without worrying what it's doing to my system. Something like intermittent backups will lead to accumulation of garbage files when doing this. And if I choose to adopt the software, I add it to my setup package. How do I modify the VM on a regular basis? I trust the input but maybe my understanding is limited by lack of context. I wish I could find a decent training source on this.

devereaux 9y ago
If your environment is changing every few day, just do a snapshot when you think the new environment is better. Keep a few snapshots to be able to go back to a previous image - like after installing some wacky software. When you overwrite the image, it will revert to the previous state, that's guaranteed :-) I also lack the context to recommend you a better solution. I do not like adding complexity unless it is needed. Hard drives are cheap. It may not worth the hassle to do something more complicated. Honestly, if the above is sufficient, don't even bother with a VM at first. Just reboot to Linux when you need to go back to a given image. It will take a few minutes, half an hour top, and you're good to go. A VM makes sense if you are short on space for the snapshot AND you would benefit from it -- like if you are doing half your work in Linux anyway, or if you have some specific security constraints. It could also be because you can't even tolerate the minutes it take to restore an image. Setting a VM with GPU passthrough/eGPU/kvm/Windows hosts/etc. is very tricky, especially when performance matters. I can't point you to a training source because it depends so much on the situation -- and it's evolving quickly too. If you want training or a dedicated solution, I offer results oriented consulting services. Let me know your email and we can discuss a solution more tailored to your specific situation - I will recommend a specific setup, get it running for you, and train you on how to use and change it, so that you don't end up needing me after that.
- gt_ 9y ago
  Yeah that GPU passthrough sounds pretty awesome. As for the environment reload solution, your solution sounds like the best one for most people, and probably the best one for me in practice, to be honest. But there is some value the scripted solution serves which snapshots cannot. Updates to the snapshots require some planning. If a wacky software is tried and uninstalled, it is no longer safe to run updates to the snapshot until implementing another refresh. My scripting solution is just a code mod and git push and I can freely test wacky software and update my configuration in any order I like. I guess you could say image snapshots have an accumulation cost. A refresh is not a refresh to new but a refresh to old on a certain date. When I have a failure, I want to isolate issues as soon as possible. Determining whether it's a hardware issue or software issue can cost a lot of time and distraction. The fastest and surest way I know to do this is with an OS reinstall from the distributed source (Original Windows ISO). Image snapshots only theoretically isolate from system changes made since original OS install, and that level of isolation is getting harder to confirm as software deliveries get more common. These probably qualify as edge cases, but edge cases are most of what this is about. Edge cases are notorious for undermining production deadlines in an environment not prepared for them. A funny thing about that is they are also one of the hardest for people to admit or understand. Telling a non-technical client the job won't be done in time because of a software bug carries a burden of understanding hard to put into words. Of course, studios are prepared. But freelancers are generally not. A particular pain point with GPU rendering has been depending depending on driver/hardware/OS compatibility which has different needs than the priorities of gamers. That is changing, thankfully. But, the value of isolating software issues from the hardware is big to me. I juggle hard drives like nobody's business as it is, so I'm not opposed to that. And while it's nice, source control might be overkill for something I might not even need for months on end.