unRAID Server Release 6.0-beta15-x86_64 Available


Recommended Posts

sparklyballs, you can also try NOT passing through the sound device from the video card to see if that works.  I remember having luck with one of the AMD video cards I have when I didn't pass though its HDMI audio.

 

LOL, when my 4 yr old niece is kicking the crap out of my shins because there's no sound on her barbie movies I am going to curse your name.

Haha, don't want you to get bruised shins.  Does your motherboard have analog audio outputs? If so, use that device for the sound portion.  That's actually how Jon rolls.

 

lol Eric, didn't know you were on forum duty tonight ;-), great minds think alike ;-)

Link to comment
  • Replies 506
  • Created
  • Last Reply

Top Posters In This Topic

sparklyballs, you can also try NOT passing through the sound device from the video card to see if that works.  I remember having luck with one of the AMD video cards I have when I didn't pass though its HDMI audio.

 

LOL, when my 4 yr old niece is kicking the crap out of my shins because there's no sound on her barbie movies I am going to curse your name.

Haha, don't want you to get bruised shins.  Does your motherboard have analog audio outputs? If so, use that device for the sound portion.  That's actually how Jon rolls.

 

lol Eric, didn't know you were on forum duty tonight ;-), great minds think alike ;-)

I like to surprise everyone by doing a drive-by posting every now and then

Link to comment

I still am experiencing spin down issues with this beta. Any ideas to figure out what keeps making those discs spin up? Seems to be something in the Unraid environment itself since if I isolate it from the network I still get this problem, frustrating...especially with summer coming. Also no spin down issues pre-beta 13 as far as I remember.

Disabling your plugins / dockers / vm's will help to narrow it down and then bring them up one at a time

 

Sure I could do that. Probably will have to end up doing that, but don't really want to cuz its a pain and it only indirectly tells me what could be the problem. I guess I was looking for something more like htop for disk access.

 

EDIT: Just disabled everything and the issue still remains..

Link to comment

Just updated to b15 today.  I seem to be having a problem with moving files from my cache drive now.  Wonder if they are actually being moved or not?

 

