Chandler Posted November 2, 2019 Share Posted November 2, 2019 Last week my VM stopped working. Sometimes it would start but I would not be able to access it, other times during boot Unraid would pause it automatically. I and using a GPU passthrough and a separate dedicated SSD for the drive. I hooked up a monitor and watched it boot. When Unraid does not pause it automatically I get Windows startup repair. After playing around in that it says it cannot find the C:/ drive. Any ideas? Quote Link to comment
Squid Posted November 3, 2019 Share Posted November 3, 2019 Are you passing through the ssd, or have you simply created a vdisk on a dedicated ssd. Pausing *implies* that you sized the vdisk larger than the ssd Quote Link to comment
Chandler Posted November 3, 2019 Author Share Posted November 3, 2019 11 hours ago, Squid said: Are you passing through the ssd, or have you simply created a vdisk on a dedicated ssd. Pausing *implies* that you sized the vdisk larger than the ssd I have a vdisk on the ssd. I’m not sure if the pausing means the vdisk is larger than the ssd here. This vm has been working for over 6 months and just recently had this issue. I think it may have started when I upgrade to 6.7.2? I reverted back to 6.6.7 but the vm still will not start. Quote Link to comment
Squid Posted November 3, 2019 Share Posted November 3, 2019 Another possibility is that your VM is going to sleep Quote Link to comment
Chandler Posted November 3, 2019 Author Share Posted November 3, 2019 Just now, Squid said: Another possibility is that your VM is going to sleep Well when I hook up a monitor directly to the GPU and watch it boot, it loads windows startup repair. When I use cmd in there to try and run chkdsk or bootrec it says c:/ does not exist.. Quote Link to comment
Squid Posted November 3, 2019 Share Posted November 3, 2019 Then I would still go with the vdisk size is larger than the ssd. How much free space is available on that SSD? Quote Link to comment
Chandler Posted November 3, 2019 Author Share Posted November 3, 2019 1 hour ago, Squid said: Then I would still go with the vdisk size is larger than the ssd. How much free space is available on that SSD? It is a 240GB SSD and when I initially made the VM I gave it 230GB. Currently Unassigned Devices says there is 750KB free. Quote Link to comment
Squid Posted November 3, 2019 Share Posted November 3, 2019 3 minutes ago, Chandler said: 750KB free Full 3 minutes ago, Chandler said: 240GB SSD and when I initially made the VM I gave it 230GB. Probably the 230GB is actually GiB whereas the 240GB is actually GB, hence the problem as 230 GiB == 246GB Not quite sure how to properly recover here, but for next time, you can do this to keep the vdisk as small as possible https://forums.unraid.net/topic/51703-vm-faq/#comment-557606 Quote Link to comment
Chandler Posted November 3, 2019 Author Share Posted November 3, 2019 Just now, Squid said: Full Probably the 230GB is actually GiB whereas the 240GB is actually GB, hence the problem as 230 GiB == 246GB Not quite sure how to properly recover here, but for next time, you can do this to keep the vdisk as small as possible https://forums.unraid.net/topic/51703-vm-faq/#comment-557606 Hmm well do you know what would have just caused this? The VM has been running fine for months. Is it due to the VM attempting to use the full amount of what I allocated but there was more allocated than usable? Quote Link to comment
Squid Posted November 3, 2019 Share Posted November 3, 2019 Assuming Windows VM, without setting the vdisk up as a scsi drive (as detailed in the thread), the vdisk will always grow to it's maximum size, just from windows creating and then deleting temporary files. The size of the vdisk is the total of all all the files currently on the vdisk plus the size of every file ever created on the vdisk up to a maximum of the vdisk size. IE: No matter what you do it will always eventually (usually pretty quickly) hit the size of the vdisk you've set. The link describes how to set up the template and windows so that the vdisk will grow and shrink accordingly. Quote Link to comment
Chandler Posted November 3, 2019 Author Share Posted November 3, 2019 Just now, Squid said: Assuming Windows VM, without setting the vdisk up as a scsi drive (as detailed in the thread), the vdisk will always grow to it's maximum size, just from windows creating and then deleting temporary files. The size of the vdisk is the total of all all the files currently on the vdisk plus the size of every file ever created on the vdisk up to a maximum of the vdisk size. IE: No matter what you do it will always eventually (usually pretty quickly) hit the size of the vdisk you've set. The link describes how to set up the template and windows so that the vdisk will grow and shrink accordingly. Got it. I read through it and will follow that. Would moving my current vdisk to another drive that is larger than 240GB fix my problem so I can change to a scsi drive? Or is there any way to open the vdisk.img to extract files? Quote Link to comment
bastl Posted November 3, 2019 Share Posted November 3, 2019 20 minutes ago, Chandler said: Would moving my current vdisk to another drive that is larger than 240GB fix my problem so I can change to a scsi drive? Or is there any way to open the vdisk.img to extract files? You can try to move the vdisk to a bigger drive and attach it to a working VM and try to chkdsk and recover data from it. Quote Link to comment
Chandler Posted November 3, 2019 Author Share Posted November 3, 2019 1 hour ago, Squid said: IDK 41 minutes ago, bastl said: You can try to move the vdisk to a bigger drive and attach it to a working VM and try to chkdsk and recover data from it. Moving the vdisk to another drive let it boot up finally. Had to make 3 different VMs for it to work though.. I will try the scsi drive settings now. Thanks guys. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.