[Solved] Windows VM - Hard Drive Passthrough or Assign


Recommended Posts

Hello, very new to unRaid. Tinkering with getting my setup online, a couple of questions.

 

I have had issues with, and read about issues people have had with running Plex Server, Sabnzbd etc in dockers, with hangs and such, so I would like to just proceed with installing them on my Blue Iris Windows VM. I need the VM for BlueIris anyways, so why not, right?

 

I currently have the windows VM online, with the VM image file on my cache drive(an SSD). I have another, old 250GB "scrap" drive, which I want to use for my download drive. I don't want the wear and tear of my downloads/extracts etc on my SSD's, and have this drive so figure why not use it.

 

1. How can I pass this 250GB drive on to my windows VM to use it as a download drive? I don't want to include this in my unRaid system or cache.

2. I actually have 2, 240GB Intel SSD's. Currently only one added as cache drive. Will add the second once I finish removing files from it. I have already created my cache with 1 drive, and put stuff, like my VMs on it. When I add the second, will I have to format and lose the data I have already? If so, options?

3. My Plex Media Server, I am thinking I will simply host it on my Windows VM as well, at least until the docker hang up issues all get sorted. My library is quite big, and growing. Once I set a VM image size, can I expand it later? Easily?

 

Thanks in advance!

Link to comment

Someone else may have a better idea so wait for their response!  Especially if you don't like what I'm going to suggest and there is an easier way.  But as I see it there are two options. 

 

[*] Add a two port controller card to your box and pass through the controller to the VM then put your drive on it.

[*]Add your drive to unRAID and us the UnassignedDevices plugin to mount the drive then create an image file on it that you add to your VM.

But as I said there may be more options that I haven't a clue existed.  If this was ESXi I would tell you to RDM the drive but I haven't see that as an option with unRAID or KVM for that matter.

Link to comment

Hello, very new to unRaid. Tinkering with getting my setup online, a couple of questions.

 

I have had issues with, and read about issues people have had with running Plex Server, Sabnzbd etc in dockers, with hangs and such, so I would like to just proceed with installing them on my Blue Iris Windows VM. I need the VM for BlueIris anyways, so why not, right?

 

I currently have the windows VM online, with the VM image file on my cache drive(an SSD). I have another, old 250GB "scrap" drive, which I want to use for my download drive. I don't want the wear and tear of my downloads/extracts etc on my SSD's, and have this drive so figure why not use it.

 

1. How can I pass this 250GB drive on to my windows VM to use it as a download drive? I don't want to include this in my unRaid system or cache.

2. I actually have 2, 240GB Intel SSD's. Currently only one added as cache drive. Will add the second once I finish removing files from it. I have already created my cache with 1 drive, and put stuff, like my VMs on it. When I add the second, will I have to format and lose the data I have already? If so, options?

3. My Plex Media Server, I am thinking I will simply host it on my Windows VM as well, at least until the docker hang up issues all get sorted. My library is quite big, and growing. Once I set a VM image size, can I expand it later? Easily?

 

Thanks in advance!

 

There is actually a way to pass through an entire block-level device to unRAID a virtual machine (not using a virtual disk image file at all).  I'll have to write this up in a reply for you a little later today.

Link to comment

Hello, very new to unRaid. Tinkering with getting my setup online, a couple of questions.

 

I have had issues with, and read about issues people have had with running Plex Server, Sabnzbd etc in dockers, with hangs and such, so I would like to just proceed with installing them on my Blue Iris Windows VM. I need the VM for BlueIris anyways, so why not, right?

 

I currently have the windows VM online, with the VM image file on my cache drive(an SSD). I have another, old 250GB "scrap" drive, which I want to use for my download drive. I don't want the wear and tear of my downloads/extracts etc on my SSD's, and have this drive so figure why not use it.

 

1. How can I pass this 250GB drive on to my windows VM to use it as a download drive? I don't want to include this in my unRaid system or cache.

2. I actually have 2, 240GB Intel SSD's. Currently only one added as cache drive. Will add the second once I finish removing files from it. I have already created my cache with 1 drive, and put stuff, like my VMs on it. When I add the second, will I have to format and lose the data I have already? If so, options?

3. My Plex Media Server, I am thinking I will simply host it on my Windows VM as well, at least until the docker hang up issues all get sorted. My library is quite big, and growing. Once I set a VM image size, can I expand it later? Easily?

 

Thanks in advance!

 

There is actually a way to pass through an entire block-level device to unRAID a virtual machine (not using a virtual disk image file at all).  I'll have to write this up in a reply for you a little later today.

 

That would be fantastic. I did some googling, and think I found a couple of options, however I am not 100% familiar with Linux, or at all with unRaid yet, and dont quite want to mess anything up. Thanks in advance!

Link to comment

Ok, so to pass through a full block device to a VM, here's what you need to do.  First, you need to identify the device you wish to do this with.  You can find a listing of your storage devices in the webGui under Tools -> System Devices -> SCSI Devices.  Once identified, note the SCSI device id in the first column.  Here's an example from one of my test systems.

 

[1:0:0:0]    disk    PNY      USB 3.0 FD       1.00  /dev/sdb 
[3:0:0:0]    disk    ATA      WDC WD20EARX-00P AB51  /dev/sdc 
[5:0:0:0]    disk    ATA      ST4000DM000-1F21 CC52  /dev/sdd 
[6:0:0:0]    disk    ATA      OCZ-VERTEX3      2.25  /dev/sde 
[8:0:0:0]    disk    ATA      ST4000DM000-1F21 CC52  /dev/sdf 
[9:0:0:0]    disk    ATA      WDC WD20EARX-00P AB51  /dev/sdg 
[10:0:0:0]   disk    ATA      ST2000DL003-9VT1 CC3C  /dev/sdh 
[11:0:0:0]   disk    ATA      WDC WD20EARX-00P AB51  /dev/sdi 

 