Apr 19 22:39:42 Tower emhttp: read_line: client closed the connection
Apr 19 22:39:49 Tower emhttp: /usr/bin/tail -n 42 -f /var/log/syslog 2>&1
Apr 19 22:40:38 Tower emhttp: /usr/bin/tail -n 42 -f /var/log/syslog 2>&1
Apr 19 22:40:45 Tower emhttp: read_line: client closed the connection
Apr 19 22:40:54 Tower emhttp: read_line: client closed the connection
Apr 19 22:41:07 Tower logger: ./Game ISO's/Xbox 360/Mortal Kombat vs. DC Universe.mds
Apr 19 22:41:07 Tower logger: .d..t...... Game ISO's/Xbox 360/
Apr 19 22:41:07 Tower logger: >f+++++++++ Game ISO's/Xbox 360/Mortal Kombat vs. DC Universe.mds
Apr 19 22:41:07 Tower logger: ./Game ISO's/Xbox 360/Mortal Kombat vs. DC Universe.iso
Apr 19 22:41:07 Tower logger: >f+++++++++ Game ISO's/Xbox 360/Mortal Kombat vs. DC Universe.iso
Apr 19 22:41:31 Tower emhttp: read_line: client closed the connection
Apr 19 22:41:32 Tower emhttp: read_line: client closed the connection
Apr 19 22:41:34 Tower emhttp: read_line: client closed the connection
Apr 19 22:41:44 Tower emhttp: read_line: client closed the connection
Apr 19 22:41:49 Tower emhttp: /usr/bin/tail -n 42 -f /var/log/syslog 2>&1
Apr 19 22:41:52 Tower emhttp: read_line: client closed the connection
Apr 19 22:41:59 Tower emhttp: read_line: client closed the connection
Apr 19 22:42:06 Tower emhttp: read_line: client closed the connection
Apr 19 22:42:09 Tower emhttp: read_line: client closed the connection
Apr 19 22:42:39 Tower emhttp: read_line: client closed the connection
Apr 19 22:42:48 Tower emhttp: read_line: client closed the connection
Apr 19 22:43:05 Tower emhttp: read_line: client closed the connection
Apr 19 22:43:19 Tower emhttp: /usr/bin/tail -n 42 -f /var/log/syslog 2>&1
Apr 19 22:43:40 Tower logger: ./Game ISO's/Xbox 360/FlatOut Ultimate Carnage.mds
Apr 19 22:43:40 Tower logger: .d..t...... Game ISO's/Xbox 360/
Apr 19 22:43:40 Tower logger: >f+++++++++ Game ISO's/Xbox 360/FlatOut Ultimate Carnage.mds
Apr 19 22:43:40 Tower logger: ./Game ISO's/Xbox 360/FlatOut Ultimate Carnage.iso
Apr 19 22:43:40 Tower logger: >f+++++++++ Game ISO's/Xbox 360/FlatOut Ultimate Carnage.iso
Apr 19 22:43:42 Tower emhttp: read_line: client closed the connection
Apr 19 22:43:44 Tower emhttp: read_line: client closed the connection
Apr 19 22:44:22 Tower emhttp: read_line: client closed the connection
Apr 19 22:44:40 Tower emhttp: read_line: client closed the connection
Apr 19 22:44:51 Tower emhttp: read_line: client closed the connection
Apr 19 22:44:57 Tower emhttp: read_line: client closed the connection
Apr 19 22:45:05 Tower emhttp: /usr/bin/tail -n 42 -f /var/log/syslog 2>&1
Apr 19 22:46:08 Tower emhttp: read_line: client closed the connection
Apr 19 22:46:12 Tower logger: ./Game ISO's/Xbox 360/MX vs. ATV Untamed.mds
Apr 19 22:46:12 Tower logger: .d..t...... Game ISO's/Xbox 360/
Apr 19 22:46:12 Tower logger: >f+++++++++ Game ISO's/Xbox 360/MX vs. ATV Untamed.mds
Apr 19 22:46:12 Tower logger: ./Game ISO's/Xbox 360/MX vs. ATV Untamed.iso
Apr 19 22:46:12 Tower logger: >f+++++++++ Game ISO's/Xbox 360/MX vs. ATV Untamed.iso
Apr 19 22:46:56 Tower emhttp: /usr/bin/tail -n 42 -f /var/log/syslog 2>&1
Apr 19 22:46:56 Tower emhttp: read_line: client closed the connection

Link to comment

Just updated to b15 today.  I seem to be having a problem with moving files from my cache drive now.  Wonder if they are actually being moved or not?

 

