So I stupidly removed drives from one of my unRAID servers which is used mainly for its sole Windows 10 virtual machine. When I put them back, I had a brain fart and mixed them up, did a new config and bam all my shares for my VM are gone. This VM runs on its own SSD and that is intact, what is gone is everything else. What do I need to do to get back to booting this VM?

 

The OS install path was this: mnt/windowsVM/ISO/Win10_1511_English_x64.iso

 

The VirtIO ISO Drivers path was this: mnt/windowsVM/Drivers/virtio-win-0.1.112.iso

 

The primary vdisk image path was this: /mnt/windowsVM/Windows 10/vdisk1.img

 

Am I toast? Do I need to start from scratch again and reinstall Windows?

So I stupidly removed drives from one of my unRAID servers which is used mainly for its sole Windows 10 virtual machine. When I put them back, I had a brain fart and mixed them up, did a new config and bam all my shares for my VM are gone. This VM runs on its own SSD and that is intact, what is gone is everything else. What do I need to do to get back to booting this VM?

 

The OS install path was this: mnt/windowsVM/ISO/Win10_1511_English_x64.iso

 

The VirtIO ISO Drivers path was this: mnt/windowsVM/Drivers/virtio-win-0.1.112.iso

 

The primary vdisk image path was this: /mnt/windowsVM/Windows 10/vdisk1.img

 

Am I toast? Do I need to start from scratch again and reinstall Windows?

Not entirely clear from your description how you actually lost them. Did you put the wrong disk in the parity slot or what?

You should be able to create a new win 10 vm and manually set it to the disk image you have previously created. If it won't let you select it from the toggle/dropdown, then you may have to edit the xml for it. Just redownload the virtio drivers and load those from their default location when you create the vm.

 

*Might* have an issue with nvram, but I don't think you can mess up the image trying. I do this all the time with OS X images... same principal I believe. If you're worried, make a copy and do it with that.

Something like the Trurl, I wasn't thinking.

Actually I have figured out that everything I need is on my SSD, however when I try and start the VM I keep getting this error which I can't seem to fix.

 

 