The first column is the scsi ID.  If I wanted to assign the /dev/sdi device (a western digital device), I would need to note the 11:0:0:0 designation.  Next, I need to edit the XML for my VM.  Goto the VMs tab, click on the icon for the VM we're dealing with, and then select Edit XML.

 

NOTE:  Once you do this, you will not be able to use the GUI editor to make changes to your VM without losing these edits, so before proceeding, use the GUI editor to get your memory, CPU pinning, and any other device assignments all set.

 

In the XML, add the following code:

 

<controller type='scsi' model='virtio-scsi'/>

    <hostdev mode='subsystem' type='scsi' rawio='yes'>

      <source>

        <adapter name='scsi_host11'/>

        <address bus='0' target='0' unit='0'/>

      </source>

      <readonly/>

    </hostdev>

 

Adjust the large bolded numbers for the four numbers in the scsi id.  For most, this will only be the first number in the <adapter> section.

 

If you are installing Windows directly to this device, you will need to load the vioscsi driver during the installation process for the installer to detect the device.  Follow the same procedure as is documented in the wiki for setting up a normal Windows VM, but instead of selecting viostor, browse to the vioscsi folder.

 

Let me know if any of this is unclear or if this doesn't work for you.

  • Like 1
Link to comment

Ok, so to pass through a full block device to a VM, here's what you need to do.  First, you need to identify the device you wish to do this with.  You can find a listing of your storage devices in the webGui under Tools -> System Devices -> SCSI Devices.  Once identified, note the SCSI device id in the first column.  Here's an example from one of my test systems.

 

[1:0:0:0]    disk    PNY      USB 3.0 FD       1.00  /dev/sdb 
[3:0:0:0]    disk    ATA      WDC WD20EARX-00P AB51  /dev/sdc 
[5:0:0:0]    disk    ATA      ST4000DM000-1F21 CC52  /dev/sdd 
[6:0:0:0]    disk    ATA      OCZ-VERTEX3      2.25  /dev/sde 
[8:0:0:0]    disk    ATA      ST4000DM000-1F21 CC52  /dev/sdf 
[9:0:0:0]    disk    ATA      WDC WD20EARX-00P AB51  /dev/sdg 
[10:0:0:0]   disk    ATA      ST2000DL003-9VT1 CC3C  /dev/sdh 
[11:0:0:0]   disk    ATA      WDC WD20EARX-00P AB51  /dev/sdi 

 

The first column is the scsi ID.  If I wanted to assign the /dev/sdi device (a western digital device), I would need to note the 11:0:0:0 designation.  Next, I need to edit the XML for my VM.  Goto the VMs tab, click on the icon for the VM we're dealing with, and then select Edit XML.

 

NOTE:  Once you do this, you will not be able to use the GUI editor to make changes to your VM without losing these edits, so before proceeding, use the GUI editor to get your memory, CPU pinning, and any other device assignments all set.

 

In the XML, add the following code:

 

<controller type='scsi' model='virtio-scsi'/>

    <hostdev mode='subsystem' type='scsi' rawio='yes'>

      <source>

        <adapter name='scsi_host11'/>

        <address bus='0' target='0' unit='0'/>

      </source>

      <readonly/>

    </hostdev>

 

Adjust the large bolded numbers for the four numbers in the scsi id.  For most, this will only be the first number in the <adapter> section.

 

If you are installing Windows directly to this device, you will need to load the vioscsi driver during the installation process for the installer to detect the device.  Follow the same procedure as is documented in the wiki for setting up a normal Windows VM, but instead of selecting viostor, browse to the vioscsi folder.

 

Let me know if any of this is unclear or if this doesn't work for you.

 

 

Worked like a charm, thanks so much!

Link to comment

Ok, so to pass through a full block device to a VM, here's what you need to do.  First, you need to identify the device you wish to do this with.  You can find a listing of your storage devices in the webGui under Tools -> System Devices -> SCSI Devices.  Once identified, note the SCSI device id in the first column.  Here's an example from one of my test systems.

 

[1:0:0:0]    disk    PNY      USB 3.0 FD       1.00  /dev/sdb 
[3:0:0:0]    disk    ATA      WDC WD20EARX-00P AB51  /dev/sdc 
[5:0:0:0]    disk    ATA      ST4000DM000-1F21 CC52  /dev/sdd 
[6:0:0:0]    disk    ATA      OCZ-VERTEX3      2.25  /dev/sde 
[8:0:0:0]    disk    ATA      ST4000DM000-1F21 CC52  /dev/sdf 
[9:0:0:0]    disk    ATA      WDC WD20EARX-00P AB51  /dev/sdg 
[10:0:0:0]   disk    ATA      ST2000DL003-9VT1 CC3C  /dev/sdh 
[11:0:0:0]   disk    ATA      WDC WD20EARX-00P AB51  /dev/sdi 

 

The first column is the scsi ID.  If I wanted to assign the /dev/sdi device (a western digital device), I would need to note the 11:0:0:0 designation.  Next, I need to edit the XML for my VM.  Goto the VMs tab, click on the icon for the VM we're dealing with, and then select Edit XML.

...

 