Apr 19 22:39:42 Tower emhttp: read_line: client closed the connection
Apr 19 22:39:49 Tower emhttp: /usr/bin/tail -n 42 -f /var/log/syslog 2>&1
Apr 19 22:40:38 Tower emhttp: /usr/bin/tail -n 42 -f /var/log/syslog 2>&1
Apr 19 22:40:45 Tower emhttp: read_line: client closed the connection
Apr 19 22:40:54 Tower emhttp: read_line: client closed the connection
Apr 19 22:41:07 Tower logger: ./Game ISO's/Xbox 360/Mortal Kombat vs. DC Universe.mds
Apr 19 22:41:07 Tower logger: .d..t...... Game ISO's/Xbox 360/
Apr 19 22:41:07 Tower logger: >f+++++++++ Game ISO's/Xbox 360/Mortal Kombat vs. DC Universe.mds
Apr 19 22:41:07 Tower logger: ./Game ISO's/Xbox 360/Mortal Kombat vs. DC Universe.iso
Apr 19 22:41:07 Tower logger: >f+++++++++ Game ISO's/Xbox 360/Mortal Kombat vs. DC Universe.iso
Apr 19 22:41:31 Tower emhttp: read_line: client closed the connection
Apr 19 22:41:32 Tower emhttp: read_line: client closed the connection
Apr 19 22:41:34 Tower emhttp: read_line: client closed the connection
Apr 19 22:41:44 Tower emhttp: read_line: client closed the connection
Apr 19 22:41:49 Tower emhttp: /usr/bin/tail -n 42 -f /var/log/syslog 2>&1
Apr 19 22:41:52 Tower emhttp: read_line: client closed the connection
Apr 19 22:41:59 Tower emhttp: read_line: client closed the connection
Apr 19 22:42:06 Tower emhttp: read_line: client closed the connection
Apr 19 22:42:09 Tower emhttp: read_line: client closed the connection
Apr 19 22:42:39 Tower emhttp: read_line: client closed the connection
Apr 19 22:42:48 Tower emhttp: read_line: client closed the connection
Apr 19 22:43:05 Tower emhttp: read_line: client closed the connection
Apr 19 22:43:19 Tower emhttp: /usr/bin/tail -n 42 -f /var/log/syslog 2>&1
Apr 19 22:43:40 Tower logger: ./Game ISO's/Xbox 360/FlatOut Ultimate Carnage.mds
Apr 19 22:43:40 Tower logger: .d..t...... Game ISO's/Xbox 360/
Apr 19 22:43:40 Tower logger: >f+++++++++ Game ISO's/Xbox 360/FlatOut Ultimate Carnage.mds
Apr 19 22:43:40 Tower logger: ./Game ISO's/Xbox 360/FlatOut Ultimate Carnage.iso
Apr 19 22:43:40 Tower logger: >f+++++++++ Game ISO's/Xbox 360/FlatOut Ultimate Carnage.iso
Apr 19 22:43:42 Tower emhttp: read_line: client closed the connection
Apr 19 22:43:44 Tower emhttp: read_line: client closed the connection
Apr 19 22:44:22 Tower emhttp: read_line: client closed the connection
Apr 19 22:44:40 Tower emhttp: read_line: client closed the connection
Apr 19 22:44:51 Tower emhttp: read_line: client closed the connection
Apr 19 22:44:57 Tower emhttp: read_line: client closed the connection
Apr 19 22:45:05 Tower emhttp: /usr/bin/tail -n 42 -f /var/log/syslog 2>&1
Apr 19 22:46:08 Tower emhttp: read_line: client closed the connection
Apr 19 22:46:12 Tower logger: ./Game ISO's/Xbox 360/MX vs. ATV Untamed.mds
Apr 19 22:46:12 Tower logger: .d..t...... Game ISO's/Xbox 360/
Apr 19 22:46:12 Tower logger: >f+++++++++ Game ISO's/Xbox 360/MX vs. ATV Untamed.mds
Apr 19 22:46:12 Tower logger: ./Game ISO's/Xbox 360/MX vs. ATV Untamed.iso
Apr 19 22:46:12 Tower logger: >f+++++++++ Game ISO's/Xbox 360/MX vs. ATV Untamed.iso
Apr 19 22:46:56 Tower emhttp: /usr/bin/tail -n 42 -f /var/log/syslog 2>&1
Apr 19 22:46:56 Tower emhttp: read_line: client closed the connection

There is nothing in that log snippet that indicates an issue with the files being moved off the cache.  The error messages relate to the GUI although I do not know why they should be occurring.

 

You can always check if files are being moved from the cache by going directly to the cache share to see if they are still there or not.

Link to comment

Ok, a few things you can try here.  First, let's try using the pciback hide mechanism to bind the devices you want to use with passthrough prior to the OS itself booting.  This will involve a little command line work and a modification to your syslinux.cfg file under /boot/config/syslinux/.

 

First, go to the command line and type this:

 

lspci -n

 

Should print out a list something like this:

 

00:00.0 0600: 8086:0c00 (rev 06)
00:01.0 0604: 8086:0c01 (rev 06)
00:01.1 0604: 8086:0c05 (rev 06)
00:02.0 0300: 8086:0412 (rev 06)
00:03.0 0403: 8086:0c0c (rev 06)
00:14.0 0c03: 8086:8c31 (rev 04)
00:16.0 0780: 8086:8c3a (rev 04)
00:19.0 0200: 8086:153b (rev 04)
00:1b.0 0403: 8086:8c20 (rev 04)
00:1c.0 0604: 8086:8c10 (rev d4)
00:1c.3 0604: 8086:8c16 (rev d4)
00:1f.0 0601: 8086:8c44 (rev 04)
00:1f.2 0106: 8086:8c02 (rev 04)
00:1f.3 0c05: 8086:8c22 (rev 04)
01:00.0 0300: 1002:68f9
01:00.1 0403: 1002:aa68
02:00.0 0300: 10de:1004 (rev a1)
02:00.1 0403: 10de:0e1a (rev a1)
04:00.0 0400: 1a0a:6202 (rev 01)

 

