unRAID Server Release 6.1-rc1 Available


Recommended Posts

Another notable addition to this release is the inclusion of the "OpenELEC" template type in VM Manager.

 

It may be prudent to note in the OP which version of OE is being pulled (latest stable, latest beta/RC, legacy stable, user choice, etc.)...especially for those that are using a shared mysql database.

 

Also, how are OE upgrades handled?

 

Nice work!

 

John

 

This... Also when there are multiple stable/rc builds will be able to choose which one or will we be locked into whichever one is the current unRAID OE VM?

 

Taking a moment to address a few questions on the OE VM.

 

Kernel panics from VM (not host OS) when trying to start

Tough to diagnose because the VM image is based on 6.0.0 beta 2 from OpenELEC which is based on Kodi 15.0 beta 2 (Isengard).  This means that the OS and the primary application are BOTH in a beta state, therefore issues relating to VM boot up could be due to problems in either of those layers on top of the potential for an issue relating to the virtual machine / GPU assignment itself.  A few things you can try here:

 

1 - Toggle "advanced" view on the VM page and switch the VM from SeaBIOS to OVMF and see if that changes anything.

2 - Do not assign the audio device to the VM (just do the graphics) and see if it boots.

3 - Try assigning an alternate audio device from the HDMI audio on the graphics device (assign an on-board audio device)

4 - Try utilizing a port on the card OTHER than HDMI (e.g. Displayport, VGA, or DVI)

 

RE: Updating the VM

The VM template is configured in such a way to make the image itself attach in a read-only state.  This allows you to create multiple OpenELEC instances off of a single image file.  As new updates are released, we will release new versions of the VM available for download from within the web interface.  You can then toggle to these new versions while pointing to the same config path so an update is really as simple as editing an existing VM, changing the version field, then downloading the new image and clicking update.

 

Stable / RC Builds

When 6.0.0 stable is released for OpenELEC, it's our intention to maintain pace with the current releases only, not necessarily RC's or betas.  We are just starting our initial template implementation using the OE RC.

Link to comment
  • Replies 114
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

a) If I dragged an image with say 96x96 dimensions it would appear like that in the browser and the Apply button would never be enabled.

 

This should only happen when the input is not accepted, but in such a case a proper warning should be displayed.

 

b) If instead I used manual selection, image would again be too large in browser, but Apply button would be enabled, but then clicking Apply had no effect - that is, the image was not uploaded.

 

Here apply should not have been enabled...

 

Guess, need to dig into the error handling code!

 

Ok, I've found the culprit and have made an update on github.

 

Btw have set now the following file size restrictions (feel free to adjust)

 

user images = max 50 KB

banner image = max 200 KB

 

Link to comment

Brian => Have you had a chance to confirm the > 25 devices support in this version?

 

i.e. the "Brian fix" I referred to here:

 

... Looking forward to Brian's feedback on this fix:  "emhttp: fix: let Pro start regardless of attached device count"

 

Yes, I was able to create and start an array with 30 drives installed in the box. But testing was limited as one of the controllers is acting flakey. Do not think it is an unRaid issue.

Link to comment
When you click Add VM from the VMs page, you will now notice a new option in the Template drop-down called OpenELEC.

Give it a name (e.g. Living Room Media Player).

The rest of the form will be reduced to just a download path field and button.  Provide a location (preferably a share that you use to create VMs) and click download and the process will start directly within the webGui.

If you navigate off this page while the download is proceeding, you can resume by returning to the Add VM page and selecting the template again.

After the download completes, the form will transform again allowing you to optionally configure additional settings for the VM.

The version field indicates the version of the VM image you downloaded.  When new releases are created, they will appear as a drop-down item here.  You can download the new image and either keep the old or delete it.

If an appdata share already exists on your system, the template form will automatically suggest a Config Folder of /mnt/user/appdata/OpenELEC, which it will create for you when you create the VM.

If you do not have an appdata share, you should either create one or provide an alternate path for where Kodi will store its application data (media library, config files, etc.)

The minimum CPU and memory required for OpenELEC is 1 core and 512MB of RAM.

Different skins / customizations / adjustments may perform better with more resources assigned.  Adjust as necessary

Graphics support is limited to physical GPUs only (no on-board GPUs).