make sure you re-downloaded the virtio drivers in the vm tab(if you don't have them already) and/or that you have the xml/vm creator/manager pointed to the correct folder/file.

 

sorry, that was a lot of /'s

I'm curious about something.

 

Where did the /mnt/WindowsVM mount come into being?  (Is this mount point on an unassigned device mounted via the UD plugin?)

 

Old versions of UD used to allow mount points such as that, but that feature was long ago deprecated, and IIRC if you try and recreate that particular mount point with UD it looks like it sort of works, but it doesn't.

 

All UD mount points are now (and have to be) within /mnt/disks/...

Yes Squid, its on an SSD which is an UD, this server is running unRAID 6.2.3 so it's not that old, I can't remember what version of unRAID I was running when I created the Windows 10 VM it may have been before 6.2 but the settings I have were working before I removed the disks, now I've put them back I am getting that error when I try to start the VM. Any clues as how I might fix it? I've checked the XML and everything is pointing to where it should, not sure what to do next.

You were bang on Squid, when I changed the paths to /mnt/disks it booted the VM, problem is now that is booting into Windows setup, I don't know why. Wondering what I should do, I don't want to lose my existing install, if I let windows install it shouldn't over write my existing install. Wonder why its booting into Windows setup?

You were bang on Squid, when I changed the paths to /mnt/disks it booted the VM, problem is now that is booting into Windows setup, I don't know why. Wondering what I should do, I don't want to lose my existing install, if I let windows install it shouldn't over write my existing install. Wonder why its booting into Windows setup?

Usually, Windows setup only boots if the vdisk is corrupted / non-existent.  You can try removing the setup ISO from the template to basically force the system to boot from the vdisk, but I don't think that's going to work.

 

Does the vdisk exist in that folder?

Somehow now I have two folders on the SSD called Windows 10 both have disk images in them, one that is 483GB which is the proper size and one that is 519GB, although I don't know how they could both possibly be on the same SSD because its only 500GB itself. Not sure how to get rid of the one that is 519GB.

Somehow now I have two folders on the SSD called Windows 10 both have disk images in them, one that is 483GB which is the proper size and one that is 519GB, although I don't know how they could both possibly be on the same SSD because its only 500GB itself. Not sure how to get rid of the one that is 519GB.

They can probably both exist at the moment as vdisk images are stored as sparse files (I.e. Only allocate physical space for used space within the file).  However you will hit problems at a later point as the images fill up until the required space no longer fits on the drive.

The bigger problem is the vdisk names are the same and so the VM won't boot. How can I delete the other folder with the wrong vdisk image in it?

The bigger problem is the vdisk names are the same and so the VM won't boot. How can I delete the other folder with the wrong vdisk image in it?

Are you sure the names are exactly the same? Linux is case-sensitive so if you have used upper or lower case letters differently they will be different as far as Linux is concerned, but will be the same as far as SMB (Windows networking) is concerned.

From the unrAID gui, when I navigate into the SSD, yes the folders Windows 10 VM and then inside, vdisk1.img are both named exactly the same. Is there a way to delete the wrong one?

From the unrAID gui, when I navigate into the SSD, yes the folders Windows 10 VM and then inside, vdisk1.img are both named exactly the same. Is there a way to delete the wrong one?

I would take a look at them from the command line.

You've odds on got same folder different case and the vdisk location set to auto.  Change it to manual and point it at the correct folder. 

 

I'd do this before you delete anything just in case

 

Sent from my LG-D852 using Tapatalk

 

 

Vdisk is set to manual with the correct path. I am posting my XML for you guys to take a look at, perhaps there is an error in there somewhere, although I don't see any.

 

 

<domain type='kvm'>
  <name>Windows 10</name>
  <uuid>2d78105a-93c9-9428-1e35-4a04eb1b0e73</uuid>
  <description>Unraid Windows 10 VM</description>
  <metadata>
    <vmtemplate xmlns="unraid" name="Windows 10" icon="windows.png" os="windows10"/>
  </metadata>
  <memory unit='KiB'>8388608</memory>
  <currentMemory unit='KiB'>8388608</currentMemory>
  <memoryBacking>
    <nosharepages/>
    <locked/>
  </memoryBacking>
  <vcpu placement='static'>4</vcpu>
  <cputune>
    <vcpupin vcpu='0' cpuset='0'/>
    <vcpupin vcpu='1' cpuset='1'/>
    <vcpupin vcpu='2' cpuset='2'/>
    <vcpupin vcpu='3' cpuset='3'/>
  </cputune>
  <os>
    <type arch='x86_64' machine='pc-i440fx-2.3'>hvm</type>
  </os>
  <features>
    <acpi/>
    <apic/>
  </features>
  <cpu mode='host-passthrough'>
    <topology sockets='1' cores='2' threads='2'/>
  </cpu>
  <clock offset='localtime'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='hpet' present='no'/>
  </clock>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <devices>
    <emulator>/usr/local/sbin/qemu</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw' cache='writeback'/>
      <source file='/mnt/disks/windowsVM/WIndows 10/vdisk1.img'/>
      <target dev='hdc' bus='virtio'/>
      <boot order='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </disk>
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='mnt/disks/windowsVM/ISO/Win10_1511_English_x64.iso'/>
      <target dev='hda' bus='ide'/>
      <readonly/>
      <boot order='2'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='mnt/disks/windowsVM/Drivers/virtio-win-0.1.112.iso'/>
      <target dev='hdb' bus='ide'/>
      <readonly/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>
    <controller type='usb' index='0' model='nec-xhci'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
    </controller>
    <controller type='pci' index='0' model='pci-root'/>
    <controller type='ide' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
    </controller>
    <controller type='virtio-serial' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </controller>
    <interface type='bridge'>
      <mac address='52:54:00:83:43:84'/>
      <source bridge='br0'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </interface>
    <serial type='pty'>
      <target port='0'/>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
    <channel type='unix'>
      <source mode='connect'/>
      <target type='virtio' name='org.qemu.guest_agent.0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    </channel>
    <hostdev mode='subsystem' type='pci' managed='yes' xvga='yes'>
      <driver name='vfio'/>
      <source>
        <address domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
      </source>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </hostdev>
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <driver name='vfio'/>
      <source>
        <address domain='0x0000' bus='0x00' slot='0x1b' function='0x0'/>
      </source>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </hostdev>
    <hostdev mode='subsystem' type='usb' managed='no'>
      <source>
        <vendor id='0x17ef'/>
        <product id='0x6019'/>
      </source>
    </hostdev>
    <hostdev mode='subsystem' type='usb' managed='no'>
      <source>
        <vendor id='0x413c'/>
        <product id='0x2105'/>
      </source>
    </hostdev>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
    </memballoon>
  </devices>
</domain>

      <source file='/mnt/disks/windowsVM/WIndows 10/vdisk1.img'/>

 

Sure that's correct WIndows 10 vs Windows 10?

 

What's the output of

ls /mnt/disks/windowsVM

 

So this is what I get when I SSH in a view the directories, its even more messed up. You can see there are two vdisk.img files, the vdisk1.img is the one I want. Is there a command to run from the shell that will show the file sizes?

 

Here is the output of that command:

 

root@Backup:/# ls /mnt/disks/windowsVM
Drivers/  ISO/  WIndows\ 10/  Windows\ 10/
root@Backup:/# 

 

 

root@Backup:/mnt/windowsVM# ls /
bin/   dev/  home/  lib/    mnt/   root/  sbin/  tmp/  var/
boot/  etc/  init@  lib64/  proc/  run/   sys/   usr/
root@Backup:/mnt/windowsVM# cd /
root@Backup:/# ls
bin/   dev/  home/  lib/    mnt/   root/  sbin/  tmp/  var/
boot/  etc/  init@  lib64/  proc/  run/   sys/   usr/
root@Backup:/# cd /mnt
root@Backup:/mnt# ls
disk1/  disk2/  disk3/  disks/  user/  windowsVM/
root@Backup:/mnt# cd windowsVM
root@Backup:/mnt/windowsVM# ls
WIndows\ 10/
root@Backup:/mnt/windowsVM# cd WIndows\ 10
root@Backup:/mnt/windowsVM/WIndows 10# ls
vdisk.img*  vdisk1.img*
root@Backup:/mnt/windowsVM/WIndows 10# 

ls -al

Now I'm getting messed up.

 

Where is the SSD actually mounted in /mnt/windowsVM or /mnt/disks/windowsVM?

 

If its now mounted in /mnt/disks/windowsVM then those 2 vdisks are actually stored in RAM....

 

Now I'm getting messed up.

 

Where is the SSD actually mounted in /mnt/windowsVM or /mnt/disks/windowsVM?

 

If its now mounted in /mnt/disks/windowsVM then those 2 vdisks are actually stored in RAM....

Not sure I am entirely following all the nuances here. Seems to me /mnt/disks/windowsVM is on an unassigned disk and /mnt/windowsVM is in RAM.

Now I'm getting messed up.

 

Where is the SSD actually mounted in /mnt/windowsVM or /mnt/disks/windowsVM?

 

If its now mounted in /mnt/disks/windowsVM then those 2 vdisks are actually stored in RAM....

Not sure I am entirely following all the nuances here. Seems to me /mnt/disks/windowsVM is on an unassigned disk and /mnt/windowsVM is in RAM.

Yeah youre correct.  I did an oopsie on the keyboard and didn't check what I typed  No... Its a nuance thing.  What I typed is correct... (because the previous ls outputs showed the vdisks in /mnt/windowsVM, and I asked where the SSD is mounted.  At least it makes sense to me  somehow 

 

Sent from my LG-D852 using Tapatalk

 

 

I thought maybe something was in RAM too so I rebooted the unRAID server, nope, still have the two Windows 10 folders with the two vdisk images. After the reboot I tried to start up the VM again, and it booted, but into Windows setup again. 

 

Yes, all my files should be on the SSD which is an unassigned disk.