Locate your PCI devices by their ID (the first column of numbers in this format:  ##:##:#.  Your GPU device id is listed in the VM manager edit page when you select the GPU.  Once you've found it and it's audio counterpart (the ##:##.1), note the vendor/product ids for each and put them in your syslinux config file.  For example, in mine, I have this:

 

label unRAID OS
  kernel /bzimage
  append pci-stub.ids=1002:68f9,1002:aa68,10de:1004,10de:0e1a initrd=/bzroot

 

After applying that, reboot your server and give it another whirl.  Also, remove any VFIO bind scripts you use.  We take care of all that automatically for you.

 

Also, some vendors may have updates to the BIOS firmware for their cards.  Check to see if there is one for yours.  If the card supports UEFI, it really should work, but in some scenarios, we've had challenges.

 

Other things you can try:

 

1)  Adjust to Q35 or i440fx chipset.

2)  Load your ROM BIOS for the GPU manually.

 

To do the latter, you will first need to find your BIOS from this site:  http://www.techpowerup.com/vgabios/

 

Download the bin for your BIOS and save it to somewhere on your cache or in the array.

 

Edit the XML for your VM through the webGui.  Locate the section for your GPU pass through which will look like this:

 

    <hostdev mode='subsystem' type='pci' managed='yes'>
      <driver name='vfio'/>
      <source>
        <address domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
      </source>
    </hostdev>

 

Add the following after the </source> but before the </hostdev>:

 

<rom bar='on' file='/mnt/path/to/rom.bin'/>

 

Replace the file path to the path of your bin file.

 

I've had much easier success with NVIDIA devices that have UEFI BIOS than AMD.  I actually don't have any AMD cards that have UEFI capability.  Even a modern R9-290 I got from ASUS about a year ago doesn't have UEFI support.  With NVIDIA, most devices as of the 650 series and up seem to have it, and I've had particularly good luck with EVGA.

 

Give these things a go and let me know how it goes.  There are a few other things we can try as well.  I'd be inclined to have you try that GPU without the OVMF setting (bet it would work), but let's keep trying OVMF first, as it is definitely going to be the preferred method.

 

 

story so far.

 

took out vfio-bind from go...

 

added the pci stubs to syslinux.cfg  ----- still had blank screen

 

found bios for card and place the line in the xml, ----- output to vnc and able to install, nothing outputting via hdmi yet.

 

NOTE: with the rom bios in the xml the installer for ubuntu 14.04 server goes straight to the grub screen and i can press install and it works, no need for the shell commands . fs0: and so on.

 

the bios was a .rom not .bin , is that important ?

Link to comment

Has anyone tried running a preclear on b15 yet?

I tried earlier today and it ran e-x-t-r-e-m-e-l-y  s-l-o-w-l-y.  I ended up booting an earlier v6beta on another machine and am running the preclear on that.

 

I will try preclearing on b15 again later.

 

Edit:

Okay, I had been playing with the new VM Manager and had a VM in a strange state where the boot wouldn't complete.  Having killed that VM, the preclear appears to run at a respectable speed.

 

Which would be the most appropriate area on the forum to seek advice on creating an ArchLinux VM using the VM Manager?

Link to comment

Has anyone tried running a preclear on b15 yet?

I tried earlier today and it ran e-x-t-r-e-m-e-l-y  s-l-o-w-l-y.  I ended up booting an earlier v6beta on another machine and am running the preclear on that.

 

I will try preclearing on b15 again later.

 

Edit:

Okay, I had been playing with the new VM Manager and had a VM in a strange state where the boot wouldn't complete.  Having killed that VM, the preclear appears to run at a respectable speed.

 

Which would be the most appropriate area on the forum to seek advice on creating an ArchLinux VM using the VM Manager?

The kvm forum probably is your best bet. I hang around there a bit too and will help where I can.

Link to comment

 

 

Ok, a few things you can try here.  First, let's try using the pciback hide mechanism to bind the devices you want to use with passthrough prior to the OS itself booting.  This will involve a little command line work and a modification to your syslinux.cfg file under /boot/config/syslinux/.

 