Some AMD GPUs may not support VDPAU encoding properly for media content.  You can disable this under the System -> Video preferences page in OpenELEC (turn on Expert mode).  This only affects certain media files

You can redirect audio through an alternate sound device than what is built into your GPU.  This includes HD audio ports on the motherboard (Optical, HDMI, Digital Coax) as well as analog audio (stereo ports, headphone jacks, microphone ports).

Add media content through the normal process for Kodi (we’ve tested SMB protocol and NFS protocol in our use).

 

Once installed, how do I go to OpenELEC?

 

Link to comment

When you click Add VM from the VMs page, you will now notice a new option in the Template drop-down called OpenELEC.

Give it a name (e.g. Living Room Media Player).

The rest of the form will be reduced to just a download path field and button.  Provide a location (preferably a share that you use to create VMs) and click download and the process will start directly within the webGui.

If you navigate off this page while the download is proceeding, you can resume by returning to the Add VM page and selecting the template again.

After the download completes, the form will transform again allowing you to optionally configure additional settings for the VM.

The version field indicates the version of the VM image you downloaded.  When new releases are created, they will appear as a drop-down item here.  You can download the new image and either keep the old or delete it.

If an appdata share already exists on your system, the template form will automatically suggest a Config Folder of /mnt/user/appdata/OpenELEC, which it will create for you when you create the VM.

If you do not have an appdata share, you should either create one or provide an alternate path for where Kodi will store its application data (media library, config files, etc.)

The minimum CPU and memory required for OpenELEC is 1 core and 512MB of RAM.

Different skins / customizations / adjustments may perform better with more resources assigned.  Adjust as necessary

Graphics support is limited to physical GPUs only (no on-board GPUs).

Some AMD GPUs may not support VDPAU encoding properly for media content.  You can disable this under the System -> Video preferences page in OpenELEC (turn on Expert mode).  This only affects certain media files

You can redirect audio through an alternate sound device than what is built into your GPU.  This includes HD audio ports on the motherboard (Optical, HDMI, Digital Coax) as well as analog audio (stereo ports, headphone jacks, microphone ports).

Add media content through the normal process for Kodi (we’ve tested SMB protocol and NFS protocol in our use).

 

Once installed, how do I go to OpenELEC?

 

It should be displayed on whichever monitor/TV you have connected to the passed-through vid card.

Link to comment

That means I have to move a long cable, between the server and My TV set in the living room, a distance of 2.5 m? There is no better method to move the display over a network?

For the ultra professional way of doing things, you can always check out the offerings from Matrox graphics.  I think they max out at a distance of 10km.  http://www.matrox.com/graphics/en/

 

Or, you could search for video over ethernet.  Something like this should work:  http://www.newegg.ca/Product/Product.aspx?Item=N82E16815158371CVF&nm_mc=KNC-GoogleAdwordsCA-PC&cm_mmc=KNC-GoogleAdwordsCA-PC-_-pla-_-Pro+A%2fV+Extender+%26+Repeater-_-N82E16815158371CVF&gclid=CIX3lKrN7MYCFQipaQodFWEBmQ

  Maximum run something like 100m.

 

But for a run of 2.5 meters, there's no real need to spend the $$ required, unless its impossible to route the HDMI cable.  Using active HDMI cables, you can probably get up to about 30m with no loss in signal.

Link to comment

Another notable addition to this release is the inclusion of the "OpenELEC" template type in VM Manager.

 

It may be prudent to note in the OP which version of OE is being pulled (latest stable, latest beta/RC, legacy stable, user choice, etc.)...especially for those that are using a shared mysql database.

 

Also, how are OE upgrades handled?

 

Nice work!

 

John

 

This... Also when there are multiple stable/rc builds will be able to choose which one or will we be locked into whichever one is the current unRAID OE VM?

 

Taking a moment to address a few questions on the OE VM.

 

Kernel panics from VM (not host OS) when trying to start

Tough to diagnose because the VM image is based on 6.0.0 beta 2 from OpenELEC which is based on Kodi 15.0 beta 2 (Isengard).  This means that the OS and the primary application are BOTH in a beta state, therefore issues relating to VM boot up could be due to problems in either of those layers on top of the potential for an issue relating to the virtual machine / GPU assignment itself.  A few things you can try here:

 

1 - Toggle "advanced" view on the VM page and switch the VM from SeaBIOS to OVMF and see if that changes anything.