JonP, this is rather worrisome.  Those SCSI ID's can change, just as much as the sd symbols and the ata numbers.  It's true that some systems seem to be more 'stable', especially small systems with no added disk controllers, but otherwise, I can't see how hard coding the SCSI ID in will work across boots.  It will at times, but not reliably.  A user could reboot and it would stop working, then reboot again, and it would start working, if that session happened to match the same lsscsi list.  If you have multiple diagnostics zips available, test this yourself, compare the lsscsi.txt files.

Link to comment

Ok, so to pass through a full block device to a VM, here's what you need to do.  First, you need to identify the device you wish to do this with.  You can find a listing of your storage devices in the webGui under Tools -> System Devices -> SCSI Devices.  Once identified, note the SCSI device id in the first column.  Here's an example from one of my test systems.

 

[1:0:0:0]    disk    PNY      USB 3.0 FD       1.00  /dev/sdb 
[3:0:0:0]    disk    ATA      WDC WD20EARX-00P AB51  /dev/sdc 
[5:0:0:0]    disk    ATA      ST4000DM000-1F21 CC52  /dev/sdd 
[6:0:0:0]    disk    ATA      OCZ-VERTEX3      2.25  /dev/sde 
[8:0:0:0]    disk    ATA      ST4000DM000-1F21 CC52  /dev/sdf 
[9:0:0:0]    disk    ATA      WDC WD20EARX-00P AB51  /dev/sdg 
[10:0:0:0]   disk    ATA      ST2000DL003-9VT1 CC3C  /dev/sdh 
[11:0:0:0]   disk    ATA      WDC WD20EARX-00P AB51  /dev/sdi 

 

The first column is the scsi ID.  If I wanted to assign the /dev/sdi device (a western digital device), I would need to note the 11:0:0:0 designation.  Next, I need to edit the XML for my VM.  Goto the VMs tab, click on the icon for the VM we're dealing with, and then select Edit XML.

...

 

JonP, this is rather worrisome.  Those SCSI ID's can change, just as much as the sd symbols and the ata numbers.  It's true that some systems seem to be more 'stable', especially small systems with no added disk controllers, but otherwise, I can't see how hard coding the SCSI ID in will work across boots.  It will at times, but not reliably.  A user could reboot and it would stop working, then reboot again, and it would start working, if that session happened to match the same lsscsi list.  If you have multiple diagnostics zips available, test this yourself, compare the lsscsi.txt files.

 

I personally haven't had this issue, but yes, some may.  This is why we haven't put it formally into the webGui yet.

 

Eric and I are working on a VM device manager for the webGui.  The goal here is to manage device assignments differently, where a user could specify a device for use with a VM, then we would do the legwork at runtime to determine the appropriate changes to XML for VMs.  E.g., if the SCSI address changed, the /dev/disk/by-id path won't, and we can use something like udevadm to trace back to the actually SCSI ID.

 

There is another method for passing through a block device as well which we are experimenting with, and doesn't use SCSI IDs.  The difference in methods could impact performance though.

 

It should be noted that whenever I provide these guides, they are a temporary way to establish a level of functionality that isn't supported officially in the webGui yet.  I want to hear from folks experiences in using these methods so we can adjust our formal support implementation path.

Link to comment

Ok, so to pass through a full block device to a VM, here's what you need to do.  First, you need to identify the device you wish to do this with.  You can find a listing of your storage devices in the webGui under Tools -> System Devices -> SCSI Devices.  Once identified, note the SCSI device id in the first column.  Here's an example from one of my test systems.

 

[1:0:0:0]    disk    PNY      USB 3.0 FD       1.00  /dev/sdb 
[3:0:0:0]    disk    ATA      WDC WD20EARX-00P AB51  /dev/sdc 
[5:0:0:0]    disk    ATA      ST4000DM000-1F21 CC52  /dev/sdd 
[6:0:0:0]    disk    ATA      OCZ-VERTEX3      2.25  /dev/sde 
[8:0:0:0]    disk    ATA      ST4000DM000-1F21 CC52  /dev/sdf 
[9:0:0:0]    disk    ATA      WDC WD20EARX-00P AB51  /dev/sdg 
[10:0:0:0]   disk    ATA      ST2000DL003-9VT1 CC3C  /dev/sdh 
[11:0:0:0]   disk    ATA      WDC WD20EARX-00P AB51  /dev/sdi 

 

The first column is the scsi ID.  If I wanted to assign the /dev/sdi device (a western digital device), I would need to note the 11:0:0:0 designation.  Next, I need to edit the XML for my VM.  Goto the VMs tab, click on the icon for the VM we're dealing with, and then select Edit XML.

...

 

JonP, this is rather worrisome.  Those SCSI ID's can change, just as much as the sd symbols and the ata numbers.  It's true that some systems seem to be more 'stable', especially small systems with no added disk controllers, but otherwise, I can't see how hard coding the SCSI ID in will work across boots.  It will at times, but not reliably.  A user could reboot and it would stop working, then reboot again, and it would start working, if that session happened to match the same lsscsi list.  If you have multiple diagnostics zips available, test this yourself, compare the lsscsi.txt files.

 

I personally haven't had this issue, but yes, some may.  This is why we haven't put it formally into the webGui yet.

 

Eric and I are working on a VM device manager for the webGui.  The goal here is to manage device assignments differently, where a user could specify a device for use with a VM, then we would do the legwork at runtime to determine the appropriate changes to XML for VMs.  E.g., if the SCSI address changed, the /dev/disk/by-id path won't, and we can use something like udevadm to trace back to the actually SCSI ID.

 