First, go to the command line and type this:

 

lspci -n

 

Should print out a list something like this:

 

00:00.0 0600: 8086:0c00 (rev 06)
00:01.0 0604: 8086:0c01 (rev 06)
00:01.1 0604: 8086:0c05 (rev 06)
00:02.0 0300: 8086:0412 (rev 06)
00:03.0 0403: 8086:0c0c (rev 06)
00:14.0 0c03: 8086:8c31 (rev 04)
00:16.0 0780: 8086:8c3a (rev 04)
00:19.0 0200: 8086:153b (rev 04)
00:1b.0 0403: 8086:8c20 (rev 04)
00:1c.0 0604: 8086:8c10 (rev d4)
00:1c.3 0604: 8086:8c16 (rev d4)
00:1f.0 0601: 8086:8c44 (rev 04)
00:1f.2 0106: 8086:8c02 (rev 04)
00:1f.3 0c05: 8086:8c22 (rev 04)
01:00.0 0300: 1002:68f9
01:00.1 0403: 1002:aa68
02:00.0 0300: 10de:1004 (rev a1)
02:00.1 0403: 10de:0e1a (rev a1)
04:00.0 0400: 1a0a:6202 (rev 01)

 

Locate your PCI devices by their ID (the first column of numbers in this format:  ##:##:#.  Your GPU device id is listed in the VM manager edit page when you select the GPU.  Once you've found it and it's audio counterpart (the ##:##.1), note the vendor/product ids for each and put them in your syslinux config file.  For example, in mine, I have this:

 

label unRAID OS
  kernel /bzimage
  append pci-stub.ids=1002:68f9,1002:aa68,10de:1004,10de:0e1a initrd=/bzroot

 

After applying that, reboot your server and give it another whirl.  Also, remove any VFIO bind scripts you use.  We take care of all that automatically for you.

 

Also, some vendors may have updates to the BIOS firmware for their cards.  Check to see if there is one for yours.  If the card supports UEFI, it really should work, but in some scenarios, we've had challenges.

 

Other things you can try:

 

1)  Adjust to Q35 or i440fx chipset.

2)  Load your ROM BIOS for the GPU manually.

 

To do the latter, you will first need to find your BIOS from this site:  http://www.techpowerup.com/vgabios/

 

Download the bin for your BIOS and save it to somewhere on your cache or in the array.

 

Edit the XML for your VM through the webGui.  Locate the section for your GPU pass through which will look like this:

 

    <hostdev mode='subsystem' type='pci' managed='yes'>
      <driver name='vfio'/>
      <source>
        <address domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
      </source>
    </hostdev>

 

Add the following after the </source> but before the </hostdev>:

 

<rom bar='on' file='/mnt/path/to/rom.bin'/>

 

Replace the file path to the path of your bin file.

 

I've had much easier success with NVIDIA devices that have UEFI BIOS than AMD.  I actually don't have any AMD cards that have UEFI capability.  Even a modern R9-290 I got from ASUS about a year ago doesn't have UEFI support.  With NVIDIA, most devices as of the 650 series and up seem to have it, and I've had particularly good luck with EVGA.

 

Give these things a go and let me know how it goes.  There are a few other things we can try as well.  I'd be inclined to have you try that GPU without the OVMF setting (bet it would work), but let's keep trying OVMF first, as it is definitely going to be the preferred method.

 

 

story so far.

 

took out vfio-bind from go...

 

added the pci stubs to syslinux.cfg  ----- still had blank screen

 

found bios for card and place the line in the xml, ----- output to vnc and able to install, nothing outputting via hdmi yet.

 

NOTE: with the rom bios in the xml the installer for ubuntu 14.04 server goes straight to the grub screen and i can press install and it works, no need for the shell commands . fs0: and so on.

 

the bios was a .rom not .bin , is that important ?

 

Ok, ROM file is fine.

Link to comment

 

 

Ok, a few things you can try here.  First, let's try using the pciback hide mechanism to bind the devices you want to use with passthrough prior to the OS itself booting.  This will involve a little command line work and a modification to your syslinux.cfg file under /boot/config/syslinux/.

 

First, go to the command line and type this:

 

lspci -n

 

Should print out a list something like this:

 