2 - Do not assign the audio device to the VM (just do the graphics) and see if it boots.

3 - Try assigning an alternate audio device from the HDMI audio on the graphics device (assign an on-board audio device)

4 - Try utilizing a port on the card OTHER than HDMI (e.g. Displayport, VGA, or DVI)

 

RE: Updating the VM

The VM template is configured in such a way to make the image itself attach in a read-only state.  This allows you to create multiple OpenELEC instances off of a single image file.  As new updates are released, we will release new versions of the VM available for download from within the web interface.  You can then toggle to these new versions while pointing to the same config path so an update is really as simple as editing an existing VM, changing the version field, then downloading the new image and clicking update.

 

Stable / RC Builds

When 6.0.0 stable is released for OpenELEC, it's our intention to maintain pace with the current releases only, not necessarily RC's or betas.  We are just starting our initial template implementation using the OE RC.

@JonP I've tried all of your above suggestions.  After completely removing the VM and associated files and choosing OVMF I'm receiving a "Failed to start Xorg Server" error.  Suggestions 2-4 yield either the same error or a kernel panic when using SeaBIOS.

 

@johnodon I've been successfully running Windows and Ubuntu KVM VMs for quite some time using both SeaBIOS and OVMF.

 

All of your feedback has been greatly appreciated.

2015-07-21-08_58_28.jpg.aa23e19018ec7f87a288df0fa07829e5.jpg

Link to comment

 

@johnodon I've been successfully running Windows and Ubuntu KVM VMs for quite some time using both SeaBIOS and OVMF.

 

 

But have you been successfully passing through a GPU to one of both of those?  Or are you connecting to them via VNC/RDP?

 

Can you also copy/paste your XML for the problematic OE VM?

Link to comment

 

@johnodon I've been successfully running Windows and Ubuntu KVM VMs for quite some time using both SeaBIOS and OVMF.

 

 

But have you been successfully passing through a GPU to one of both of those?  Or are you connecting to them via VNC/RDP?

 

Can you also copy/paste your XML for the problematic OE VM?

Successfully GPU passthrough on both Windows and Ubuntu.  In fact, I'm posting this from a Windows 8.1 VM on a passed through AMD Radeon R9 270.

 

Here is the template generated XML for the OE VM.

<domain type='kvm'>
  <name>Openelec</name>
  <uuid>f4338f06-c190-0529-2aa4-5578bd244da2</uuid>
  <metadata>
    <vmtemplate name="OpenELEC" icon="openelec.png" os="openelec" openelec="5.95.2_1"/>
  </metadata>
  <memory unit='KiB'>524288</memory>
  <currentMemory unit='KiB'>524288</currentMemory>
  <memoryBacking>
    <nosharepages/>
    <locked/>
  </memoryBacking>
  <vcpu placement='static'>1</vcpu>
  <cputune>
    <vcpupin vcpu='0' cpuset='0'/>
  </cputune>
  <os>
    <type arch='x86_64' machine='pc-q35-2.3'>hvm</type>
    <loader type='pflash'>/usr/share/qemu/ovmf-x64/OVMF-pure-efi.fd</loader>
  </os>
  <features>
    <acpi/>
    <apic/>
  </features>
  <cpu mode='host-passthrough'>
    <topology sockets='1' cores='1' threads='1'/>
  </cpu>
  <clock offset='utc'>
    <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/bin/qemu-system-x86_64</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw' cache='writeback'/>
      <source file='/mnt/cache/vm/OpenELEC-unRAID.x86_64-5.95.2_1.img'/>
      <target dev='hda' bus='virtio'/>
      <boot order='1'/>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x05' function='0x0'/>
    </disk>
    <controller type='usb' index='0' model='ich9-ehci1'>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x03' function='0x7'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci1'>
      <master startport='0'/>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x03' function='0x0' multifunction='on'/>
    </controller>
    <controller type='sata' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/>
    </controller>
    <controller type='pci' index='0' model='pcie-root'/>
    <controller type='pci' index='1' model='dmi-to-pci-bridge'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1e' function='0x0'/>
    </controller>
    <controller type='pci' index='2' model='pci-bridge'>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x01' function='0x0'/>
    </controller>
    <controller type='virtio-serial' index='0'>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x04' function='0x0'/>
    </controller>
    <filesystem type='mount' accessmode='passthrough'>
      <source dir='/mnt/user/appdata/OpenELEC/'/>
      <target dir='appconfig'/>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x01' function='0x0'/>
    </filesystem>
    <interface type='bridge'>
      <mac address='52:54:00:d1:e8:d4'/>
      <source bridge='br0'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x02' 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='bind' path='/var/lib/libvirt/qemu/channel/target/Openelec.org.qemu.guest_agent.0'/>
      <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'>
      <driver name='vfio'/>
      <source>
        <address domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
      </source>
      <address type='pci' domain='0x0000' bus='0x02' 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>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x07' function='0x0'/>
    </hostdev>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x08' function='0x0'/>
    </memballoon>
  </devices>