There is another method for passing through a block device as well which we are experimenting with, and doesn't use SCSI IDs.  The difference in methods could impact performance though.

 

It should be noted that whenever I provide these guides, they are a temporary way to establish a level of functionality that isn't supported officially in the webGui yet.  I want to hear from folks experiences in using these methods so we can adjust our formal support implementation path.

 

Baked in support would be awesome. Currently, when I reboot unRAID for whatever reason(new build here so im doing quite a lot right now), I have to go in a change the address, as the device address seems to change every reboot. Always changes between the same 2 numbers, oddly enough. Even changes when I don't touch my drives during the reboot/power off.

 

Also, as far as performance or issues, I am not positive this is unRAID/KVM/passthrough related yet, but my SABnzbD downloads are mostly failing. WinRAR unpack issues, "unexpected end of archive". Have even downloaded some NZB's which I had recently grabbed before making the unRAIR leap. Going to install on my desktop and test it out to see what might be up.

 

When I first booted the VM up with the disk passed through, I formatted, copied some files to/from to test, and windows gave me a filesystem corruption error(didnt jot it down). Ran it through a chkdsk and have not had that error since, though still have the odd unpack issues.

Link to comment

Ok, so to pass through a full block device to a VM, here's what you need to do.  First, you need to identify the device you wish to do this with.  You can find a listing of your storage devices in the webGui under Tools -> System Devices -> SCSI Devices.  Once identified, note the SCSI device id in the first column.  Here's an example from one of my test systems.

 

[1:0:0:0]    disk    PNY      USB 3.0 FD       1.00  /dev/sdb 
[3:0:0:0]    disk    ATA      WDC WD20EARX-00P AB51  /dev/sdc 
[5:0:0:0]    disk    ATA      ST4000DM000-1F21 CC52  /dev/sdd 
[6:0:0:0]    disk    ATA      OCZ-VERTEX3      2.25  /dev/sde 
[8:0:0:0]    disk    ATA      ST4000DM000-1F21 CC52  /dev/sdf 
[9:0:0:0]    disk    ATA      WDC WD20EARX-00P AB51  /dev/sdg 
[10:0:0:0]   disk    ATA      ST2000DL003-9VT1 CC3C  /dev/sdh 
[11:0:0:0]   disk    ATA      WDC WD20EARX-00P AB51  /dev/sdi 

 

The first column is the scsi ID.  If I wanted to assign the /dev/sdi device (a western digital device), I would need to note the 11:0:0:0 designation.  Next, I need to edit the XML for my VM.  Goto the VMs tab, click on the icon for the VM we're dealing with, and then select Edit XML.

...

 

JonP, this is rather worrisome.  Those SCSI ID's can change, just as much as the sd symbols and the ata numbers.  It's true that some systems seem to be more 'stable', especially small systems with no added disk controllers, but otherwise, I can't see how hard coding the SCSI ID in will work across boots.  It will at times, but not reliably.  A user could reboot and it would stop working, then reboot again, and it would start working, if that session happened to match the same lsscsi list.  If you have multiple diagnostics zips available, test this yourself, compare the lsscsi.txt files.

 

I personally haven't had this issue, but yes, some may.  This is why we haven't put it formally into the webGui yet.

 

Eric and I are working on a VM device manager for the webGui.  The goal here is to manage device assignments differently, where a user could specify a device for use with a VM, then we would do the legwork at runtime to determine the appropriate changes to XML for VMs.  E.g., if the SCSI address changed, the /dev/disk/by-id path won't, and we can use something like udevadm to trace back to the actually SCSI ID.

 

There is another method for passing through a block device as well which we are experimenting with, and doesn't use SCSI IDs.  The difference in methods could impact performance though.

 

It should be noted that whenever I provide these guides, they are a temporary way to establish a level of functionality that isn't supported officially in the webGui yet.  I want to hear from folks experiences in using these methods so we can adjust our formal support implementation path.

 

Baked in support would be awesome. Currently, when I reboot unRAID for whatever reason(new build here so im doing quite a lot right now), I have to go in a change the address, as the device address seems to change every reboot. Always changes between the same 2 numbers, oddly enough. Even changes when I don't touch my drives during the reboot/power off.

 

Also, as far as performance or issues, I am not positive this is unRAID/KVM/passthrough related yet, but my SABnzbD downloads are mostly failing. WinRAR unpack issues, "unexpected end of archive". Have even downloaded some NZB's which I had recently grabbed before making the unRAIR leap. Going to install on my desktop and test it out to see what might be up.

 

When I first booted the VM up with the disk passed through, I formatted, copied some files to/from to test, and windows gave me a filesystem corruption error(didnt jot it down). Ran it through a chkdsk and have not had that error since, though still have the odd unpack issues.

 

Ok, if you'd like to be a guinea pig, here's another method for passing through a block device that does not utilize the virtio-scsi controller.  Changing your existing VM to this may possibly not work (you may have to reinstall windows or try a few things to get it to boot again).

 

1 - Remove all the custom xml stuff I had you add originally.

2 - Add a new <disk> section that looks like this:

 

    <disk type='block' device='disk'>

      <driver name='qemu' type='raw' cache='writeback'/>

      <source dev='/dev/disk/by-id/YOUR DISK ID HERE'/>

      <target dev='hda' bus='virtio'/>

    </disk>

 

To find what to put in the highlighted portion, you will need to login to your server from command line.  Then type the following command:

 

