MADRIX NEBULA is a flexible LED pixel tape driver to directly control a wide range of digital LEDs. Developed and made in Germany. PC Pitstop - PC Performance Roots. PC Pitstop began in 1999 with an emphasis on computer diagnostics and maintenance. During the early days of the dot com boom, our online PC maintenance tools were skyrocketing. Try to Uninstall USB Drivers Open Device Manager (Right Click on Windows Logo and Click Device Manager). Now find and expand Universal Serial Bus controllers. Now right-click on USB drivers and click Uninstall. Do for all USB drivers one by one. Restart your PC then Windows will reinstall the device automatically.

Note

1. This documentation is outdated. Please check at the DVB wikiat https://linuxtv.org/wiki for more updated info.
2. deprecated: Newer DVB USB drivers should use the dvb-usb-v2 framework.

In March 2005 I got the new Twinhan USB2.0 DVB-T device. They provided specsand a firmware.

Quite keen I wanted to put the driver (with some quirks of course) into dibusb.After reading some specs and doing some USB snooping, it realized, that thedibusb-driver would be a complete mess afterwards. So I decided to do it in adifferent way: With the help of a dvb-usb-framework.

The framework provides generic functions (mostly kernel API calls), such as:

• Transport Stream URB handling in conjunction with dvb-demux-feed-control(bulk and isoc are supported)
• registering the device for the DVB-API
• registering an I2C-adapter if applicable
• remote-control/input-device handling
• firmware requesting and loading (currently just for the Cypress USBcontrollers)
• other functions/methods which can be shared by several drivers (such asfunctions for bulk-control-commands)
• TODO: a I2C-chunker. It creates device-specific chunks of register-accessesdepending on length of a register and the number of values that can bemulti-written and multi-read.

The source code of the particular DVB USB devices does just the communicationwith the device via the bus. The connection between the DVB-API-functionalityis done via callbacks, assigned in a static device-description (structdvb_usb_device) each device-driver has to have.

For an example have a look in drivers/media/usb/dvb-usb/vp7045*.

Objective is to migrate all the usb-devices (dibusb, cinergyT2, maybe thettusb; flexcop-usb already benefits from the generic flexcop-device) to usethe dvb-usb-lib.

TODO: dynamic enabling and disabling of the pid-filter in regard to number offeeds requested.

6.1. Supported devices¶

See the LinuxTV DVB Wiki at https://linuxtv.org for a complete list ofcards/drivers/firmwares:https://linuxtv.org/wiki/index.php/DVB_USB

0. History & News:

2005-06-30

• added support for WideView WT-220U (Thanks to Steve Chang)

2005-05-30

• added basic isochronous support to the dvb-usb-framework

• added support for Conexant Hybrid reference design and Nebula

  DigiTV USB

2005-04-17

• all dibusb devices ported to make use of the dvb-usb-framework

2005-04-02

• re-enabled and improved remote control code.

2005-03-31

• ported the Yakumo/Hama/Typhoon DVB-T USB2.0 device to dvb-usb.

2005-03-30

• first commit of the dvb-usb-module based on the dibusb-source.First device is a new driver for theTwinhanDTV Alpha / MagicBox II USB2.0-only DVB-T device.
• (change from dvb-dibusb to dvb-usb)

2005-03-28

• added support for the AVerMedia AverTV DVB-T USB2.0 device(Thanks to Glen Harris and Jiun-Kuei Jung, AVerMedia)

2005-03-14

• added support for the Typhoon/Yakumo/HAMA DVB-T mobile USB2.0

2005-02-11

• added support for the KWorld/ADSTech Instant DVB-T USB2.0.Thanks a lot to Joachim von Caron

2005-02-02- added support for the Hauppauge Win-TV Nova-T USB2

2005-01-31- distorted streaming is gone for USB1.1 devices

2005-01-13