</domain>

Link to comment

But for a run of 2.5 meters, there's no real need to spend the $$ required, unless its impossible to route the HDMI cable.  Using active HDMI cables, you can probably get up to about 30m with no loss in signal.

 

I run a 35m Monoprice HDMI 1.3 cable (a non-active cable) and it works just fine.

Link to comment

Another notable addition to this release is the inclusion of the "OpenELEC" template type in VM Manager.

 

It may be prudent to note in the OP which version of OE is being pulled (latest stable, latest beta/RC, legacy stable, user choice, etc.)...especially for those that are using a shared mysql database.

 

Also, how are OE upgrades handled?

 

Nice work!

 

John

 

This... Also when there are multiple stable/rc builds will be able to choose which one or will we be locked into whichever one is the current unRAID OE VM?

 

Taking a moment to address a few questions on the OE VM.

 

Kernel panics from VM (not host OS) when trying to start

Tough to diagnose because the VM image is based on 6.0.0 beta 2 from OpenELEC which is based on Kodi 15.0 beta 2 (Isengard).  This means that the OS and the primary application are BOTH in a beta state, therefore issues relating to VM boot up could be due to problems in either of those layers on top of the potential for an issue relating to the virtual machine / GPU assignment itself.  A few things you can try here:

 

1 - Toggle "advanced" view on the VM page and switch the VM from SeaBIOS to OVMF and see if that changes anything.

2 - Do not assign the audio device to the VM (just do the graphics) and see if it boots.

3 - Try assigning an alternate audio device from the HDMI audio on the graphics device (assign an on-board audio device)

4 - Try utilizing a port on the card OTHER than HDMI (e.g. Displayport, VGA, or DVI)

 

RE: Updating the VM

The VM template is configured in such a way to make the image itself attach in a read-only state.  This allows you to create multiple OpenELEC instances off of a single image file.  As new updates are released, we will release new versions of the VM available for download from within the web interface.  You can then toggle to these new versions while pointing to the same config path so an update is really as simple as editing an existing VM, changing the version field, then downloading the new image and clicking update.

 

Stable / RC Builds

When 6.0.0 stable is released for OpenELEC, it's our intention to maintain pace with the current releases only, not necessarily RC's or betas.  We are just starting our initial template implementation using the OE RC.

@JonP I've tried all of your above suggestions.  After completely removing the VM and associated files and choosing OVMF I'm receiving a "Failed to start Xorg Server" error.  Suggestions 2-4 yield either the same error or a kernel panic when using SeaBIOS.

 

@johnodon I've been successfully running Windows and Ubuntu KVM VMs for quite some time using both SeaBIOS and OVMF.

 

All of your feedback has been greatly appreciated.

Ok, you'll want to try modifying the XML to pass it your GPU rom manually (see the wiki manual in my signature for a guide on this).

Link to comment

Another notable addition to this release is the inclusion of the "OpenELEC" template type in VM Manager.

 

It may be prudent to note in the OP which version of OE is being pulled (latest stable, latest beta/RC, legacy stable, user choice, etc.)...especially for those that are using a shared mysql database.

 

Also, how are OE upgrades handled?

 

Nice work!

 

John

 

This... Also when there are multiple stable/rc builds will be able to choose which one or will we be locked into whichever one is the current unRAID OE VM?

 

Taking a moment to address a few questions on the OE VM.

 

Kernel panics from VM (not host OS) when trying to start