00:00.0 0600: 8086:0c00 (rev 06)
00:01.0 0604: 8086:0c01 (rev 06)
00:01.1 0604: 8086:0c05 (rev 06)
00:02.0 0300: 8086:0412 (rev 06)
00:03.0 0403: 8086:0c0c (rev 06)
00:14.0 0c03: 8086:8c31 (rev 04)
00:16.0 0780: 8086:8c3a (rev 04)
00:19.0 0200: 8086:153b (rev 04)
00:1b.0 0403: 8086:8c20 (rev 04)
00:1c.0 0604: 8086:8c10 (rev d4)
00:1c.3 0604: 8086:8c16 (rev d4)
00:1f.0 0601: 8086:8c44 (rev 04)
00:1f.2 0106: 8086:8c02 (rev 04)
00:1f.3 0c05: 8086:8c22 (rev 04)
01:00.0 0300: 1002:68f9
01:00.1 0403: 1002:aa68
02:00.0 0300: 10de:1004 (rev a1)
02:00.1 0403: 10de:0e1a (rev a1)
04:00.0 0400: 1a0a:6202 (rev 01)

 

Locate your PCI devices by their ID (the first column of numbers in this format:  ##:##:#.  Your GPU device id is listed in the VM manager edit page when you select the GPU.  Once you've found it and it's audio counterpart (the ##:##.1), note the vendor/product ids for each and put them in your syslinux config file.  For example, in mine, I have this:

 

label unRAID OS
  kernel /bzimage
  append pci-stub.ids=1002:68f9,1002:aa68,10de:1004,10de:0e1a initrd=/bzroot

 

After applying that, reboot your server and give it another whirl.  Also, remove any VFIO bind scripts you use.  We take care of all that automatically for you.

 

Also, some vendors may have updates to the BIOS firmware for their cards.  Check to see if there is one for yours.  If the card supports UEFI, it really should work, but in some scenarios, we've had challenges.

 

Other things you can try:

 

1)  Adjust to Q35 or i440fx chipset.

2)  Load your ROM BIOS for the GPU manually.

 

To do the latter, you will first need to find your BIOS from this site:  http://www.techpowerup.com/vgabios/

 

Download the bin for your BIOS and save it to somewhere on your cache or in the array.

 

Edit the XML for your VM through the webGui.  Locate the section for your GPU pass through which will look like this:

 

    <hostdev mode='subsystem' type='pci' managed='yes'>
      <driver name='vfio'/>
      <source>
        <address domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
      </source>
    </hostdev>

 

Add the following after the </source> but before the </hostdev>:

 

<rom bar='on' file='/mnt/path/to/rom.bin'/>

 

Replace the file path to the path of your bin file.

 

I've had much easier success with NVIDIA devices that have UEFI BIOS than AMD.  I actually don't have any AMD cards that have UEFI capability.  Even a modern R9-290 I got from ASUS about a year ago doesn't have UEFI support.  With NVIDIA, most devices as of the 650 series and up seem to have it, and I've had particularly good luck with EVGA.

 

Give these things a go and let me know how it goes.  There are a few other things we can try as well.  I'd be inclined to have you try that GPU without the OVMF setting (bet it would work), but let's keep trying OVMF first, as it is definitely going to be the preferred method.

 

 

story so far.

 

took out vfio-bind from go...

 

added the pci stubs to syslinux.cfg  ----- still had blank screen

 

found bios for card and place the line in the xml, ----- output to vnc and able to install, nothing outputting via hdmi yet.

 

NOTE: with the rom bios in the xml the installer for ubuntu 14.04 server goes straight to the grub screen and i can press install and it works, no need for the shell commands . fs0: and so on.

 

the bios was a .rom not .bin , is that important ?

 

Ok, ROM file is fine.

 

i've been making and killing VM's a few times today, and on a side note, i can't remember the damn sequence of things but i managed to get a 12.04 desktop ubuntu installer up and running.

 

one thing i do remember is putting nomodeset in edit from grub menu. also there is a message about secureboot not enabled.

 

when the efi shell appears, typing exit and looking in the bios, can't enable secureboot.

Link to comment

More Updates - 4 Total: (mostly nitpicking)

 

1. unRAID still does not email me the completed parity check notice. It shows up under archived notifications but I never get an email.

 