• moved the mirrored pid_filter_table back to dvb-dibusbfirst almost working version for HanfTek UMT-010found out, that Yakumo/HAMA/Typhoon are predecessors of the HanfTek UMT-010

2005-01-10

• refactoring completed, now everything is very delightful
• tuner quirks for some weird devices (Artec T1 AN2235 device has sometimes aPanasonic Tuner assembled). Tunerprobing implemented.Thanks a lot to Gunnar Wittich.

2004-12-29

• after several days of struggling around bug of no returning URBs fixed.

2004-12-26

• refactored the dibusb-driver, splitted into separate files
• i2c-probing enabled

2004-12-06

• possibility for demod i2c-address probing
• new usb IDs (Compro, Artec)

2004-11-23

• merged changes from DiB3000MC_ver2.1
• revised the debugging
• possibility to deliver the complete TS for USB2.0

2004-11-21

• first working version of the dib3000mc/p frontend driver.

2004-11-12

• added additional remote control keys. Thanks to Uwe Hanke.

2004-11-07

• added remote control support. Thanks to David Matthews.

2004-11-05

• added support for a new devices (Grandtec/Avermedia/Artec)
• merged my changes (for dib3000mb/dibusb) to the FE_REFACTORING, because it became HEAD
• moved transfer control (pid filter, fifo control) from usb driver to frontend, it seemsbetter settled there (added xfer_ops-struct)
• created a common files for frontends (mc/p/mb)

2004-09-28

• added support for a new device (Unknown, vendor ID is Hyper-Paltek)

2004-09-20

• added support for a new device (Compro DVB-U2000), thanksto Amaury Demol for reporting
• changed usb TS transfer method (several urbs, stopping transferbefore setting a new pid)

2004-09-13

• added support for a new device (Artec T1 USB TVBOX), thanksto Christian Motschke for reporting

2004-09-05

• released the dibusb device and dib3000mb-frontend driver(old news for vp7041.c)

2004-07-15

• found out, by accident, that the device has a TUA6010XS for PLL

2004-07-12

• figured out, that the driver should also work with theCTS Portable (Chinese Television System)

2004-07-08

• firmware-extraction-2.422-problem solved, driver is now workingproperly with firmware extracted from 2.422
• #if for 2.6.4 (dvb), compile issue
• changed firmware handling, see vp7041.txt sec 1.1

2004-07-02

• some tuner modifications, v0.1, cleanups, first public

2004-06-28

• now using the dvb_dmx_swfilter_packets, everything runs fine now

2004-06-27

• able to watch and switching channels (pre-alpha)
• no section filtering yet

2004-06-06

• first TS received, but kernel oops :/

2004-05-14

• firmware loader is working

2004-05-11

• start writing the driver

6.2. How to use?¶

6.2.1. Firmware¶

Most of the USB drivers need to download a firmware to the device before startworking.

Have a look at the Wikipage for the DVB-USB-drivers to find out, which firmwareyou need for your device:

6.2.2. Compiling¶

Since the driver is in the linux kernel, activating the driver inyour favorite config-environment should sufficient. I recommendto compile the driver as module. Hotplug does the rest.

If you use dvb-kernel enter the build-2.6 directory run ‘make’ and ‘insmod.shload’ afterwards.

6.2.3. Loading the drivers¶

Hotplug is able to load the driver, when it is needed (because you pluggedin the device).

If you want to enable debug output, you have to load the driver manually andfrom within the dvb-kernel cvs repository.

first have a look, which debug level are available:

should do the trick.

When the driver is loaded successfully, the firmware file was inthe right place and the device is connected, the “Power”-LED should beturned on.

At this point you should be able to start a dvb-capable application. I’m use(t|s)zap, mplayer and dvbscan to test the basics. VDR-xine provides thelong-term test scenario.

6.3. Known problems and bugs¶

• Don’t remove the USB device while running an DVB application, your systemwill go crazy or die most likely.

6.3.2. USB1.1 Bandwidth limitation¶