Tough to diagnose because the VM image is based on 6.0.0 beta 2 from OpenELEC which is based on Kodi 15.0 beta 2 (Isengard).  This means that the OS and the primary application are BOTH in a beta state, therefore issues relating to VM boot up could be due to problems in either of those layers on top of the potential for an issue relating to the virtual machine / GPU assignment itself.  A few things you can try here:

 

1 - Toggle "advanced" view on the VM page and switch the VM from SeaBIOS to OVMF and see if that changes anything.

2 - Do not assign the audio device to the VM (just do the graphics) and see if it boots.

3 - Try assigning an alternate audio device from the HDMI audio on the graphics device (assign an on-board audio device)

4 - Try utilizing a port on the card OTHER than HDMI (e.g. Displayport, VGA, or DVI)

 

RE: Updating the VM

The VM template is configured in such a way to make the image itself attach in a read-only state.  This allows you to create multiple OpenELEC instances off of a single image file.  As new updates are released, we will release new versions of the VM available for download from within the web interface.  You can then toggle to these new versions while pointing to the same config path so an update is really as simple as editing an existing VM, changing the version field, then downloading the new image and clicking update.

 

Stable / RC Builds

When 6.0.0 stable is released for OpenELEC, it's our intention to maintain pace with the current releases only, not necessarily RC's or betas.  We are just starting our initial template implementation using the OE RC.

@JonP I've tried all of your above suggestions.  After completely removing the VM and associated files and choosing OVMF I'm receiving a "Failed to start Xorg Server" error.  Suggestions 2-4 yield either the same error or a kernel panic when using SeaBIOS.

 

@johnodon I've been successfully running Windows and Ubuntu KVM VMs for quite some time using both SeaBIOS and OVMF.

 

All of your feedback has been greatly appreciated.

Ok, you'll want to try modifying the XML to pass it your GPU rom manually (see the wiki manual in my signature for a guide on this).

After editing the XML file OE VM is booting properly.  Your help has been greatly appreciated.

<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
  <name>OpenELEC</name>
  <uuid>4eae880e-07f3-e670-40bb-7e9899ce542c</uuid>
  <metadata>
    <vmtemplate name="OpenELEC" icon="openelec.png" os="openelec" openelec="5.95.2_1"/>
  </metadata>
  <memory unit='KiB'>2097152</memory>
  <currentMemory unit='KiB'>2097152</currentMemory>
  <memoryBacking>
    <nosharepages/>
    <locked/>
  </memoryBacking>
  <vcpu placement='static'>2</vcpu>
  <cputune>
    <vcpupin vcpu='0' cpuset='2'/>
    <vcpupin vcpu='1' cpuset='3'/>
  </cputune>
  <os>
    <type arch='x86_64' machine='pc-q35-2.3'>hvm</type>
  </os>
  <features>
    <acpi/>
    <apic/>
  </features>
  <cpu mode='host-passthrough'>
    <topology sockets='1' cores='2' threads='1'/>
  </cpu>
  <clock offset='utc'>
    <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/bin/qemu-system-x86_64</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw' cache='writeback'/>
      <source file='/mnt/cache/vm/OpenELEC-unRAID.x86_64-5.95.2_1.img'/>
      <target dev='hda' bus='virtio'/>
      <boot order='1'/>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x05' function='0x0'/>
    </disk>
    <controller type='usb' index='0' model='ich9-ehci1'>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x03' function='0x7'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci1'>
      <master startport='0'/>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x03' function='0x0' multifunction='on'/>
    </controller>
    <controller type='sata' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/>
    </controller>
    <controller type='pci' index='0' model='pcie-root'/>
    <controller type='pci' index='1' model='dmi-to-pci-bridge'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1e' function='0x0'/>
    </controller>
    <controller type='pci' index='2' model='pci-bridge'>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x01' function='0x0'/>
    </controller>
    <controller type='virtio-serial' index='0'>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x04' function='0x0'/>
    </controller>
    <filesystem type='mount' accessmode='passthrough'>
      <source dir='/mnt/user/appdata/OpenELEC/'/>
      <target dir='appconfig'/>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x01' function='0x0'/>
    </filesystem>
    <interface type='bridge'>
      <mac address='52:54:00:82:84:a6'/>
      <source bridge='br0'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x02' 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='bind' path='/var/lib/libvirt/qemu/channel/target/OpenELEC.org.qemu.guest_agent.0'/>
      <target type='virtio' name='org.qemu.guest_agent.0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    </channel>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x06' function='0x0'/>
    </memballoon>
  </devices>
  <qemu:commandline>
    <qemu:arg value='-device'/>
    <qemu:arg value='ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1'/>
    <qemu:arg value='-device'/>
    <qemu:arg value='vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on'/>
    <qemu:arg value='-device'/>
    <qemu:arg value='vfio-pci,host=01:00.1,bus=root.1,addr=00.1'/>
    <qemu:arg value='-device'/>
    <qemu:arg value='vfio-pci,host=00:1d.0'/>
  </qemu:commandline>