2. The VM VNC screen has gotten smaller with beta 15. It was nicer when the VNC  screen was larger.

 

3. If you view unRAID's "main" GUI tab on an iPhone/iPad with the Google Chrome Browser App, the Devices look like it they freaking out. I am guessing it has to do with the auto screen update.

 

4. I received this notification last night (not sure what it is indicating):

SUBJECT: Version update plugin: xml parse error

BODY:

Event: Plugin - unRAIDServer [plugin: xml parse error]

Subject: Notice [PITHOS.PRIVATE] - Version update plugin: xml parse error

Description: A new version of unRAIDServer is available

Importance: normal

Link to comment

Not sure if this was mentioned already...

 

I have 16 cores at my disposal:

 

v68v19Y.png

 

However, only cores 0 - 7 are available for pinning in the new VM Manager:

 

nrhNajC.png

 

Is this an issue or am I just not understanding?

 

John

Will chat with eric, not sure if his code has logic to handle more than 8 cores right now, but we can fix.

Link to comment

Not sure if this was mentioned already...

 

I have 16 cores at my disposal:

 

v68v19Y.png

 

However, only cores 0 - 7 are available for pinning in the new VM Manager:

 

nrhNajC.png

 

Is this an issue or am I just not understanding?

 

John

Will chat with eric, not sure if his code has logic to handle more than 8 cores right now, but we can fix.

 

I think it's quite right; he has 2 quad core Xeon E5530, so 8 cores or 16 threads with Hyper-Threading. You pin cores and not threads.

Link to comment

Are you sure about that? If I remember correctly my cpu has 4 cores or 8 threads with hyper threading and I have the option to pin 8 cores.

 

Yes, you're right. But if you pin a core and it's HT, you will not have 2 physical cores to that VM. If i'm not mistaken, in an 4 core processor with HT, core 0 and 4 are the same physical core, as 1 and 5, 2 and 6, 3 and 7.

 

The 8 core limit in the Gui must be a bug.

Link to comment

Are you sure about that? If I remember correctly my cpu has 4 cores or 8 threads with hyper threading and I have the option to pin 8 cores.

 

Yes, you're right. But if you pin a core and it's HT, you will not have 2 physical cores to that VM. If i'm not mistaken, in an 4 core processor with HT, core 0 and 4 are the same physical core, as 1 and 5, 2 and 6, 3 and 7.

 

The 8 core limit in the Gui must be a bug.

 

When hyperthreading is enabled, the hardware actually presents to the kernel as if there double the physical cores as were presented without hyperthreading, so while you are correct, a hyperthreaded core is not the same as a physical core, it really doesn't matter from the perspective of a VM.  With hyperthreading, each "virtual core" (if you want to call it that) is given partitioned access to the CPU including things like L1-L3 cache.  Example:  If HT is on and core 0 is in use while core 1 is also in use, context-switching doesn't have to occur.  If HT was off and the applications in question had to share core 0, then each time it would handoff between application 1 and application 2, a context-switch would occur which is very expensive and taxing on the CPU in comparison.  This is probably a bit more of an explanation than necessary, but hopefully the information is useful.  The point is that you pin vCPUs to cores and hyperthreading will essentially double the core count presented to the kernel.  The GUI not allowing for more than 8 is a bug.  A simple way to validate how many cores you have is to type the following command in SSH/telnet:

 

nproc

 

The number value returned represents the number of cores you have.

 

captain obvious here. when fixing the limit bug, shouldn't you make the # of the cpu pinning match the cpu speed.. one starts at 0 while starts at 1.

+1

 

Well there's two ways to do this:  we could fix the CPU speed to show cores starting at 0 (which is how the kernel counts them too) or we could adjust the presentation on the webGui side.  What's confusing is that in the XML for the VMs, pinning starts at 0, not 1, so to change the presentation in the webGui for CPU pinning to start with numeral 1 may inadvertently cause people to think the CPU pinning isn't working right with the XML.  It creates unnecessary confusion.  I will discuss with Tom/Eric to see how we want to handle it.  Most likely we'd adjust the dashboard CPU speed section to start with 0 instead of 1.

Link to comment
Guest
This topic is now closed to further replies.