A lot of the currently supported devices are USB1.1 and thus they have amaximum bandwidth of about 5-6 MBit/s when connected to a USB2.0 hub.This is not enough for receiving the complete transport stream of aDVB-T channel (which is about 16 MBit/s). Normally this is not aproblem, if you only want to watch TV (this does not apply for HDTV),but watching a channel while recording another channel on the samefrequency simply does not work very well. This applies to all USB1.1DVB-T devices, not just the dvb-usb-devices)

The bug, where the TS is distorted by a heavy usage of the device is gonedefinitely. All dvb-usb-devices I was using (Twinhan, Kworld, DiBcom) areworking like charm now with VDR. Sometimes I even was able to record a channeland watch another one.

6.4. 3. Acknowledgements¶

Amaury Demol (Amaury.Demol@parrot.com) and Francois Kanounnikoff from DiBcom forproviding specs, code and help, on which the dvb-dibusb, dib3000mb anddib3000mc are based.

David Matthews for identifying a new device type (Artec T1 with AN2235)and for extending dibusb with remote control event handling. Thank you.

Alex Woods for frequently answering question about usb and dvbstuff, a big thank you.

Bernd Wagner for helping with huge bug reports and discussions.

Gunnar Wittich and Joachim von Caron for their trust for providingroot-shells on their machines to implement support for new devices.

Allan Third and Michael Hutchinson for their help to write the Nebuladigitv-driver.

Glen Harris for bringing up, that there is a new dibusb-device and Jiun-KueiJung from AVerMedia who kindly provided a special firmware to get the deviceup and running in Linux.

Nebula Media USB Devices Driver

Jennifer Chen, Jeff and Jack from Twinhan for kindly supporting bywriting the vp7045-driver.

Steve Chang from WideView for providing information for new devices andfirmware files.

Michael Paxton for submitting remote control keymaps.

Some guys on the linux-dvb mailing list for encouraging me.

Peter Schildmann >peter.schildmann-nospam-at-web.de< for hisuser-level firmware loader, which saves a lot of time(when writing the vp7041 driver)

Ulf Hermenau for helping me out with traditional chinese.

André Smoktun and Christian Frömmel for supporting me withhardware and listening to my problems very patiently.

This Section lays out the configuration requirements needed in the vCenter and ESX instances in order to be managed by OpenNebula.

The VMware vCenter drivers enable OpenNebula to access one or more vCenter servers that manage one or more ESX Clusters. Each ESX Cluster is presented in OpenNebula as an aggregated hypervisor, i.e. as an OpenNebula Host. This means that the representation is one OpenNebula Host per ESX Cluster.

Note that OpenNebula scheduling decisions are therefore made at ESX Cluster level. vCenter then uses the DRS component to select the actual ESX host and Datastore to deploy the Virtual Machine.

Requirements¶

The following must be met for a functional vCenter environment:

• Supported vSphere version (check Platform Notes) with at least one cluster aggregating at least one ESX.
• Define a vCenter user for OpenNebula. This vCenter user (let’s call her oneadmin) needs to have access to the ESX clusters that OpenNebula will manage. In order to avoid problems, the hassle free approach is to declare this oneadmin user as Administrator. However, in some enterprise environments declaring the user as Administrator is not allowed. In that case, you will need to grant permissions to perform some tasks. A table with the permissions required is found at the end of this chapter.
• All ESX hosts belonging to the same ESX cluster to be exposed to OpenNebula must share at least one datastore among them.
• The ESX cluster should have DRS enabled. DRS is not required but it is recommended. As OpenNebula does not schedule to the granularity of ESX hosts, DRS is needed to select the actual ESX host within the cluster, otherwise the VM will be launched in the ESX where the VM template has been created.
• If virtual standard switches are used, check that those switches exist in every ESX host belonging to the same ESX cluster, so the network represented by a port group can be used by a VM, no matter in what ESX host it’s running. If you use distributed virtual switches, check that ESX hosts have been added to switches.
• To enable VNC functionality, please check the detailed information in section VNC on ESX hosts below.