</domain>

Link to comment

I don't get it.  What did you edit in the xml? I don't see a GPU rom.

 

Isn't it this from his XML above:

 

  <qemu:commandline>
    <qemu:arg value='-device'/>
    <qemu:arg value='ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1'/>
    <qemu:arg value='-device'/>
    <qemu:arg value='vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on'/>
    <qemu:arg value='-device'/>
    <qemu:arg value='vfio-pci,host=01:00.1,bus=root.1,addr=00.1'/>
    <qemu:arg value='-device'/>
    <qemu:arg value='vfio-pci,host=00:1d.0'/>
  </qemu:commandline>

 

Link to comment

I don't get it.  What did you edit in the xml? I don't see a GPU rom.

 

Isn't it this from his XML above:

 

  <qemu:commandline>
    <qemu:arg value='-device'/>
    <qemu:arg value='ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1'/>
    <qemu:arg value='-device'/>
    <qemu:arg value='vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on'/>
    <qemu:arg value='-device'/>
    <qemu:arg value='vfio-pci,host=01:00.1,bus=root.1,addr=00.1'/>
    <qemu:arg value='-device'/>
    <qemu:arg value='vfio-pci,host=00:1d.0'/>
  </qemu:commandline>

No. I don't see a rom file in there.

Link to comment

I don't get it.  What did you edit in the xml? I don't see a GPU rom.

 

Isn't it this from his XML above:

 

  <qemu:commandline>
    <qemu:arg value='-device'/>
    <qemu:arg value='ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1'/>
    <qemu:arg value='-device'/>
    <qemu:arg value='vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on'/>
    <qemu:arg value='-device'/>
    <qemu:arg value='vfio-pci,host=01:00.1,bus=root.1,addr=00.1'/>
    <qemu:arg value='-device'/>
    <qemu:arg value='vfio-pci,host=00:1d.0'/>
  </qemu:commandline>

No. I don't see a rom file in there.

 

I'm looking at the wiki now and this rom.bin stuff is new to me.  I don't have it defined in any of my 3 OE VMs.  Here is one of them:

 