ls /dev/disk/by-id

 

Find the one that represents your storage device (but without the -part1 at the end) and paste that in the section above that says YOUR DISK ID HERE.  This should work regardless of what SCSI IDs change to after reboots.

  • Like 1
  • Upvote 1
Link to comment

Ok, so to pass through a full block device to a VM, here's what you need to do.  First, you need to identify the device you wish to do this with.  You can find a listing of your storage devices in the webGui under Tools -> System Devices -> SCSI Devices.  Once identified, note the SCSI device id in the first column.  Here's an example from one of my test systems.

 

[1:0:0:0]    disk    PNY      USB 3.0 FD       1.00  /dev/sdb 
[3:0:0:0]    disk    ATA      WDC WD20EARX-00P AB51  /dev/sdc 
[5:0:0:0]    disk    ATA      ST4000DM000-1F21 CC52  /dev/sdd 
[6:0:0:0]    disk    ATA      OCZ-VERTEX3      2.25  /dev/sde 
[8:0:0:0]    disk    ATA      ST4000DM000-1F21 CC52  /dev/sdf 
[9:0:0:0]    disk    ATA      WDC WD20EARX-00P AB51  /dev/sdg 
[10:0:0:0]   disk    ATA      ST2000DL003-9VT1 CC3C  /dev/sdh 
[11:0:0:0]   disk    ATA      WDC WD20EARX-00P AB51  /dev/sdi 

 

The first column is the scsi ID.  If I wanted to assign the /dev/sdi device (a western digital device), I would need to note the 11:0:0:0 designation.  Next, I need to edit the XML for my VM.  Goto the VMs tab, click on the icon for the VM we're dealing with, and then select Edit XML.

...

 

JonP, this is rather worrisome.  Those SCSI ID's can change, just as much as the sd symbols and the ata numbers.  It's true that some systems seem to be more 'stable', especially small systems with no added disk controllers, but otherwise, I can't see how hard coding the SCSI ID in will work across boots.  It will at times, but not reliably.  A user could reboot and it would stop working, then reboot again, and it would start working, if that session happened to match the same lsscsi list.  If you have multiple diagnostics zips available, test this yourself, compare the lsscsi.txt files.

 

I personally haven't had this issue, but yes, some may.  This is why we haven't put it formally into the webGui yet.

 

Eric and I are working on a VM device manager for the webGui.  The goal here is to manage device assignments differently, where a user could specify a device for use with a VM, then we would do the legwork at runtime to determine the appropriate changes to XML for VMs.  E.g., if the SCSI address changed, the /dev/disk/by-id path won't, and we can use something like udevadm to trace back to the actually SCSI ID.

 

There is another method for passing through a block device as well which we are experimenting with, and doesn't use SCSI IDs.  The difference in methods could impact performance though.

 

It should be noted that whenever I provide these guides, they are a temporary way to establish a level of functionality that isn't supported officially in the webGui yet.  I want to hear from folks experiences in using these methods so we can adjust our formal support implementation path.

 

Baked in support would be awesome. Currently, when I reboot unRAID for whatever reason(new build here so im doing quite a lot right now), I have to go in a change the address, as the device address seems to change every reboot. Always changes between the same 2 numbers, oddly enough. Even changes when I don't touch my drives during the reboot/power off.

 

Also, as far as performance or issues, I am not positive this is unRAID/KVM/passthrough related yet, but my SABnzbD downloads are mostly failing. WinRAR unpack issues, "unexpected end of archive". Have even downloaded some NZB's which I had recently grabbed before making the unRAIR leap. Going to install on my desktop and test it out to see what might be up.

 

When I first booted the VM up with the disk passed through, I formatted, copied some files to/from to test, and windows gave me a filesystem corruption error(didnt jot it down). Ran it through a chkdsk and have not had that error since, though still have the odd unpack issues.

 

Ok, if you'd like to be a guinea pig, here's another method for passing through a block device that does not utilize the virtio-scsi controller.  Changing your existing VM to this may possibly not work (you may have to reinstall windows or try a few things to get it to boot again).

 

1 - Remove all the custom xml stuff I had you add originally.

2 - Add a new <disk> section that looks like this:

 

    <disk type='block' device='disk'>

      <driver name='qemu' type='raw' cache='writeback'/>

      <source dev='/dev/disk/by-id/YOUR DISK ID HERE'/>

      <target dev='hda' bus='virtio'/>

    </disk>

 

To find what to put in the highlighted portion, you will need to login to your server from command line.  Then type the following command:

 

ls /dev/disk/by-id

 

Find the one that represents your storage device (but without the -part1 at the end) and paste that in the section above that says YOUR DISK ID HERE.  This should work regardless of what SCSI IDs change to after reboots.

 

No problem being a guinea pig, though itll have to wait until later this weekend, as I am about to head out. Will let you know how it goes!

Link to comment

Tbh, this isn't "too" guinea pigish (did I just make that a word?), as I've set up VMs like this before.  I know it works, but the device to the guest OS will simply show up as a generic qemu/virtio storage device.  With the virtio-scsi controller setup, it's only emulating the storage controller, but the physical device is assigned, so it's a more native storage device experience.  Does this impact performance?  Maybe, but I honestly don't know because I haven't run benchmarks yet.

Link to comment
  • 3 months later...

Is this still considered a valid option for adding a disk to a VM? Been struggling for a couple days trying to get a unassigned hardrive shared using the plugin unassigned device setup to record an IP camera from a windows VM

 