Important

OpenNebula will NOT modify any vCenter configuration with some exceptions, the creation of virtual switches and port groups if the vcenter network driver is used, and the creation of images for VMDK and/or ISO files.

Note

For security reasons, you may define different users to access different ESX Clusters. A different user can be defined in OpenNebula per ESX cluster, which is encapsulated in OpenNebula as an OpenNebula host.

Configuration¶

There are a few simple steps needed to configure OpenNebula so it can interact with vCenter:

Step 1: Check connectivity¶

The OpenNebula Front-end needs network connectivity to all the vCenters that it is supposed to manage.

Additionally, to enable VNC access to the spawned Virtual Machines, the Front-end also needs network connectivity to all the ESX hosts

Warning

OpenNebula uses port 443 to communicate with vCenter instances. Port 443 is the default port used by vCenter, so unless you’re filtering that port, or you’ve configured a different port to listen for connections from the vSphere Web Client, OpenNebula will be able to connect with the right credentials.

Step 2: Configure the drivers in the Front-end (oned.conf) [Optional]¶

The following sections in the /etc/one/oned.conf file describe the information and virtualization drivers for vCenter, which are enabled by default:

As a Virtualization driver, the vCenter driver accepts a series of parameters that control its execution. The parameters allowed are:

See the Virtual Machine drivers reference for more information about these parameters, and how to customize and extend the drivers.

Additionally some behavior of the vCenter driver can be configured in the /var/lib/one/remotes/etc/vmm/vcenter/vcenterrc. The parameters that can be changed here are as follows:

OpenNebula needs to be restarted after any change in the /etc/one/oned.conf file. This can be done with the following command:

Step 3: Importing vCenter Clusters¶

OpenNebula ships with a powerful CLI tool to import vCenter clusters, VM Templates, Networks and running VMs. The tool onevcenter is self-explanatory, just set the credentials and FQDN/IP to access the vCenter host and follow on screen instructions.

If you need to know how to import vCenter clusters, check vCenter import tool.

Once the vCenter cluster is monitored successfully, ON will show as the host status. If ERROR is shown please check connectivity and have a look to the /var/log/one/oned.log file in order to find out the possible cause.

The following variables are added to OpenNebula hosts representing ESX clusters:

Note

OpenNebula will create a special key at boot time and save it in /var/lib/one/.one/one_key. This key will be used as a private key to encrypt and decrypt all the passwords for all the vCenters that OpenNebula can access. Thus, the password shown in the OpenNebula host representing the vCenter is the original password encrypted with this special key.

Note

You have more information about what is a Managed Object Reference and what is the vCenter instance UUID in the vCenter driver section.

Step 4: Next Steps¶

Jump to the Verify your Installation section in order to launch a VM or learn how to setup the VMWare infrastructure.

Permissions requirement¶

If the user account that is going to be used in vCenter operations is not declared as an Administrator the following table summarizes the privileges required by the tasks performed in vCenter by OpenNebula:

Special Permission¶

The above permissions, except one, can be set at the Cluster level. However, OpenNebula needs access to the Customization spec for successful monitoring. This is a special privilege because it needs to be applied to vCenter server level. It means that if you try to apply the previous privileges into a cluster/datacenter and their inheritors, OpenNebula will fail and it will tell you that higher level permissions are necessary.

Our recommended approach its to create two roles, one for the general permissions (“opennebulapermissions”) that can be applied in the Cluster level, and another to handle this single permission. This way, you can create a role managing all OpenNebula permissions and another role (called for instance readcustspec) with only the next one:

Once you have created the proper role, one way to manage these privileges is creating two groups.