<domain type='kvm' id='3' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
  <name>HTPCPLAYRM</name>
  <uuid>58f0eb06-dbe4-bc9c-50c5-dd219d610ef4</uuid>
  <metadata>
    <vmtemplate name="Custom" icon="openelec.png" os="openelec"/>
  </metadata>
  <memory unit='KiB'>2097152</memory>
  <currentMemory unit='KiB'>2097152</currentMemory>
  <memoryBacking>
    <nosharepages/>
    <locked/>
  </memoryBacking>
  <vcpu placement='static'>2</vcpu>
  <cputune>
    <vcpupin vcpu='0' cpuset='12'/>
    <vcpupin vcpu='1' cpuset='13'/>
  </cputune>
  <resource>
    <partition>/machine</partition>
  </resource>
  <os>
    <type arch='x86_64' machine='pc-q35-2.3'>hvm</type>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
  </features>
  <cpu mode='host-passthrough'>
    <topology sockets='1' cores='2' threads='1'/>
  </cpu>
  <clock offset='utc'>
    <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/bin/qemu-system-x86_64</emulator>
    <controller type='usb' index='0' model='ich9-ehci1'>
      <alias name='usb'/>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x02' function='0x7'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci1'>
      <alias name='usb'/>
      <master startport='0'/>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x02' function='0x0' multifunction='on'/>
    </controller>
    <controller type='sata' index='0'>
      <alias name='ide'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/>
    </controller>
    <controller type='pci' index='0' model='pcie-root'>
      <alias name='pcie.0'/>
    </controller>
    <controller type='pci' index='1' model='dmi-to-pci-bridge'>
      <alias name='pci.1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1e' function='0x0'/>
    </controller>
    <controller type='pci' index='2' model='pci-bridge'>
      <alias name='pci.2'/>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x01' function='0x0'/>
    </controller>
    <controller type='virtio-serial' index='0'>
      <alias name='virtio-serial0'/>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x03' function='0x0'/>
    </controller>
    <interface type='bridge'>
      <mac address='52:54:00:17:ea:29'/>
      <source bridge='br0'/>
      <target dev='vnet1'/>
      <model type='e1000'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x01' function='0x0'/>
    </interface>
    <serial type='pty'>
      <source path='/dev/pts/1'/>
      <target port='0'/>
      <alias name='serial0'/>
    </serial>
    <console type='pty' tty='/dev/pts/1'>
      <source path='/dev/pts/1'/>
      <target type='serial' port='0'/>
      <alias name='serial0'/>
    </console>
    <channel type='unix'>
      <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/HTPCPLAYRM.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>
    <hostdev mode='subsystem' type='usb' managed='no'>
      <source>
        <address bus='2' device='4'/>
      </source>
      <alias name='hostdev0'/>
    </hostdev>
    <memballoon model='virtio'>
      <alias name='balloon0'/>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x04' function='0x0'/>
    </memballoon>
  </devices>
  <qemu:commandline>
    <qemu:arg value='-device'/>
    <qemu:arg value='ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=2,chassis=1,id=root.1'/>
    <qemu:arg value='-device'/>
    <qemu:arg value='vfio-pci,host=86:00.0,bus=pcie.0,multifunction=on,x-vga=on'/>
    <qemu:arg value='-device'/>
    <qemu:arg value='vfio-pci,host=86:00.1,bus=pcie.0'/>
  </qemu:commandline>
</domain>

Link to comment

Noticed this in my log:

 

Jul 23 04:50:47 media01 kernel: timekeeping watchdog: Marking clocksource 'tsc' as unstable, because the skew is too large:
Jul 23 04:50:47 media01 kernel: 'hpet' wd_now: 6da0260f wd_last: 6d1ee276 mask: ffffffff
Jul 23 04:50:47 media01 kernel: 'tsc' cs_now: 292d9f99dfeaf cs_last: 292d98b8a523c mask: ffffffffffffffff
Jul 23 04:50:47 media01 kernel: Switched to clocksource hpet

 

 

 

Link to comment

Noticed this in my log:

 

Jul 23 04:50:47 media01 kernel: timekeeping watchdog: Marking clocksource 'tsc' as unstable, because the skew is too large:
Jul 23 04:50:47 media01 kernel: 'hpet' wd_now: 6da0260f wd_last: 6d1ee276 mask: ffffffff
Jul 23 04:50:47 media01 kernel: 'tsc' cs_now: 292d9f99dfeaf cs_last: 292d98b8a523c mask: ffffffffffffffff
Jul 23 04:50:47 media01 kernel: Switched to clocksource hpet

 

I suspect you're curious, wondering if this is normal or not, and if not, is it a problem with unRAID or Linux or your motherboard or ...  I haven't done any specific research, so this is just a general comment, and I don't want to go too far off-topic.

 

Timekeeping and clocking is a complex subject, but absolutely vital in all electronics, especially modern computers.  Your motherboard and addon cards and all attached devices have numerous clocking mechanisms, some of which are made available to the system.  If you examine any syslog, you'll see the kernel switch between different ones as it progresses through the initialization and setup and general operation.  Because it is so vital, and because different timers can be more or less reliable under differing conditions, there are 'watchdogs' that check the accuracy of each, compare them, and cause the kernel to change horses once in a while, as you saw in your syslog.  It's rather common to see some adjustment of clock sources, but perhaps not so common to the extent that yours was detailed.  There's nothing to worry about.  I *think* it just means that a commonly used clock source on your motherboard is not as reliable as it could be, but there are always others, and the kernel is just reporting that, in detail.

Link to comment

Can someone confirm that the "Check for Updates" function on the Docker tab still works?  In the past, each status would spin for a good 20 seconds or so before coming back with the result.  Now when I click it, the page refreshes instantly and all of my containers say ""up-to-date".

 

Was there a change made that sped things up or is the check failing?

 

John

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.