Dell Driver Support
Martial Salleh
Dell_RBU driver supports BIOS update using the monolithic image and packetizedimage methods. In case of monolithic the driver allocates a contiguous chunkof physical pages having the BIOS image. In case of packetized the appusing the driver breaks the image in to packets of fixed sizes and the driverwould place each packet in contiguous physical memory. The driver alsomaintains a link list of packets for reading them back.
The driver supports two types of update mechanism; monolithic and packetized.These update mechanism depends upon the BIOS currently running on the system.Most of the Dell systems support a monolithic update where the BIOS image iscopied to a single contiguous block of physical memory.
By default the driver uses monolithic memory for the update type. This can bechanged to packets during the driver load time by specifying the loadparameter image_type=packet. This can also be changed later as below:
In the packet update mechanism, the user needs to create a new file havingpackets of data arranged back to back. It can be done as follows:The user creates packets header, gets the chunk of the BIOS image andplaces it next to the packetheader; now, the packetheader + BIOS image chunkadded together should match the specified packet_size. This makes onepacket, the user needs to create more such packets out of the entire BIOSimage file and then arrange all these packets back to back in to one singlefile.
This file is then copied to /sys/class/firmware/dell_rbu/data.Once this file gets to the driver, the driver extracts packet_size data fromthe file and spreads it across the physical memory in contiguous packet_sizedspace.
CSM for Authorization provides storage and Kubernetes administrators the ability to apply RBAC for Dell CSI Drivers. It does this by deploying a proxy between the CSI driver and the storage system to enforce role-based access and usage rules.
Storage administrators of compatible storage platforms will be able to apply quota and RBAC rules that instantly and automatically restrict cluster tenants usage of storage resources. Users of storage through CSM for Authorization do not need to have storage admin root credentials to access the storage system.
Kubernetes administrators will have an interface to create, delete, and manage roles/groups that storage rules may be applied. Administrators and/or users may then generate authentication tokens that may be used by tenants to use storage with proper access policies being automatically enforced.
The following diagram shows a high-level overview of CSM for Authorization with a tenant-app that is using a CSI driver to perform storage operations through the CSM for Authorization proxy-server to access the a Dell storage system. All requests from the CSI driver will contain the token for the given tenant that was granted by the Storage Administrator.
NOTE: PowerScale OneFS implements its own form of Role-Based Access Control (RBAC). CSM for Authorization does not enforce any role-based restrictions for PowerScale. To configure RBAC for PowerScale, refer to the PowerScale OneFS documentation.
CSM for Authorization supports the following CSI drivers and versions.Storage ArrayCSI DriverSupported VersionsCSI Driver for Dell PowerFlexcsi-powerflexv2.0 +CSI Driver for Dell PowerMaxcsi-powermaxv2.0 +CSI Driver for Dell PowerScalecsi-powerscalev2.0 +
CSM for Authorization consists of 2 components - the Authorization sidecar and the Authorization proxy server. It is important that the version of the Authorization sidecar image maps to a supported version of the Authorization proxy server.
The EMC Shared File Systems service driver framework (EMCShareDriver)utilizes the EMC storage products to provide the shared file systems toOpenStack. The EMC driver is a plug-in based driver which is designed touse different plug-ins to manage different EMC storage products.
This driver performs the operations on Unity through RESTful APIs. Each backendmanages one Storage Processor of Unity. Configure multiple Shared FileSystems service backends to manage multiple Unity systems.
We recommend this type of network topology in Manila.In most use cases, VLAN is used to isolate the different tenants and providean isolated network for each tenant. To support this function, anadministrator needs to set a slot connected with Unity Ethernet port inTrunk mode or allow multiple VLANs from the slot.
Unity native VXLAN is still unavailable. However, with the HPB(Hierarchical Port Binding) in Networking and Shared file system services,it is possible that Unity co-exists with VXLAN enabled network environment.
Comma separated list specifying the ethernet ports of Unity systemthat can be used for share. Do not set this option if all ethernet portscan be used.Wild card character is supported. Both the normal ethernet port and linkaggregation port can be used by Unity share driver.
Whether or not report default filter function. Default value is False.However, this value will be changed to True in a future release to ensurecompliance with design expectations in Manila. So we recommend alwayssetting this option in your deployment to True or False per your desiredbehavior.
If you want to connect Unity using IPv6 address, you should configure IPv6address by /net/if/mgmt uemcli command, mgmtInterfaceSettings RESTful apior the system settings of Unity GUI for Unity and specify the address in/etc/manila/manila.conf:
Unity share driver provides IP based authentication method support forNFS shares and user based authentication method for CIFS sharesrespectively. For CIFS share, Microsoft Active Directory is the onlysupported security service.
The Unity driver automatically distributes the file interfaces per storageprocessor based on the option unity_ethernet_ports. This balances IOtraffic. The recommended configuration for unity_ethernet_ports specifiesbalanced ports per storage processor. For example:
This is a preliminary document. It is incomplete, and in need ofadditional content. Please send additional information on IA-64processors, motherboards, and various devices working on FreeBSD tothe FreeBSD IA64 porting mailing list.
This document contains the hardware compatibility notes forFreeBSD 5.4-RELEASE on the IA-64 hardware platform (also referredto as FreeBSD/ia64 5.4-RELEASE). It lists devices known to work onthis platform, as well as some notes on boot-time kernelcustomization that may be useful when attempting to configuresupport for new devices.
Both Uniprocessor (UP) and Symmetric Multi-processor (SMP)configurations are under active development. At this time,SMP-enabled systems are considered less stable. The currentpriorities are UP fixes to improve stability.
Except for the PC chipset embedded ata(4) controllers, most shouldwork out of the box. Eventually, all ia64-compatible ATAcontrollers are expected to be fully supported. Refer to thefollowing sections for various disk controllers and their currentstatus.
In general, ``PC standard'' serial ports supported by thesio(4) driver are expected towork on Intel legacy machines, but not PA legacy machines. Thereason is that all devices on HP machines are memory-mapped andthere is noISA device support other than the PCI dictated VGA legacy.
In addition to sio(4) devices, the followingdevices fail on non-Intel legacy machines (but should work on boxeswith an Intel legacy) because their drivers make ISA-specificassumptions that do not hold:
This section describes the devices currently known to besupported by with FreeBSD on the IA-64 platform. Otherconfigurations may also work, but simply have not been tested yet.Feedback, updates, and corrections to this list are encouraged.
Where possible, the drivers applicable to each device or classof devices is listed. If the driver in question has a manual pagein the FreeBSD base distribution (most should), it is referencedhere. Information on specific models of supported devices,controllers, etc. can be found in the manual pages.
Note: The device lists in this document are beinggenerated automatically from FreeBSD manual pages. This means thatsome devices, which are supported by multiple drivers, may appearmultiple times.
All major firmware revisions (2.x, 3.x, 4.x and 5.x) aresupported, however it is always advisable to upgrade to the mostrecent firmware available for the controller. Compatible Mylexcontrollers not listed should work, but have not been verified.
With all supported SCSI controllers, full support is providedfor SCSI-I, SCSI-II, and SCSI-III peripherals, including harddisks, optical disks, tape drives (including DAT, 8mm Exabyte,Mammoth, and DLT), medium changers, processor target devices andCD-ROM drives. WORM devices that support CD-ROM commands aresupported for read-only access by the CD-ROM drivers (such ascd(4)). WORM/CD-R/CD-RW writingsupport is provided by cdrecord(1), which is a part ofthe sysutils/cdrtools port in the PortsCollection.
The sis(4) driver supports SiliconIntegrated Systems SiS 900 and SiS 7016 based Fast Ethernetadapters and embedded controllers, as well as Fast Ethernetadapters based on the National Semiconductor DP83815 (MacPhyter)chip. Supported adapters include:
This document contains the hardware compatibility notes forFreeBSD 6.1-RELEASE on the IA-64 hardware platform (also referredto as FreeBSD/ia64 6.1-RELEASE). It lists devices known to work onthis platform, as well as some notes on boot-time kernelcustomization that may be useful when attempting to configuresupport for new devices.
Most devices that can be found in or are compatible with ia64machines are fully supported. The notable exception is the VGAconsole. The FreeBSD support for VGA consoles is at this time toomuch based on PC hardware and not all ia64 machines have chipsetsthat provide sufficient PC legacy support. As such syscons(4) can not be enabled andthe use of a serial console is required.
59fb9ae87f