• The first group needs to be assigned the readcustspec role. Place the OpenNebula user inside this group and grant permission over the vCenter instance to the group.
• The second groups needs to be assigned the opennebulapermissions role. Place the OpenNebula user inside this group and grant permission over the desired cluster to the group.

Note

Do not forget to add the proper permissions to the datastores and any resource accessed by your OpenNebula user.

VNC on ESX hosts¶

To enable VNC functionality, you need to allow access to the VNC ports on ESX hosts. By default, access to these ports is filtered by the firewall. We provide an installation package, which adds the VNC ruleset (port range 5900-11999 excluding known reserved ports) and permits access to these ports. Also OpenNebula needs to be reconfigured to respect this specific VNC ports range. This package must be installed on each ESX host; it can be done via CLI or web UI. We’ll cover the necessary steps for both ways here.

Locations of the VIB installation package or ZIP bundle:

• On your OpenNebula Front-end server, in /usr/share/one/esx-fw-vnc/.Installed as part of the package
  • opennebula-server on RHEL/CentOS
  • opennebula on Debian and Ubuntu.
• On the public download server. In a case of installation problems,insecure HTTP access can be used at your own risk!

Note

Make sure that the ESX hosts are reachable from the OpenNebula Front-end.

The VNC range whitelisted on ESX hosts must be specified in the OpenNebula configuration located in /etc/one/oned.conf. Please change the VNC_PORTS section following way:

and, restart OpenNebula:

Using CLI¶

Note

Please replace the placeholder variables $ESX_HOST (ESX hostname),$ESX_USER (access user name) and $ESX_PSWD (access user’s password)with the valid access parameters depending on your infrastructure configuration.

Over SSH

If you have enabled direct SSH access on the ESX hosts, copy the VIB installationpackages to the ESX host via scp. Login the ESX host via SSH, allow the communitypackages to be installed and do the install.

What Is A Usb Devices

Note

The absolute path to the VIB must be provided.

This enables VNC ports for any remote host. You shouldlimit access to the VNC only from your OpenNebula Front-end. In thisexample, we restrict access only from IP address 192.168.0.1.

Repeat for each ESX host.

VMware vSphere CLI

If you have a working VMware vSphere CLI, you can install the packageremotely via esxcli.

First, check the CLI is working:

If the connection fails on untrusted fingerprint, please specify the validone as an extra esxcli parameter --thumbprint. Example:

Now, with all required connection parameters from a test above, use the esxclito allow the community packages to be installed and proceed with the install.

Note

VIB must be accessible from the ESX host, as an absolute file pathon the ESX host or downloadable URL.

Examples Of Usb Devices

This enables VNC ports for any remote host. You shouldlimit access to the VNC only from your OpenNebula Front-end. In thisexample, we restrict access only from IP address 192.168.0.1.

Repeat for each ESX host.

Using UI¶

The VIB package can also be installed over vSphere and ESX web UIs.

• Allow the custom VIB package to be installed (in the vSphere client)
  • Login the vSphere client
  • Go to Home -> Inventories -> Hosts and Clusters
  • Select the ESX host and its tab Manage or Configure (depends on the vSphere version)
  • Select Security Profile in the System category
  • At the very bottom, select edit on Host Image Profile Acceptance Level
  • Switch to Community Supported and confirm with OK

• Install the VIB package (in the ESX host UI)
  • Login the ESX host UI
  • Go to Help -> Update in top right corner
  • Provide the VIB URL or absolute local path and click on Update

Nebula Media Usb Devices Driver Updater

• Restrict VNC access to the OpenNebula Front-end only (in the vSphere client)
  • Go back again to the ESX host details in the vSphere client
  • Reload the vSphere page to see current data
  • Check again Security Profile in the System category, look on the Firewall/Incoming Connections for new VNC item
  • Click on Edit for the Firewall
  • Find the VNC and optionally restrict access only to your OpenNebula Front-end (e.g. for 192.168.0.1):

Nebula Media Usb Devices Driver Windows 10

Repeat for each ESX host.