Suggestion in unassigned devices thread was to assign the device completely to the VM and I have been hunting how to do it. Ultimately I would rather be a share but this would work as well..

 

Thanks

 

Mike

Link to comment

Worked great... Thanks..

 

Ideally I need to get the Unassigned Devices Plugin working. Then I don't have to assign the entire disk to video recording and can split it out with some other less important data that does not need to be part of the array.  It would be great if this was a native feature of UnRaid. Choose if it needs parity or not.

 

Mike

Link to comment
  • 10 months later...
  • 1 year later...
On 8/27/2015 at 1:41 AM, jonp said:

Ok, so to pass through a full block device to a VM, here's what you need to do.  First, you need to identify the device you wish to do this with.  You can find a listing of your storage devices in the webGui under Tools -> System Devices -> SCSI Devices.  Once identified, note the SCSI device id in the first column.  Here's an example from one of my test systems.

 

 


[1:0:0:0]    disk    PNY      USB 3.0 FD       1.00  /dev/sdb 
[3:0:0:0]    disk    ATA      WDC WD20EARX-00P AB51  /dev/sdc 
[5:0:0:0]    disk    ATA      ST4000DM000-1F21 CC52  /dev/sdd 
[6:0:0:0]    disk    ATA      OCZ-VERTEX3      2.25  /dev/sde 
[8:0:0:0]    disk    ATA      ST4000DM000-1F21 CC52  /dev/sdf 
[9:0:0:0]    disk    ATA      WDC WD20EARX-00P AB51  /dev/sdg 
[10:0:0:0]   disk    ATA      ST2000DL003-9VT1 CC3C  /dev/sdh 
[11:0:0:0]   disk    ATA      WDC WD20EARX-00P AB51  /dev/sdi 
 

 

 

The first column is the scsi ID.  If I wanted to assign the /dev/sdi device (a western digital device), I would need to note the 11:0:0:0 designation.  Next, I need to edit the XML for my VM.  Goto the VMs tab, click on the icon for the VM we're dealing with, and then select Edit XML.

 

NOTE:  Once you do this, you will not be able to use the GUI editor to make changes to your VM without losing these edits, so before proceeding, use the GUI editor to get your memory, CPU pinning, and any other device assignments all set.

 

In the XML, add the following code:

 

 

 

Adjust the large bolded numbers for the four numbers in the scsi id.  For most, this will only be the first number in the <adapter> section.

 

If you are installing Windows directly to this device, you will need to load the vioscsi driver during the installation process for the installer to detect the device.  Follow the same procedure as is documented in the wiki for setting up a normal Windows VM, but instead of selecting viostor, browse to the vioscsi folder.

 

Let me know if any of this is unclear or if this doesn't work for you.

 

Hi John,

 

I know this is an old post but it is exactly what i am trying to achieve a pass through of an SSD for my gaming VM.

 

I followed  you instructions and the VM booted with 2 SCSI Controllers with no driver loaded.  One of them loaded fine using the virtio CD but the other one wont accept any driver.  The result I have is I can actually see the SSD in my Windows VM and also view the contents of the drive but it is write protected.  I have followed the steps to remove write protection through windows using diskpart but although the program tells me write protection successfully removed It basically lies! ? I still cannot write to the disk.  Below is my XML in case you think I have made an error? the Disk ID is 12

 

Many Thanks!

 

PCI Devices and IOMMU Groups


 
IOMMU group 0: [8086:3ec2] 00:00.0 Host bridge: Intel Corporation Device 3ec2 (rev 07)
 
IOMMU group 1: [8086:1901] 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor PCIe Controller (x16) (rev 07)
  [10de:1c03] 01:00.0 VGA compatible controller: NVIDIA Corporation GP106 [GeForce GTX 1060 6GB] (rev a1)
  [10de:10f1] 01:00.1 Audio device: NVIDIA Corporation GP106 High Definition Audio Controller (rev a1)
 
IOMMU group 2: [8086:3e92] 00:02.0 VGA compatible controller: Intel Corporation Device 3e92
 
IOMMU group 3: [8086:a2af] 00:14.0 USB controller: Intel Corporation 200 Series PCH USB 3.0 xHCI Controller
 
IOMMU group 4: [8086:a2ba] 00:16.0 Communication controller: Intel Corporation 200 Series PCH CSME HECI #1
 
IOMMU group 5: [8086:a282] 00:17.0 SATA controller: Intel Corporation 200 Series PCH SATA controller [AHCI mode]
 
IOMMU group 6: [8086:a2e7] 00:1b.0 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port #17 (rev f0)
 
IOMMU group 7: [8086:a2eb] 00:1b.4 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port #21 (rev f0)
 
IOMMU group 8: [8086:a290] 00:1c.0 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port #1 (rev f0)
 
IOMMU group 9: [8086:a294] 00:1c.4 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port #5 (rev f0)
 
IOMMU group 10: [8086:a297] 00:1c.7 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port #8 (rev f0)
 
IOMMU group 11: [8086:a298] 00:1d.0 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port #9 (rev f0)
 
IOMMU group 12: [8086:a2c9] 00:1f.0 ISA bridge: Intel Corporation Device a2c9
  [8086:a2a1] 00:1f.2 Memory controller: Intel Corporation 200 Series PCH PMC
  [8086:a2f0] 00:1f.3 Audio device: Intel Corporation 200 Series PCH HD Audio
  [8086:a2a3] 00:1f.4 SMBus: Intel Corporation 200 Series PCH SMBus Controller
 
IOMMU group 13: [8086:15b8] 00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2) I219-V
 
IOMMU group 14: [1000:0072] 03:00.0 Serial Attached SCSI controller: LSI Logic / Symbios Logic SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] (rev 03)
 
IOMMU group 15: [1ade:3038] 04:00.0 Multimedia video controller: Spin Master Ltd. PCIe Video Bridge (rev 01)
 
IOMMU group 16: [1b21:2142] 05:00.0 USB controller: ASMedia Technology Inc. Device 2142
 
IOMMU group 17: [1b4b:9215] 06:00.0 SATA controller: Marvell Technology Group Ltd. Device 9215 (rev 11)
 
IOMMU group 18: [144d:a804] 07:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM961/PM961

 

CPU Thread Pairings


 
Pair 1: cpu 0 / cpu 6
Pair 2: cpu 1 / cpu 7
Pair 3: cpu 2 / cpu 8
Pair 4: cpu 3 / cpu 9
Pair 5: cpu 4 / cpu 10
Pair 6: cpu 5 / cpu 11

 

USB Devices


 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 062a:5918 MosArt Semiconductor Corp.
Bus 001 Device 003: ID 046d:c31b Logitech, Inc. Compact Keyboard K300
Bus 001 Device 005: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 001 Device 006: ID 154b:004f PNY
Bus 001 Device 007: ID 1e71:170e NZXT
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 002: ID 357d:7788 Sharkoon QuickPort XT
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

 

SCSI Devices


 
[0:0:0:0] disk SAMSUNG HD103SI 0100 /dev/sda 1.00TB
[1:0:0:0] disk PNY Tech USB 2.0 FD 1100 /dev/sdb 4.05GB
[2:0:0:0] disk ATA ST3000DM008-2DM1 CC26 /dev/sdc 3.00TB
[2:0:1:0] disk ATA ST3000DM008-2DM1 CC26 /dev/sdd 3.00TB
[2:0:2:0] disk ATA SAMSUNG HD204UI 0001 /dev/sde 2.00TB
[2:0:3:0] disk ATA TOSHIBA HDWD130 ACF0 /dev/sdf 3.00TB
[2:0:4:0] disk ATA TOSHIBA HDWD130 ACF0 /dev/sdg 3.00TB
[2:0:5:0] disk ATA TOSHIBA HDWD130 ACF0 /dev/sdh 3.00TB
[2:0:6:0] disk ATA WDC WD30EFRX-68E 0A82 /dev/sdi 3.00TB
[3:0:0:0] disk ATA KINGSTON SV300S3 BBF0 /dev/sdj 480GB
[4:0:0:0] disk ATA ST2000DL004 HD20 0001 /dev/sdk 2.00TB
[5:0:0:0] disk ATA SAMSUNG SSD 830 3B1Q /dev/sdl 256GB
[6:0:0:0] disk ATA ST2000DL001-9VT1 CC43 /dev/sdm 2.00TB
[8:0:0:0] disk ATA TOSHIBA HDWD130 ACF0 /dev/sdn 3.00TB
[9:0:0:0] disk ATA TOSHIBA HDWD130 ACF0 /dev/sdo 3.00TB
[10:0:0:0] disk ATA TOSHIBA HDWD130 ACF0 /dev/sdp 3.00TB
[11:0:0:0] disk ATA TOSHIBA HDWD130 ACF0 /dev/sdq 3.00TB
[12:0:0:0] disk ATA CT480BX300SSD1 010 /dev/sdr 480GB

 

<domain type='kvm' id='2'>
  <name>Windows 10</name>
  <uuid>beac90af-1947-1387-95ca-9fe34f8b6d24</uuid>
  <description>I7HEX</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/>
  </memoryBacking>
  <vcpu placement='static'>6</vcpu>
  <cputune>
    <vcpupin vcpu='0' cpuset='3'/>
    <vcpupin vcpu='1' cpuset='9'/>
    <vcpupin vcpu='2' cpuset='4'/>
    <vcpupin vcpu='3' cpuset='10'/>
    <vcpupin vcpu='4' cpuset='5'/>
    <vcpupin vcpu='5' cpuset='11'/>
  </cputune>
  <resource>
    <partition>/machine</partition>
  </resource>
  <os>
    <type arch='x86_64' machine='pc-i440fx-2.10'>hvm</type>
    <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd</loader>
    <nvram>/etc/libvirt/qemu/nvram/beac90af-1947-1387-95ca-9fe34f8b6d24_VARS-pure-efi.fd</nvram>
  </os>
  <features>
    <acpi/>
    <apic/>
  </features>
  <cpu mode='host-passthrough' check='none'>
    <topology sockets='1' cores='3' 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/Samsung_SSD_960_EVO_250GB_S3ESNX0JB85431Y/VM/Windows 10/vdisk1.img'/>
      <backingStore/>
      <target dev='hdc' bus='virtio'/>
      <boot order='1'/>
      <alias name='virtio-disk2'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </disk>
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/mnt/user/isos/Windows(FromMS).iso'/>
      <backingStore/>
      <target dev='hda' bus='sata'/>
      <readonly/>
      <boot order='2'/>
      <alias name='sata0-0-0'/>
      <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/user/isos/virtio-win-0.1.126-1.iso'/>
      <backingStore/>
      <target dev='hdb' bus='sata'/>
      <readonly/>
      <alias name='sata0-0-1'/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>
    <controller type='usb' index='0' model='ich9-ehci1'>
      <alias name='usb'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x7'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci1'>
      <alias name='usb'/>
      <master startport='0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0' multifunction='on'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci2'>
      <alias name='usb'/>
      <master startport='2'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x1'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci3'>
      <alias name='usb'/>
      <master startport='4'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x2'/>
    </controller>
    <controller type='pci' index='0' model='pci-root'>
      <alias name='pci.0'/>
    </controller>
    <controller type='sata' index='0'>
      <alias name='sata0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </controller>
    <controller type='virtio-serial' index='0'>
      <alias name='virtio-serial0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </controller>
    <controller type='scsi' index='0'>
      <alias name='scsi0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x0b' function='0x0'/>
    </controller>
    <controller type='scsi' index='1' model='virtio-scsi'>
      <alias name='scsi1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/>
    </controller>
    <interface type='bridge'>
      <mac address='52:54:00:5e:ff:85'/>
      <source bridge='br0'/>
      <target dev='vnet0'/>
      <model type='virtio'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </interface>
    <serial type='pty'>
      <source path='/dev/pts/0'/>
      <target port='0'/>
      <alias name='serial0'/>
    </serial>
    <console type='pty' tty='/dev/pts/0'>
      <source path='/dev/pts/0'/>
      <target type='serial' port='0'/>
      <alias name='serial0'/>
    </console>
    <channel type='unix'>
      <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/domain-2-Windows 10/org.qemu.guest_agent.0'/>
      <target type='virtio' name='org.qemu.guest_agent.0' state='disconnected'/>
      <alias name='channel0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    </channel>
    <input type='mouse' bus='ps2'>
      <alias name='input0'/>
    </input>
    <input type='keyboard' bus='ps2'>
      <alias name='input1'/>
    </input>
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <driver name='vfio'/>
      <source>
        <address domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
      </source>
      <alias name='hostdev0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </hostdev>
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <driver name='vfio'/>
      <source>
        <address domain='0x0000' bus='0x01' slot='0x00' function='0x1'/>
      </source>
      <alias name='hostdev1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
    </hostdev>
    <hostdev mode='subsystem' type='scsi' managed='no' rawio='yes'>
      <source>
        <adapter name='scsi_host12'/>
        <address bus='0' target='0' unit='0'/>
      </source>
      <readonly/>
      <alias name='hostdev2'/>
      <address type='drive' controller='1' bus='0' target='0' unit='0'/>
    </hostdev>
    <hostdev mode='subsystem' type='usb' managed='no'>
      <source>
        <vendor id='0x046d'/>
        <product id='0xc52b'/>
        <address bus='1' device='5'/>
      </source>
      <alias name='hostdev3'/>
      <address type='usb' bus='0' port='1'/>
    </hostdev>
    <hostdev mode='subsystem' type='usb' managed='no'>
      <source>
        <vendor id='0x062a'/>
        <product id='0x5918'/>
        <address bus='1' device='2'/>
      </source>
      <alias name='hostdev4'/>
      <address type='usb' bus='0' port='2'/>
    </hostdev>
    <hostdev mode='subsystem' type='usb' managed='no'>
      <source>
        <vendor id='0x1e71'/>
        <product id='0x170e'/>
        <address bus='1' device='4'/>
      </source>
      <alias name='hostdev5'/>
      <address type='usb' bus='0' port='3'/>
    </hostdev>
    <memballoon model='virtio'>
      <alias name='balloon0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
    </memballoon>
  </devices>
  <seclabel type='dynamic' model='dac' relabel='yes'>
    <label>+0:+100</label>
    <imagelabel>+0:+100</imagelabel>
  </seclabel>
</domain>

 

 

Link to comment
  • 5 years later...
On 8/28/2015 at 3:08 PM, jonp said:

 

1 - Remove all the custom xml stuff I had you add originally.

2 - Add a new <disk> section that looks like this:

 

 

Quote
    <disk type='block' device='disk'>

      <driver name='qemu' type='raw' cache='writeback'/>

      <source dev='/dev/disk/by-id/YOUR DISK ID HERE'/>

      <target dev='hda' bus='virtio'/>

    </disk>

 

To find what to put in the highlighted portion, you will need to login to your server from command line.  Then type the following command:

 

 

ls /dev/disk/by-id
 

 

 

Find the one that represents your storage device (but without the -part1 at the end) and paste that in the section above that says YOUR DISK ID HERE.  This should work regardless of what SCSI IDs change to after reboots.

 

This is still relevant in 2024. Thanks!

Link to comment
  • 4 weeks later...
On 8/28/2015 at 8:08 PM, jonp said:

 

Ok, if you'd like to be a guinea pig, here's another method for passing through a block device that does not utilize the virtio-scsi controller.  Changing your existing VM to this may possibly not work (you may have to reinstall windows or try a few things to get it to boot again).

 

1 - Remove all the custom xml stuff I had you add originally.

2 - Add a new <disk> section that looks like this:

 

 

 

To find what to put in the highlighted portion, you will need to login to your server from command line.  Then type the following command:

 

 

ls /dev/disk/by-id
 

 

 

Find the one that represents your storage device (but without the -part1 at the end) and paste that in the section above that says YOUR DISK ID HERE.  This should work regardless of what SCSI IDs change to after reboots.

 

This is the best and simplest way to do it.
I was running arround in multiple treads until I found this. Thx mate.

 

On an end note: I'm not using this particular drive to boot my OS from, it's a secondary drive for an already existing VM. So I can't say if it's bootable or not, but it is usable inside the VM at least.

Edited by drydenmike
adding relevant information
Link to comment

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.