Release Notes for SUSE Linux Enterprise Server 11 Service Pack 2 for VMware

Btrfs is a copy-on-write (CoW) general purpose file system. Based on the CoW functionality, btrfs provides snapshoting. Beyond that data and metadata checksums improve the reliability of the file system. btrfs is highly scalable, but also supports online shrinking to adopt to real-life environments. On appropriate storage devices btrfs also supports the TRIM command.

Support

With SUSE Linux Enterprise 11 SP2, the btrfs file system joins ext3, reiserfs, xfs and ocfs2 as commercially supported file systems. Each file system offers disctinct advantages. While the installation default is ext3, we recommend xfs when maximizing data performance is desired, and btrfs as a root file system when snapshotting and rollback capabilities are required. Btrfs is supported as a root file system (i.e. the file system for the operating system) across all architectures of SUSE Linux Enterprise 11 SP2. Customers are advised to use the YaST partitioner (or AutoYaST) to build their systems: YaST will prepare the btrfs file system for use with subvolumes and snapshots. Snapshots will be automatically enabled for the root file system using SUSE's snapper infrastructure. For more information about snapper, its integration into ZYpp and YaST, and the YaST snapper module, see the SUSE Linux Enterprise documentation.

Migration from "ext" File Systems to btrfs

Migration from existing "ext" file systems (ext2, ext3, ext4) is supported "offline" and "in place". Calling "btrfs-convert [device]" will convert the file system. This is an offline process, which needs at least 15% free space on the device, but is applied in place. Roll back: calling "btrfs-convert -r [device]" will roll back. Caveat: when rolling back, all data will be lost that has been added after the conversion into btrfs; in other words: the roll back is complete, not partial.

RAID

Btrfs is supported on top of MD (multiple devices) and DM (device mapper) configurations. Please use the YaST partitioner to achieve a proper setup. Multivolume/RAID with btrfs is not supported yet and will be enabled with a future maintenance update.

Future Plans

Online Check and Repair Functionality

Check and repair functionality ("scrub") is available as part of the btrfs command line tools. "Scrub" is aimed to verify data and metadata assuming the tree structures are fine. "Scrub" can (and should) be run periodically on a mounted file system: it runs as a background process during normal operation.

The tool "fsck.btrfs" tool will soon be available in the SUSE Linux Enterprise update repositories.

Capacity Planning

If you are planning to use btrfs with its snapshot capability, it is advisable to reserve twice as much disk space than the standard storage proposal. This is automatically done by the YaST2 partitioner for the root file system.

Hard Link Limitation

In order to provide a more robust file system, btrfs incorporates back references for all file names, eliminating the classic "lost+found" directory added during recovery. A temporary limitation of this approach affects the number of hard links in a single directory that link to the same file. The limitation is dynamic based on the length of the file names used. A realistic average is approximately 150 hard links. When using 255 character file names, the limit is 14 links. We intend to raise the limitation to a more usable limit of 65535 links in a future maintenance update.

Other Limitations

At the moment, btrfs is not supported as a seed device.

For More Information

For more information about btrfs, see the SUSE Linux Enterprise 11 documentation.

Tomcat6 and related packages are fully supported on the Intel/AMD x86 (32bit), AMD64/Intel64, IBM POWER, and IBM System z architectures.

The SELinux subsystem is supported. Arbitrary SELinux policies running on SLES are not supported, though. Customers and Partners who have an interest in using SELinux in their solutions, are encouraged to contact SUSE to evaluate the level of support that is needed, and how support and services for the specific SELinux policies will be granted.

The Linux Kernel swaps out rarely accessed memory pages in order to use freed memory pages as cache to speed up file system operations, for instance during backup operations.

Some Enterprise applications, such as SAP solutions, use large amounts of memory for accelerated access to business data. Parts of this memory are very seldom accessed. When a user request needs to access paged out memory, the response time is poor. It is even worse, when a SAP solution running on Java incurs a Java garbage collection. The system starts heavy page-in activity (disc I/O) and incurs poor response time for an extended period of time.

The pagecache_limit feature is a technology preview in SUSE Linux Enterprise Server 11 SP1 and SP2, and only supported for SUSE Linux Enterprise Server for SAP Applications 11 SP1 and later.

For SUSE Linux Enterprise Server 12 we expect an upstream solution based on Control Groups.

Hot-add memory is currently only supported on the following hardware:

If your specific machine is not listed, please call SUSE support to confirm whether or not your machine has been successfully tested. Also, regularly check our maintenance update information, which will explicitly mention the general availability of this feature.

Restriction on using IBM eHCA InfiniBand adapters in conjunction with hot-add memory on IBM System p:

The current eHCA Device Driver will prevent dynamic memory operations on a partition as long as the driver is loaded. If the driver is unloaded prior to the operation and then loaded again afterwards, adapter initialization may fail. A Partition Shutdown / Activate sequence on the HMC may be needed to recover from this situation.

The Internet Storage Naming Service (iSNS) package is by design suitable for secure internal networks only. SUSE will continue to work with the community on improving security.

It is possible to run SUSE Linux Enterprise Server 11 on a shared read-only root file system. A read-only root setup consists of the read-only root file system, a scratch and a state file system. The /etc/rwtab file defines which files and directories on the read-only root file system are replaced by which files on the state and scratch file systems for each system instance.

The readonlyroot kernel command line option enables read-only root mode; the state= and scratch= kernel command line options determine the devices on which the state and scratch file systems are located.

In order to set up a system with a read-only root file system, set up a scratch file system, set up a file system to use for storing persistent per-instance state, adjust /etc/rwtab as needed, add the appropriate kernel command line options to your boot loader configuration, replace /etc/mtab with a symlink to /proc/mounts as described below, and (re)boot the system.

To replace /etc/mtab with the appropriate symlinks, call:

ln -sf /proc/mounts /etc/mtab

See the rwtab(5) manual page for further details and http://www.redbooks.ibm.com/abstracts/redp4322.html for limitations on System z.

Lustre 2.1 builds of kernel modules by 3rd parties needed kernel modifications of the previous shipped SUSE Kernel, and thus breaking the support chain.

To allow the build of kernel modules for Lustre 2.1 by 3rd parties without breaking the support chain for the SUSE Kernel, the needed hooks for Lustre were added to the shipped kernel.

This change does not include Lustre modules or packages, nor support.

On systems with large memory, frequent access to the Translation Lookaside Buffer (TLB) may slow down the system significantly.

Transparent huge pages thus are of most use on systems with very large (128GB or more) memory, and help to drive performance. In SUSE Linux Enterprise, THP is enabled by default where it is expected to give a performance boost to a large number of workloads.

There are cases where THP may regress performance, particularly when under memory pressure due to pages being reclaimed in an effort to promote to huge pages. It is also possible that performance will suffer on CPUs with a limited number of huge page TLB entries for workloads that sparsely reference large amounts of memory. If necessary, THP can be disabled via the sysfs file "/sys/kernel/mm/transparent_hugepage/enabled", which accepts one of the values "always", "madvise", or "never".

To disable THP via sysfs and confirm it is disabled, do the following as root:

echo never > /sys/kernel/mm/transparent_hugepage/enabled
cat /sys/kernel/mm/transparent_hugepage/enabled 
always madvise [never]

Recent servers provide a small non-volatile storage area. A recent pstore feature can save kernel crashes there, if the pstore file system gets mounted as follows:

mkdir /dev/pstore
mount -t pstore - /dev/pstore

The crash can then be examined on the next reboot. By default, the kernel is not able to determine the non-volatile storage area (unless UEFI is used). This is because this information is exposed via APEI (ACPI Platform Error Interface) tables, which are not parsed by default.

Beside the fact that the BIOS has to export the relevant information, the kernel needs the following boot parameter:

apei_enable

Then the kernel is able to detect the non-volatile storage area.

CFS bandwidth control can be used to set a hard limit on the CPU usage of a group or VM. With this it becomes possible to limit a group's or VM's maximum CPU usage to say 0.5CPU or 2CPUs. The bandwidth is specified as quota/period where a group will not be allowed to consume more than 'quota' milliseconds worth of CPU time in every 'period' interval. If a group or VM's CPU usage exceeds the limit, it will be throttled until the time its quota gets refreshed.

Right now only the memory usage with respect to a cgroup can be controlled. The swap space used by the tasks within a cgroup cannot be controlled.

Cgroup swap control provides a way to control the memory+swap usage with respect to a cgroup. This feature can be exploited by passing the kernel boot parameter "swapaccount=1" and can be disabled by passing "swapaccount=0". If the feature is enabled, an interface by name "memory.memsw.limit_in_bytes" will be present under the memory controller. The value assigned to this control interface should include the limit for the total memory+swap usage limit for that particular cgroup.

To take advantage of the Real Time extension the extension must be at the same version as the base SUSE Linux Enterprise Server. An updated version for SUSE Linux Enterprise Real Time extension is provided later after the release of SUSE Linux Enterprise Server.

In SUSE Linux Enterprise 11 Service Pack 1 and earlier releases, the Tomcat servlet container has been provided as part of the Software Development Kit. We learned that our customers demand full runtime support for this infrastructure.

Starting with SUSE Linux Enterprise Server 11 Service Pack2, Tomcat6 and related packages are part of the Server product. Based on customer and partner feedback we fully support this on the architectures Intel/AMD x86 (32bit), AMD64/Intel64, IBM POWER, IBM System z.

The following packages are affected: tomcat6, tomcat6-servlet-2_5-api, tomcat6-webapps, tomcat6-docs-webapp, tomcat6-admin-webapps, tomcat6-lib, tomcat6-jsp-2_1-api, libtcnative-1-0, apache2-mod_jk, jakarta-taglibs-standard, jakarta-commons-collections, jakarta-commons-dbcp, jakarta-commons-pool, jakarta-commons-httpclient3, jakarta-commons-beanutils, jakarta-commons-codec, jakarta-commons-collections, jakarta-commons-collections-tomcat5, jakarta-commons-daemon, jakarta-commons-dbcp-tomcat5, jakarta-commons-digester, jakarta-commons-discovery, jakarta-commons-el, jakarta-commons-fileupload, jakarta-commons-io, jakarta-commons-lang, jakarta-commons-launcher, jakarta-commons-logging, jakarta-commons-modeler, jakarta-commons-pool-tomcat5, jakarta-commons-validator, tomcat6-javadoc, jakarta-taglibs-standard-javadoc, jakarta-commons-*-javadoc, tomcat_apparmor, ant, ant-junit, ant-trax, and mx4j.

With the changes in the printer market that have happened since SUSE Linux Enterprise 11 SP1 was released, it is highly probable that parts of HPLIP are outdated.

The version upgrade to HPLIP version 3.11.5 keeps SUSE Linux Enterprise 11 SP2 up-to-date regarding to HP printer and all-in-one devices.

Having multiple domains residing in virtual hosts, only the first domain can be served for secure Web browsing. Other domains are prevented from using secure communications. Many servers in virtual hosting environments circumvent this by using a wrong certificate, which causes the browser to warn the user.

An extension to TLS called Server Name Indication (SNI) addresses this issue by sending the name of the virtual domain as part of the TLS negotiation.This enables the server to "switch" to the correct virtual domain early and present the browser with the certificate containing the correct CN. Apache version 2.2.12 has server support for SNI extension.

With SP2 LDAP clients default to a stricter default setting for certificate verification. For that to work correctly, the CA certificate used to sign the LDAP server's certificate needs to be available on the client's file system. The YaST LDAP client module was enhanced to provide a way to download the CA certificate from a URL or to configure a file or directory from which the LDAP client should load the CA certificate.

When updating from an SP1 system, this settings is not enabled automatically. To enable it, start the YaST LDAP client configuration wizard and configure a valid CA certificate to verify your LDAP server's certificate. Then make sure that /etc/openldap/ldap.conf either contains no TLS_REQCERT setting or set it to "demand" or "hard".

For details, see the ldap.conf(5) man page.

There is no single standard for Access Control Lists (ACL) in Linux and Unix beyond the simple user/group/others-rwx flags. One option for finer control are so-called "Draft Posix ACLs", which were never formally standardized by Posix. Another is the NFSv4 ACLs, which were designed to be part of the NFSv4 network file system with the goal of making something that provided reasonable compatibility between Posix systems (like Linux) and WIN32 systems (like Microsoft Windows).

It turned out that NFSv4 ACLs are not sufficient to correctly implement Draft Posix ACLs. Thus no attempt has been made to map ACL accesses on an NFSv4 client (using e.g. setfacl ).

Therefore, when using NFSv4, Draft Posix ACLs cannot be used even in emulation. NFSv4 ACLs need to be used directly; i.e., while setfacl can work on NFSv3, it cannot work on NFSv4.

To allow NFSv4 ACLs to be used on an NFSv4 file system we provide the "nfs4-acl-tools" package, which contains:

These operate in a generally similar way to getfacl and setfacl for examining and modifying NFSv4 ACLs.

Note: This can only be effective if the file system on the NFS server provides full support for NFSv4 ACLs. Any limitation imposed by the server will affect programs running on the client in that some particular combinations of Access Control Entries (ACEs) may not be possible.

A future release of Linux may support "richacls", which are designed to provide access to NFSv4 ACLs in a way that is more integrated with other file sytems. If and when these become available, we will need to transition from using nfs4-acl-tools towards support tools coming with "richacls".

The System Security Services Daemon (sssd) was added to SLE 11 SP2 to provide an alternative method to retrieve user and group information from LDAP directories and to perform authentication through LDAP or Kerberos. It is provided as an alternative to the nss_ldap and pam_ldap (or pam_krb5) Modules. Compared to those modules sssd offers some advantages:

With SLE 11 SP2 the YaST2 ldap-client module can be used to setup sssd for LDAP (and/or Kerberos) Authentication. The YaST to ldap-client module can also be used to switch from a nss_ldap/pam_ldap based setup to sssd and back.

Some additional notes:

After a new installation of SLES 11 SP2 this feature is enabled, if the mail system is configured with using amavis.

When updating from SLES 11 SP1 this feature must be enabled by editing /etc/mail/spamassassin/v312.pre . The comment sign # must be removed from the last line. Before:

#loadplugin Mail::SpamAssassin::Plugin::DKIM

After:

loadplugin Mail::SpamAssassin::Plugin::DKIM

openSSH now makes use of cryptographic hardware acceleration. As a result, the transfer of large quantities of data through a ssh connection is considerably faster. As an additional benefit, the CPU of the system with cryptographic hardware will see a significant reduction in load.

The common PAM configuration files (/etc/pam.d/common-*) are now created and managed with pam-config.

In addition to AppArmor, SELinux capabilities have been added to SUSE Linux Enterprise Server. While these capabilities are not enabled by default, customers can run SELinux with SUSE Linux Enterprise Server if they choose to.

What does SELinux enablement mean?

By enabling SELinux in our codebase, we add community code to offer customers the option to use SELinux without replacing significant parts of the distribution.

SUSE Linux Enterprise Server 11 comes with support for Trusted Computing technology. To enable your system's TPM chip, make sure that the "security chip" option in your BIOS is selected. TPM support is entirely passive, meaning that measurements are being performed, but no action is taken based on any TPM-related activity. TPM chips manufactured by Infineon, NSC and Atmel are supported, in addition to the virtual TPM device for Xen.

The corresponding kernel drivers are not loaded automatically. To do so, enter:

find /lib/modules -type f -name "tpm*.ko"

and load the kernel modules for your system manually or via MODULES_LOADED_ON_BOOT in /etc/sysconfig/kernel.

If your TPM chip with taken ownership is configured in Linux and available for use, you may read PCRs from /sys/devices/*/*/pcrs.

The tpm-tools package contains utilities to administer your TPM chip, and the trousers package provides tcsd—the daemon that allows userland programs to communicate with the TPM driver in the Linux kernel. tcsd can be enabled as a service for the runlevels of your choice.

To implement a trusted ("measured") boot path, use the package trustedgrub instead of the grub package as your bootloader. The trustedgrub bootloader does not display any graphical representation of a boot menu for informational reasons.

Our kernel is compiled with support for Linux File System Capabilities. This is disabled by default. The feature can be enabled by adding file_caps=1 as kernel boot option.

The YaST module "FCoE Client Configuration" is a tool to configure FCoE capable network interfaces. During the installation workflow the FCoE configuration can be started on 'Disk Activation' screen. The FCoE interface can be configured and the connected disk will be available for installation.

The FCoE configuration should be automatically offered if the BIOS has activated FCoE. If not, add "withfcoe=1" to the kernel command line.

This feature addresses the issue that eth0 does not map to em1 (as labeled on server chassis), when a server has multiple network adapters.

This issue is solved for Dell hardware, which has the corresponding BIOS support, by renaming onboard network interfaces to em[1234], which maps to Embedded NIC[1234] as labeled on server chassis. (em stands for ethernet-on-motherboard.)

The renaming will be done by using the biosdevname utility.

biosdevname is automatically installed and used if YaST2 detects hardware suitable to be used with biosdevname. biosdevname can be disabled during installation by using "biosdevname=0" on the kernel commandline. The usage of biosdevname can be enforced on every hardware with "biosdevname=1". If the BIOS has no support, no network interface names are renamed.

The SUSE Linux Enterprise Server now supports the use of parallel NFS as a client. This allows access to NFS in a scalable way.

SUSE Linux Enterprise Server 11 SP2 supports "system containers" with the LXC (LinuX Container) infrastructure to achieve soft partitioning of large physical systems. In this infrastructure, instances of SLES 11 SP2 run within a host instance of SLES 11 SP2. In other words: other than with a hypervisor, all instances share one Linux Kernel, every instance has its own "init" process though.

While the host system has access to the guest instances and their filesystem, the guest instances do not see the host or the other guests other than via network or explicitly share storage (if configured). Thus, Linux Containers should not be used as the primary or only security measure around or inbetween highly secure environments.

For more information about LXC, see the SUSE Linux Enterprise 11 documentation.

LXC now comes with support for network gateway detection. This feature will prevent a container from starting, if the network configuration setup of the container is incorrect. For instance, you must make sure that the network address of the container is within the host ip range, if it was set up as brigded on host. You might need to specify the netmask of the container network address (using the syntax "lxc.network.ipv4 = X.Y.Z.T / cidr") if the netmask is not the network class default netmask).

When using DHCP to assign a container network address, ensure "lxc.network.ipv4 = 0.0.0.0" is used in your configuration template.

Previously a container would have been started but the network would not have been working properly. Now a container will refuse to start, and print an error message stating that the gateway could not be set up. For containers created before this update we recommend running rcnetwork restart to reestablish a container network connection.

YaST wagon offers to perform the on-line migration from SLES 11 SP1 to SLES 11 SP2. Wagon provides two possibilities to perform the migration:

To make sure that your system has all security patches installed and therefore is not vulnerable, either run the full migration, or make sure to run on-line update after performing the minimal migration.

Support for SCSI tapes in yast for interactive handling. Udev rules are adjusted to make changes persistent in case of reboot.

This new ixgbe driver version adds support for the following devices: 82599EB 10 Gigabit Network Connection 82599EB 10 Gigabit TN Network Connection X540-AT2 Ethernet Controller 10 Gigabit 82599 10 Gigabit Dual Port Backplane Connection with FCoE 82599 10 Gigabit Dual port Network Connection with FCoE 82599EB 10 Gigabit SFP+ Network Connection 82599 10 Gigabit Dual Port Network Connection

This is a new virtual function driver added for SR-IOV support with the Intel ixgbe 10 Gigabit devices.

Added support for the following devices: 82580 Gigabit Network Connection 82580 Gigabit Fiber Network Connection 82580 Gigabit Backplane Connection 82580 Gigabit SFP Connection 82580 Gigabit Network Connection I350 Gigabit Network Connection I350 Gigabit Fiber Network Connection I350 Gigabit Backplane Connection I350 Gigabit Connection 82576 Gigabit Network Connection 82580 Gigabit Fiber Network Connection

This Service Pack adds SR-IOV support for the Intel(R) I350 devices.

This new version of the e1000e driver adds support for the following devices: 82567LM Gigabit Network Connection 82574L Gigabit Network Connection 82567V-3 Gigabit Network Connection 82579LM Gigabit Network Connection 82579V Gigabit Network Connection 82583V Gigabit Network Connection 82567V-4 Gigabit Network Connection 82566DC-2 Gigabit Network Connection

The Chelsio T4 adapter with the cxgb4, cxgb4i, and iw_cxgb4 drivers support 10Ge NIC, iSCSI, and iWARP functions respectively. IBM Power systems support Enhanced Error Handling (EEH) and Hotplug removal. When hotplug operations are performed on a running adapter, a crash, hang or failure to remove the adapter may occur.

A permanent solution in the device drivers is being investigated but may not be ready in time for GM. Until the maintenance driver is released, it is necessary to unload all of the cxgb4, cxgb4i, and iw_cxgb4 drivers prior to running any of the hotplug commands such as 'drmgr -r'.

Once the drivers are unloaded, the adapter can be hotplug moved to another partition or removed from the system as necessary.

The bna 3.0.2.2 driver supports all Brocade FC/FCOE adapters. Below is a list of adapter models with corresponding PCIIDs:

PCIID			Model 

1657:0014:1657:0014	1010 10Gbps single port CNA - LL 
1657:0014:1657:0014	1020 10Gbps dual port CNA - LL 
1657:0014:1657:0014	1007 10Gbps dual port CNA - LL 
1657:0014:1657:0014	1741 10Gbps dual port CNA - LL 

1657:0022:1657:0023	1860 10Gbps CNA - LL 
1657:0022:1657:0023	1860 10Gbps NIC - LL

Firmware Download: The latest Firmware package for 3.0.2.2 bna driver can be found at: http://www.brocade.com/services-support/drivers-downloads/adapters/Linux.page and then click following respective util package link: Version Link v3.0.2.0 Linux Adapter Firmware package for RHEL 6.2, SLES 11SP2

Configuration and Management utility download: The latest driver configuration & management utility for 3.0.2.2 bna driver can be found at http://www.brocade.com/services-support/drivers-downloads/adapters/Linux.page and then click version v3.0.2.0, "Linux Adapter Util package for RHEL 6.2, SLES 11SP2".

Documentation: The latest Administration's Guide, Installation and Reference Manual, Troubleshooting Guide, and Release Notes for the corresponding out-of-box driver can be found at http://www.brocade.com/services-support/drivers-downloads/adapters/Linux.page and use the following inbox and out-of-box driver version mapping to find the corresponding documentation:

Inbox Version		Out-of-box Version  
 
v3.0.2.2		v3.0.0.0

Support: For general product and support info, go to the Brocade website at http://www.brocade.com/services-support/index.page .

For QLogic 82XX based CNA, update the firmware to the latest from the QLogic website or whatever is recommended by the OEM in case you are running 4.7.x FW version.

SP2 scans for the functions on a PCI device in a new way using ARI. This can cause some of the functions on the Broadcom 57712 adapter to be missing after upgrading to SP2.

Contact your system vendor to receive the latest firmware for the 57712 adapter that resolves this issue. Alternatively, upgrading to kernel 3.0.26 and adding the boot parameter 'pci=noari' will allow all the functions on the 57712 adapter to become visible under SLES 11 SP2.

Rapid Storage Technology enterprise 3.0 for the Linux allows users to install/boot to Intel BIOS initialized SW RAID. New features supported with this version includes Disk Coercion, Email Alerting, RAID5 Xor, Hot Spare Disk, Read Patrol, On Line Capacity Expansion, RAID Level Migrations, Check Pointing, smart alerting , Expanded Stripe Size, SAS & SATA drive roaming, and Auto Rebuild.

This service pack includes the proper upstream md raid userspace (mdadm/mdmon) software raid utilities to ensure full feature functionality including install/boot support.

The Intel 6 Series/C200 Series Chipset Platform Controller Hub (PCH) for mainstream Servers requires the isci driver for the Intel SAS Controller Unit (SCU).

This service pack includes the official SCU "isci.c" driver to ensure full SCU support including install/boot support.

Instructions to setup iSCSI initiator over DCB:

The iSCSI initiator will automatically set packet priority based on the DCB iSCSI application priority in effect on the egress interface. The priority is set once at session establishment. If the DCB priority is to be changed, it will be necessary to reestablish the session to apply the changed priority.

Because the priority is set based on the egress interface, the priority cannot be set until the egress interface is known. This means that by default, the initial TCP packets to establish the session will not have a priority set, but subsequent packets will. If a session is bound to an interface, then the priority associated with that interface will be used even for the initial packet exchange. If a routing change results in a different egress interface being used, the same priority will continue to be used unless or until the session is re-established.

It is specifically recommended to bind to a VLAN interface. This allows the DCB-iSCSI priority to be communicated in the VLAN header. Without a VLAN header to convey the priority, the priority will only affect packet scheduling within the host. Commands such as the following demonstrate binding to a VLAN interface:

iscsiadm -m iface -I iface3 --op=new
iscsiadm -m iface -I iface3 --op=update -n iface.net_ifacename -v eth3.3260

By binding to the interface, every packet will carry the correct priority.

Make sure that the app tlv for iSCSI is enabled on the system and that the switchport is configured to use iscsi-default cee map AND lldp iscsi-priority-bits 0x10 is set:

For example, to configure the switchport on Brocade:

no cee
cee iscsi-default
lldp iscsi-priority-bits 0x10

This sets iSCSI to use priority 4. Assuming that the host is willing (will accept DCB configuration from the switch), iSCSI should then operate at priority 4.

The following will set the app tlv in CEE mode from the host:

dcbtool sc ethX app:1 e:1 a:1 w:1 appcfg:10

To enable app tlv in IEEE mode from the host:

lldptool -T -i eth2 -V APP app=4,2,3260

Note that the 3260 above is the well-known port number for iSCSI. The iSCSI app priority is always communicated using the well-known port number and will be used even if iSCSI has been configured to operate on a non-standard port. A non-standard port number is never used to determine the iSCSI initiator priority.

There probably is a lot that could be said about DCB. It would probably simplify things to make some assumptions about how it will be used. For example, I expect that the DCB parameters will be nearly always managed from the switch, so perhaps the only real host configuration that should be needed is just turning on DCB. The rest of it probably just adds confusion.

FCoE target setup:

For more information, see http://www.open-fcoe.org .

Open-iSCSI support is added to the QLogic iSCSI qla4xxx driver in SUSE Linux Enterprise Server 11 Service Pack 2. Using iscsiadm the features supported for qla4xxx are:

For more details, see Open-iSCSI README at http://www.open-iscsi.org/docs/README .

Note: The IOCTL support in qla4xxx is dropped and hence QLogic Applications are not supported with this Inbox driver. This is being targeted for a future release. The qla4xxx driver compatible with QLogic Applications can also be obtained from the QLogic Web site.

Using bnx2fc driver for installation:

Broadcom's NetXtreme II 57712 device provides networking as well as storage functionality. Boot from SAN on this device is supported over FCoE network using bnx2fc driver. Add "withfcoe=1" to the boot option line. Since the DCBX protocol is offloaded and performed by the device firmware, 'dcb' feature should be turned off during installation when prompted.

Note that FCoE boot from SAN on Broadcom 10G devices is only supported using the bnx2fc driver. Boot from SAN using the software fcoe driver is not supported.

For detailed information, refer to "Broadcom NetXtreme II(tm) Network Adapter User Guide".

Using iSCSI Disks When Installing:

Note: The installer for SLES 11 SP2 now supports iscsi install using software iscsi method and native Broadcom offload method on Broadcom NetXtreme II devices.

To use Broadcom offload iSCSI during install, the iSCSI option ROM on the Broadcom device must be set to HBA mode. Refer to "iSCSI Boot Broadcom NetXtreme II(tm) Network Adapter User Guide" for detailed information on iSCSI install/boot for Broadcom devices.

To use software iSCSI install, disable HBA mode in the Broadcom iSCSI option ROM.

Storage Drivers:

Bnx2fc is a FCoE offload driver, that uses open-fcoe's stack and fcoeutils. Note that SLES 11 SP2 only supports offload FCoE on NetXtreme II 57712. Refer to Documentation/scsi/bnx2fc.txt in linux kernel source for the driver usage information.

The bfa 3.0.2.2 driver supports all Brocade FC/FCOE adapters. Below is a list of adapter models with corresponding PCIIDs:

PCIID		  	Model		 

1657:0013:1657:0014	425 4Gbps dual port FC HBA 
1657:0013:1657:0014	825 8Gbps PCIe dual port FC HBA 
1657:0013:103c:1742	HP 82B 8Gbps PCIedual port FC HBA 
1657:0013:103c:1744	HP 42B 4Gbps dual port FC HBA 
1657:0017:1657:0014	415 4Gbps single port FC HBA 
1657:0017:1657:0014	815 8Gbps single port FC HBA 
1657:0017:103c:1741	HP 41B 4Gbps single port FC HBA 
1657:0017:103c 1743	HP 81B 8Gbps single port FC HBA 
1657:0021:103c:1779	804 8Gbps FC HBA for HP Bladesystem c-class 
 
1657:0014:1657:0014	1010 10Gbps single port CNA - FCOE 
1657:0014:1657:0014	1020 10Gbps dual port CNA - FCOE 
1657:0014:1657:0014	1007 10Gbps dual port CNA - FCOE 
1657:0014:1657:0014	1741 10Gbps dual port CNA - FCOE 

1657:0022:1657:0024	1860 16Gbps FC HBA 
1657:0022:1657:0022	1860 10Gbps CNA - FCOE

Firmware Download: The latest Firmware package for the 3.0.2.2 bfa driver can be found at http://www.brocade.com/services-support/drivers-downloads/adapters/Linux.page , then click version v3.0.2.0, "Linux Adapter Firmware package for RHEL 6.2, SLES 11SP2".

Configuration and Management Utility Download: The latest driver configuration and management utility for 3.0.2.2 bfa driver can be found at http://www.brocade.com/services-support/drivers-downloads/adapters/Linux.page , then click version v3.0.2.0 "Linux Adapter Firmware package for RHEL 6.2, SLES 11SP2".

Documentation: The latest Administration's Guide, Installation and Reference Manual, Troubleshooting Guide, and Release Notes for the corresponding out-of-box driver can be found at http://www.brocade.com/services-support/drivers-downloads/adapters/Linux.page and use the following inbox and out-of-box driver version mapping to find the corresponding documentation:

Inbox Version		Out-of-box Version  
v3.0.2.2		v3.0.0.0

Support: For general product and support info, go to the Brocade website at http://www.brocade.com/services-support/index.page .

To solve this, upgrade the switch firmware to v6.4.3 or above.

USB 3.0 is the third major revision of the USB standard, which brings faster data transfer and increases power savings. More and more USB 3.0 consumer products are launched in market. Intel starts to support USB 3.0 in the Intel(R) 7 Series/C216 Chipset Family.

This SP introduces support for USB 3.0 by adding patches for xHCI (eXtensible Host Controller Interface), USB 3.0 hub support and USB 3.0 support for Intel(R) 7 Series/C216 Chipset Family.

The processor graphics is provided in the 2nd Generation Intel(R) Core™ i7/i5/i3 processor family.

This service pack adds support for the processor graphics in the 2nd Generation Intel(R) Core™ i7/i5/i3 processor family by updating the required kernel module, xserver, xf86-video-intel driver, Mesa and dri driver.

With SUSE Linux Enterprise 11 SP2 we introduce Linux Kernel 3.0. This kernel is a direct successor of the Linux kernel 2.6 series, thus all applications run without change. However, some applications or installation programs are broken and may check for version "2.6" literally, thus failing to accept the compatibility of our kernel.

We provide two mechanisms to encourage applications to recognize the kernel 3.0 in SUSE Linux Enterprise 11 SP2 as a Linux kernel 2.6 compatible system:

If you are running SAP applications, have a look at SAP Note #1310037 for more information on running SAP applications within a Kernel 2.6 compatibility environment.

Known Issues

To upgrade a PostgreSQL server installation from version 8.3 to 9.1, the database files need to be converted to the new version.

Newer versions of PostgreSQL come with the pg_upgrade tool that simplifies and speeds up the migration of a PostgreSQL installation to a new version. Formerly dump and restore was needed that was much slower.

pg_upgrade needs to have the server binaries of both versions available. To allow this, we had to change the way PostgreSQL is packaged as well as the naming of the packages, so that two or more versions of PostgreSQL can be installed in parallel.

Starting with version 9.1, PostgreSQL package names contain numbers indicating the major version. In PostgreSQL terms the major version consists of the first two components of the version number, i.e. 8.3, 8.4, 9.0, or 9.1. So, the packages for Postgresql 9.1 are named postgresql91, postgresql91-server, etc. Inside the packages the files were moved from their standard locations to a versioned location such as /usr/lib/postgresql83/bin or /usr/lib/postgresql91/bin to avoid file conflicts if packages are installed in parallel. The update-alternatives mechanism creates and maintains symbolic links that cause one version (by default the highest installed version) to re-appear in the standard locations. By default, database data are stored under /var/lib/pgsql/data on SUSE Linux.

The following preconditions have to be fulfilled before data migration can be started:

Upstream documentation about pg_upgrade including step by step instructions for performing a database migration can be found under file:///usr/share/doc/packages/postgresql91/html/pgupgrade.html (if the postgresql91-docs package is installed), or online under http://www.postgresql.org/docs/9.1/static/pgupgrade.html . NOTE: The online documentation starts with explaining how you can install PostgreSQL from the upstream sources (which is not necessary on SLE) and also uses other directory names ( /usr/local instead of the update-alternatives based path as described above).

For background information about the inner workings of pg_admin and a performance comparison with the old dump and restore method, see http://momjian.us/main/writings/pgsql/pg_upgrade.pdf .

For an automated upgrade from SLES 10 SP4 or SLES 11 SP1 using AutoYaST see the Deployment Guide, Part "Automated Installations". The Deployment Guide is part of the system documentation that comes with the product.

The online migration from SP1 to SP2 is supported via the "YaST wagon" module.

Online migration from SP1 to SP2 is not supported if debuginfo packages are installed.

To migrate the system to the Service Pack 2 level with zypper, proceed as follows:

Migration is supported from SUSE Linux Enterprise Server 10 SP4 via bootable media (incl. PXE boot).

There are supported ways to upgrade from SLES 10 GA and SPx or SLES 11 GA to SLES 11 SP2, which may require intermediate upgrade steps:

The upgrade or the automated migration from SLES 10 to SLES 11 SP2 may fail if the root file system of the machine is located on iSCSI because of missing boot options.

There are two approaches to solve it, if you are using AutoYaST (adjust IP addresses and hostnames according to your environment!):

With SUSE Linux Enterprise Server 11 the kernel RPMs are split in different parts:

SUSE Linux Enterprise Server uses tickless timers. This can be disabled by adding nohz=off as a boot option.

SUSE Linux Enterprise Server will no longer contain any development packages, with the exception of some core development packages necessary to compile kernel modules. Development packages are available in the SUSE Linux Enterprise Software Development Kit.

The man command now asks which manual page the user wants to see if manual pages with the same name exist in different sections. The user is expected to type the section number to make this manual page visible.

If you want to revert back to the previously used method, please set MAN_POSIXLY_CORRECT=1 in a shell initialization file such as ~/.bashrc.

The YaST LDAP Server module no longer stores the configuration of the LDAP Server in the file /etc/openldap/slapd.conf. It uses OpenLDAP's dynamic configuration backend, which stores the configuration in an LDAP database itself. That database consists of a set of .ldif files in the directory /etc/openldap/slapd.d. You should - usually - not need to access those files directly. To access the configuration you can either use the yast2-ldap-server module or any capable LDAP client (e.g., ldapmodify, ldapsearch, etc.). For details on the dynamic configuration of OpenLDAP, refer to the OpenLDAP Administration Guide.

This release of SUSE Linux Enterprise Server ships with AppArmor. The AppArmor intrusion prevention framework builds a firewall around your applications by limiting the access to files, directories, and POSIX capabilities to the minimum required for normal operation. AppArmor protection can be enabled via the AppArmor control panel, located in YaST under Security and Users. For detailed information about using AppArmor, see the documentation in /usr/share/doc/packages/apparmor-docs.

The AppArmor profiles included with SUSE Linux have been developed with our best efforts to reproduce how most users use their software. The profiles provided work unmodified for many users, but some users may find our profiles too restrictive for their environments.

If you discover that some of your applications do not function as you expected, you may need to use the AppArmor Update Profile Wizard in YaST (or use the aa-logprof(8) command line utility) to update your AppArmor profiles. Place all your profiles into learning mode with the following: aa-complain /etc/apparmor.d/*

When a program generates many complaints, the system's performance is degraded. To mitigate this, we recommend periodically running the Update Profile Wizard (or aa-logprof(8)) to update your profiles even if you choose to leave them in learning mode. This reduces the number of learning events logged to disk, which improves the performance of the system.

Note: Before updating, check the configuration of your boot loader to assure that it is not configured to modify any system areas (MBR, settings active partition or similar). This will reduce the amount of system areas that you need to restore after update.

Updating a system where an alternative boot loader (not grub) or an additional boot loader is installed in the MBR (Master Boot Record) might override the MBR and place grub as the primary boot loader into the system.

In this case, we recommend the following: First backup your data. Then either do a fresh installation and restore your data, or run the update nevertheless and restore the affected system areas (in particular, the MBR). It is always recommended to keep data separated from the system software. In other words, /home, /srv, and other volumes containing data should be on separate partitions, volume groups or logical volumes. The YaST partitioning module will propose doing this.

Other update strategies (except booting the install media) are safe if the boot loader is configured properly. But the other strategies are not available, if you update from SUSE Linux Enterprise Server 10.

During the upgrade to SUSE Linux Enterprise Server 11 MySQL is also upgraded to the latest version. To complete this migration you may have to upgrade your data as described in the MySQL documentation.

SuSEfirewall2 is enabled by default, which means you cannot log in from remote systems. This also interferes with network browsing and multicast applications, such as SLP and Samba ("Network Neighborhood"). You can fine-tune the firewall settings using YaST.

We have improved the network configuration: If you install SUSE Linux Enterprise Server 11 SP2 and configure Xen, you get a bridged setup through YaST.

However, if you upgrade from SUSE Linux Enterprise Server 10 SP4 to SUSE Linux Enterprise Server 11 SP2, the upgrade does not configure the bridged setup automatically.

To start the bridge proposal for networking, start the "YaST Control Center", choose "Virtualization", then "Install Hypervisor and Tools". Alternatively, call yast2 xen on the commandline.

The configuration of the LILO boot loader on the x86 and x86_64 architecture via YaST or AutoYaST is deprecated, and not supported anymore. For more information, see Novell TID 7003226 http://www.novell.com/support/documentLink.do?externalID=7003226.

SUSE Linux Enterprise Server 10 and SUSE Linux Enterprise Server 11 set net.ipv4.conf.all.rp_filter = 1 in /etc/sysctl.conf with the intention of enabling route path filtering. However, the kernel fails to enable routing path filtering, as intended, by default in these products.

Since SLES 11 SP1, this bug is fixed and most simple single-homed unicast server setups will not notice a change. But it may cause issues for applications that relied on reverse path filtering being disabled (e.g., multicast routing or multi-homed servers).

For more details, see http://ifup.org/2011/02/03/reverse-path-filter-rp_filter-by-example/.

Starting with SUSE Linux Enterprise Server 11 Service Pack 1 the configuration files for recompiling the kernel were moved into their own sub-package:

Updating from SUSE Linux Enterprise Server 11 SP 1 with AutoYaST is supported.

If there were two direct mounts with different timeouts configured, the second one was ignored and the first timeout value was used for both mount points.

AutoFS was patched to support individual timeout values for each direct mount.

Remote systems can now be served with xrdp. Windows clients are able to administer such servers.

Find the AppArmor Configuration module now in the "Security and Users" section of the YaST Control Center.

The YaST Repair Tool as available from the boot medium does not detect pseudo devices like /dev/btrfs and writes a warning about missing partitions instead.

You should skip the repair of such a device, because for such pseudo devices the availability of a partition is not expected.

Effective on 2009-01-13, provisional registrations have been disabled in the Novell Customer Center. Registering an instance of SUSE Linux Enterprise Server or Open Enterprise Server (OES) products now requires a valid, entitled activation code. Evaluation codes for reviews or proofs of concept can be obtained from the product pages and from the download pages on novell.com.

If a device is registered without a code at setup time, a provisional code is assigned to it by Novell Customer Center (NCC), and it will be entered in your NCC list of devices. No update repositories are assigned to the device at this time.

Once you are ready to assign a code to the device, start the YaST Novell Customer Center registration module and replace the un-entitled provisional code that NCC generated with the appropriate one to fully entitle the device and activate the related update repositories.

Operation under the Subscription Management Tool (SMT) package and registration proxy is not affected. Registration against SMT will assign codes automatically from your default pool in NCC until all entitlements have been assigned. Registering additional devices once the pool is depleted will result in the new device being assigned a provisional code (with local access to updates) The SMT server will notify the administrator that these new devices need to be entitled.

The minimal pattern provided in YaST's Software Selection dialog targets experienced customers and should be used as a base for your own specific software selections.

Do not expect a minimal pattern to provide a useful basis for your business needs without installing additional software.

This pattern does not include any dump or logging tools. To fully support your configuration, Novell Technical Services (NTS) will request installation of all tools needed for further analysis in case of a support request.

SPident is a tool to identify the Service Pack level of the current installation. On SUSE Linux Enterprise Server 11 GA, this tool has been replaced by the new SAM tool (package "suse-sam").

Intel's AES-NI is a new set of Single Instruction Multiple Data (SIMD) instructions that is introduced in Intel(R) processor since 2009. These instructions enable fast and secure data encryption and decryption, using the Advanced Encryption Standard (AES), defined by FIPS Publication number 197.

This service pack adds patches to OpenSSL to support Intel's AES-NI.

Problem (Abstract)

Java applications that use synchronization extensively might perform poorly on Linux systems that include the Completely Fair Scheduler. If you encounter this problem, there are two possible workarounds.

Symptom

You may observe extremely high CPU usage by your Java application and very slow progress through synchronized blocks. The application may appear to hang due to the slow progress.

Cause

The Completely Fair Scheduler (CFS) was adopted into the mainline Linux kernel as of release 2.6.23. The CFS algorithm is different from previous Linux releases. It might change the performance properties of some applications. In particular, CFS implements sched_yield() differently, making it more likely that a thread that yields will be given CPU time regardless. More information on CFS can be found here: "Multiprocessing with the Completely Fair Scheduler", http://www.ibm.com/developerworks/linux/library/l-cfs/?ca=dgrlnxw06CFC4Linux

The new behavior of sched_yield() might adversely affect the performance of synchronization in the IBM JVM.

Environment

This problem may affect IBM JDK 5.0 and 6.0 (all versions) running on Linux kernels that include the Completely Fair Scheduler, including Linux kernel 2.6.27 in SUSE Linux Enterprise Server 11.

Resolving the Problem

If you observe poor performance of your Java application, there are two possible workarounds:

You should not use these workarounds unless you are experiencing poor performance.

Simple database engines like Berkeley DB use memory mappings (mmap(2)) to manipulate database files. When the mapped memory is modified, those changes need to be written back to disk. In SUSE Linux Enterprise 11, the kernel includes modified mapped memory in its calculations for deciding when to start background writeback and when to throttle processes which modify additional memory. (In previous versions, mapped dirty pages were not accounted for and the amount of modified memory could exceed the overall limit defined.) This can lead to a decrease in performance; the fix is to increase the overall limit.

The maximum amount of dirty memory is 40% in SUSE Linux Enterprise 11 by default. This value is chosen for average workloads, so that enough memory remains available for other uses. The following settings may be relevant when tuning for database workloads:

These limits can be observed or modified with the sysctl utility (see sysctl(1) and sysctl.conf(5)).

The host protected area (HPA), is an area of a hard drive that is not normally visible to an operating system and usually used by system vendors to store recovery data. The Linux kernel offers mechanisms to make the host protected area visible to the OS.

SUSE Linux Enterprise defaults to the host protected area being visible.

In rare cases this might be an unwanted setup (for example when using some RAID solutions etc.). In that case please use the option "Keep HPA" during installation or boot an already installed system using this kernel parameter:

libata.ignore_hpa=0

Note: Changing handling of host protected area for already installed systems may lead to data loss and should therefore be used with cautions.

Future SUSE Linux Enterprise releases will change the default to honor the host protected area.

Setting permissions/ownership on multipath devices is becoming a problem as raw devices are now deprecated in the Linux kernel and database systems such as Oracle. Setting permissions on raw devices is pretty straightforward as you can write udev rules for that. Doing the same for multipath devices is challenging since all you have at the udev level is dm-X as device name, but the associated WWID is not known.

To set Permission/Ownership on Multipath Devices, please copy the file "/usr/share/doc/packages/device-mapper/12-dm-permissions.rules" to /etc/udev/rules.d and adopt it to your needs. This file has four parts for different device type: PLAIN DM, LVM, ENCRYPTED, MULTIPATH. Add the parameters suitable to your envinronment here. Changes to udev rules might only become active after a reboot of the system.

Some storage devices, e.g. IBM DS4K, require special handling for path failover and failback. In SUSE Linux Enterprise Server 10 SP2, dm layer served as hardware handler.

One drawback of this implementation was that the underlying SCSI layer did not know about the existence of the hardware handler. Hence, during device probing, SCSI would send I/O on the passive path, which would fail after a timeout and also print extraneous error messages in the console.

In SUSE Linux Enterprise Server 11, this problem is resolved by moving the hardware handler to the SCSI layer, hence the term SCSI Hardware Handler. These handlers are modules created under the SCSI directory in the Linux Kernel.

In SUSE Linux Enterprise Server 11, there are four SCSI Hardware Handlers: scsi_dh_alua, scsi_dh_rdac, scsi_dh_hp_sw, scsi_dh_emc.

These modules need to be included in the initrd image so that SCSI knows about the special handling during probe time itself.

To do so, carry out the following steps:

An iSCSI shared device should never be mounted directly on the local machine. In an OCFS2 environment, doing so causes all hardware to hard hang.

The system time of a guest will drift several seconds per day.

To maintain an accurate system time it is recommended to run ntpd in a guest. The ntpd daemon can be configured with the YaST "NTP Client" module. In addition to such a configuration, the following two variables must be set manually to "yes" in /etc/sysconfig/ntp:

NTPD_FORCE_SYNC_ON_STARTUP="yes"
NTPD_FORCE_SYNC_HWCLOCK_ON_STARTUP="yes"

SLES 11 SP2 has a newer block device driver, which presents all configured virtual disks as SCSI devices. Disks, which used to appear as /dev/hda in SLES 11 SP1 will from now on appear as /dev/sda.

The Windows Server Manager GUI allows to take snapshots of a Hyper-V guest. After a snapshot is taken the guest will fail to reboot. By default, the guest's root file system is referenced by the serial number of the virtual disk. This serial number changes with each snapshot. Since the guest expects the initial serial number, booting will fail.

The solution is to either delete all snapshots using the Windows GUI, or configure the guest to mount partitions by file system UUID. This change can be made with the YaST partitioner and boot loader configurator.

Installing a guest hosted on Windows 8 Server may fail when a large virtual disk image (larger than 50 GB) in .vhdx format is assigned to the guest. To workaround this issue use either virtual disk images with a fixed size, or create the dynamically sized disk image using Powershell.

This Service Pack will ensure support for the following new Intel processors:

Intel(R) Platforms based on Intel(R) Xeon(R) Processor E5-4600/2600/2400/1600 and Intel(R) C600 chipset product family will introduce PCI Express Gen3.

This Service Pack adds support for PCI Express Gen3 (ID-based Ordering, Latency Tolerance Reporting, Optimized Buffer Flush/Fill (OBFF)).

This Service Pack adds support for the following Intel(R) platforms:

Intel(R) TXT provides the solution of protecting IT infrastructure against software-based attacks within a server or PC at startup.

This Service Pack adds basic support for Intel(R) TXT by adding patches to the kernel and integrating tboot.

While the number of LUNs for a running system is virtually unlimited, we suggest not having more than 64 LUNs online while installing the system, to reduce the time to initialize and scan the devices and thus reduce the time to install the system in general.

IBM Power 7 systems running firmware 7.2.0 SP1 or later along with version 2.2.0.11-FP24 SP01 or later of the Virtual I/O Server and HMC v7r7.2.0 or later include support for long term suspension of logical partitions. Logical partitions can be suspended and resumed from the HMC. All I/O resources must be virtual I/O resources at the time of suspending. Once suspended, the memory and processor resources associated with the suspended logical partition are free to be used by other logical partitions.

SLES 11 SP2 has been enhanced to support logical partition suspend and resume.

The kernel is able to capture the most recent oops or panic report from the dmesg buffer into NVRAM, where it can be examined after reboot.

PowerVM release 7.4 includes a new memory optimization feature called Active Memory Deduplication. This feature applies to logical partitions which are assigned to an Active Memory Sharing (AMS) pool. With Active Memory Deduplication, the PowerVM Hypervisor automatically detects memory pages in the pool that have identical contents, and remaps those pages to a single physical page, freeing up the duplicate pages for other purposes in the AMS pool.

SLES 11 SP2 has been enhanced to provide the PowerVM Hypervisor with page hints to indicate which pages are good candidates for merging. This feature is automatically enabled in the kernel for AMS LPARs with Active Memory Deduplication enabled. Statistics on page merging is available through the amsstat utility.

The virtual fibre channel for IBM Power systems has been updated to support the 5729 PCIe 4-Port 8Gb FC adapter.

The ppc64-specific instruction tracing tool, ITrace, is no longer available.

The IBM Power Virtual Ethernet driver (ibmveth) has been updated with various performance enhancements, including support for IPv6 checksum offload.

A shared storage pool is a server based storage virtualization that is clustered and is an extension of existing storage virtualization on the Virtual I/O Sever for IBM Power systems. Support for shared storage pools requires the latest Virtual I/O Server software, which can be obtained from http://www14.software.ibm.com/webapp/set2/sas/f/vios/home.html .

SLES 11 SP2 adds multipath support for virtual disks backed by shared storage pools.

Previous versions of GCC limited the size of the TOC to 64kB. Options like -mminimal-toc and the linker automatic multiple TOC section support extended the effective size of the TOC, but some very large programs required source changes to break up large functions in order to compile and link.

PowerPC64 GCC now supports -mcmodel=small, -mcmodel=medium and -mcmodel=large. The latter two generate code for a 2G TOC. -mcmodel=medium optimizes accesses to local data but limits the total size of all data sections to 2G, in most cases giving a speed improvement over -mminimal-toc and may even give a speed improvement over the default -mcmodel=small. The linker supports mixing of object files compiled with any of these options.

All POWER3, POWER4, PPC970 and RS64–based models that were supported by SUSE Linux Enterprise Server 9 are no longer supported.

With SUSE Linux Enterprise Server 11 the bootfile DVD1/suseboot/inst64 can not be booted directly via network anymore, because its size is larger than 12MB. To load the installation kernel via network, copy the files yaboot.ibm, yaboot.cnf and inst64 from the DVD1/suseboot directory to the TFTP server. Rename the yaboot.cnf file to yaboot.conf. yaboot can also load config files for specific Ethernet MAC addresses. Use a name like yaboot.conf-01-23-45-ab-cd-ef to match a MAC address. An example yaboot.conf for TFTP booting looks like this:

default=sles11
timeout=100
image[64-bit]=inst64
    label=sles11
    append="quiet install=nfs://hostname/exported/sles11dir"

Huge Page Memory (16GB pages, enabled via HMC) is supported by the Linux kernel, but special kernel parameters must be used to enable this support. Boot with the parameters "hugepagesz=16G hugepages=N" in order to use the 16GB huge pages, where N is the number of 16GB pages assigned to the partition via the HMC. The number of 16GB huge pages available can not be changed once the partition is booted. Also, there are some restrictions if huge pages are assigned to a partition in combination with eHEA / eHCA adapters:

IBM eHEA Ethernet Adapter:

The eHEA module will fail to initialize any eHEA ports if huge pages are assigned to the partition and Huge Page kernel parameters are missing. Thus, no huge pages should be assigned to the partition during a network installation. To support huge pages after installation, the huge page kernel parameters need to be added to the boot loader configuration before huge pages are assigned to the partition.

IBM eHCA InfiniBand Adapter:

The current eHCA device driver is not compatible with huge pages. If huge pages are assigned to a partition, the device driver will fail to initialize any eHCA adapters assigned to the partition.

The installation on a vscsi client will fail with old versions of the AIX VIO server. Please upgrade the AIX VIO server to version 1.5.2.1-FP-11.1 or later.

After installing SLES 11 SP1 on an iSCSI target, the system boots properly, network is up and the iSCSI root device is found as expected. The install completes (firstboot part) as usual. However, at the end of firstboot, the network is shut down before the root file system is unmounted, leading to read failures accessing the root (iSCSI) device; the system hangs.

Solution: reboot the system.

Customers using SLES 9 or SLES 10 to serve Virtual SCSI to other LPARs, using the ibmvscsis driver, who wish to migrate from these releases, should consider migrating to the IBM Virtual I/O server. The IBM Virtual I/O server supports all the IBM PowerVM virtual I/O features and also provides integration with the Virtual I/O management capabilities of the HMC. It can be downloaded from: http://www14.software.ibm.com/webapp/set2/sas/f/vios/download/home.html

When using IBM Power Virtual Fibre Channel devices utilizing N-Port ID Virtualization, the Virtual I/O Server may need to be updated in order to function correctly. Linux requires VIOS 2.1, Fixpack 20.1, and the LinuxNPIV I-Fix for this feature to work properly. These updates can be downloaded from: http://www14.software.ibm.com/webapp/set2/sas/f/vios/home.html

When using virtual tape devices served by an AIX VIO server, the Virtual I/O Server may need to be updated in order to function correctly. The latest updates can be downloaded from: http://www14.software.ibm.com/webapp/set2/sas/f/vios/home.html

For more information about IBM Virtual I/O Server, see http://www14.software.ibm.com/webapp/set2/sas/f/vios/documentation/home.html.

The Chelsio hardware supports ~16K packet size (the exact value depends on the system configuration). It is recommended that you set the parameter MaxRecvDataSegmentLength in /etc/iscsid.conf to 8192.

For the cxgb3i driver to work properly, this parameter needs to be set to 8192.

In order to use the cxgb3i offload engine, the cxgb3i module needs to be loaded manually after open-scsi has been started.

For additional information, refer to /usr/src/linux/Documentation/scsi/cxgb3i.txt in the kernel source tree.

When attempting to netboot yaboot, users may see the following error message:

Can't claim memory for TFTP download (01800000 @ 01800000-04200000)

and the netboot will stop and immediately display the yaboot "boot:" prompt. Use the following steps to work around the problem.

If you do a remote installation in text mode, but want to connect to the machine later in graphical mode, be sure to set the default runlevel to 5 via YaST. Otherwise xdm/kdm/gdm might not be started.

To disable SDP on IBM hardware set SDP=no in openib.conf so that by default SDP is not loaded. After you have set this setting in openib.conf to 'no' run openibd restart or reboot the system for this setting to take effect.

If your system is configured as an NFS over RDMA server, the system may hang during a shutdown if a remote system has an active NFS over RDMA mount. To avoid this problem, prior to shutting down the system, run "openibd stop"; run it in the background, because the command will hang and otherwise block the console:

/etc/init.d/openibd stop &

A shutdown can now be run cleanly.

Note: the steps to configure and start NFS over RDMA are as follows:

Performance improvement through exploitation of new System z196 processor instructions by binutils and alternate GCC on the SDK. This feature will be active when the GNU assembler is invoked with -march=z196.

User space processes can delay I/O operations until all pending requests against the common I/O layer have been completed, eg. a user process wants to wait until a device is useable after a CP ATTACH command.

Updated version with several corrections: previous versions of libdfp exhibited minor bugs in printf_dfp and strtod[32|64|128], inconsistencies with POSIX with regard to classification functions, dfp header override include order problems, and missing classification function exports.

Fast shutdown and resume of Linux for System z in z/VM and LPAR.

Suspend to disk allows fast suspend (freeze) of a system and resume work where it stopped.

Btrfs is a copy-on-write (CoW) general purpose file system. Based on the CoW functionality, btrfs provides snapshoting. Beyond that data and metadata checksums improve the reliability of the file system. btrfs is highly scalable, but also supports online shrinking to adopt to real-life environments. On appropriate storage devices btrfs also supports the TRIM command.

Support

With SUSE Linux Enterprise 11 SP2, the btrfs file system joins ext3, reiserfs, xfs and ocfs2 as commercially supported file systems. Each file system offers disctinct advantages. While the installation default is ext3, we recommend xfs when maximizing data performance is desired, and btrfs as a root file system when snapshotting and rollback capabilities are required. Btrfs is supported as a root file system (i.e. the file system for the operating system) across all architectures of SUSE Linux Enterprise 11 SP2. Customers are advised to use the YaST partitioner (or AutoYaST) to build their systems: YaST will prepare the btrfs file system for use with subvolumes and snapshots. Snapshots will be automatically enabled for the root file system using SUSE's snapper infrastructure. For more information about snapper, its integration into ZYpp and YaST, and the YaST snapper module, see the SUSE Linux Enterprise documentation.

Migration from "ext" File Systems to btrfs

Migration from existing "ext" file systems (ext2, ext3, ext4) is supported "offline" and "in place". Calling "btrfs-convert [device]" will convert the file system. This is an offline process, which needs at least 15% free space on the device, but is applied in place. Roll back: calling "btrfs-convert -r [device]" will roll back. Caveat: when rolling back, all data will be lost that has been added after the conversion into btrfs; in other words: the roll back is complete, not partial.

RAID

Btrfs is supported on top of MD (multiple devices) and DM (device mapper) configurations. Please use the YaST partitioner to achieve a proper setup. Multivolume/RAID with btrfs is not supported yet and will be enabled with a future maintenance update.

Future Plans

Online Check and Repair Functionality

Check and repair functionality ("scrub") is available as part of the btrfs command line tools. "Scrub" is aimed to verify data and metadata assuming the tree structures are fine. "Scrub" can (and should) be run periodically on a mounted file system: it runs as a background process during normal operation.

The tool "fsck.btrfs" tool will soon be available in the SUSE Linux Enterprise update repositories.

Capacity Planning

If you are planning to use btrfs with its snapshot capability, it is advisable to reserve twice as much disk space than the standard storage proposal. This is automatically done by the YaST2 partitioner for the root file system.

Hard Link Limitation

In order to provide a more robust file system, btrfs incorporates back references for all file names, eliminating the classic "lost+found" directory added during recovery. A temporary limitation of this approach affects the number of hard links in a single directory that link to the same file. The limitation is dynamic based on the length of the file names used. A realistic average is approximately 150 hard links. When using 255 character file names, the limit is 14 links. We intend to raise the limitation to a more usable limit of 65535 links in a future maintenance update.

Other Limitations

At the moment, btrfs is not supported as a seed device.

For More Information

For more information about btrfs, see the SUSE Linux Enterprise 11 documentation.

Ensure all your logs go through permanent local storage or the network. For example, putting /var/log on a tmpfs file system means that they will not survive a system boot. This limits your ability, and the one of SUSE, to analyze log files in case of a support request.

Exceptions are configurations where you save log files via syslog on a remote log server and permanently store the log files on the log server. Note: Not all log files can be redirected to a remote log server (e.g. yast-logs, boot logs and others); if these files are not available, support may be very hard to effectively diagnose issues and support the system.

The libica package contains the interface library routines used by IBM modules to interface with IBM Cryptographic Hardware (ICA). Starting with SLES 11 SP1, libica is provided in the s390x distribution in three flavors of packages: libica-1_3_9, libica-2_0_2, and libica-2_1_0 providing libica versions 1.3.9, 2.0.2, and 2.1.0 respectively.

libica 1.3.9 is provided for compatibility reasons with legacy hardware present e.g. in the ppc64 architecture. For s390x users it is always recommended to use the new libica 2.1.0 library since it supports all newer s390x hardware, larger key sizes and is backwards compatible with any ICA device driver in the s390x architecture.

You may choose to continue using libica 1.3.9 or 2.0.2 if you do not have newer Cryptographic hardware to exploit or wish continue using custom applications that do not support the libica 2.1.0 library yet. Both openCryptoki and openssl-ibmca, the two main exploiters for the libica interface, are provided in SLES 11 SP2 to support the newer libica 2.1.0 library.

YaST writes the MAC address for layer 2 devices only if they are of the card_types:

Per intent YaST does not write the MAC address for devices of the types:

The script modify_resolvconf is removed in favor of a more versatile script called netconfig. This new script handles specific network settings from multiple sources more flexibly and transparently. See the documentation and man-page of netconfig for more information.

Memory cgroups are now disabled for machines where they cause memory exhaustion and crashes. Namely, X86 32-bit systems with PAE support and more than 8G in any memory node have this feature disabled.

The mcelog package logs and parses/translates Machine Check Exceptions (MCE) on hardware errors (also including memory errors). Formerly this has been done by a cron job executed hourly. Now hardware errors are immediately processed by an mcelog daemon.

However, the mcelog service is not enabled by default resulting in memory and CPU errors also not being logged by default. In addition, mcelog has a new feature to also handle predictive bad page offlining and automatic core offlining when cache errors happen.

The service can either be enabled via the YaST runlevel editor or via commandline with:

chkconfig mcelog on
rcmcelog start

If you are not satisfied with locale system defaults, change the settings in ~/.i18n. Entries in ~/.i18n override system defaults from /etc/sysconfig/language. Use the same variable names but without the RC_ namespace prefixes; for example, use LANG instead of RC_LANG. For more information about locales in general, see "Language and Country-Specific Settings" in the Administration Guide.

kdump is useful, if the kernel is crashing or otherwise misbehaving and a kernel core dump needs to be captured for analysis.

Use YaST (System+Kernel Kdump) to configure your environment.

When kdump is configured through YaST with ssh/scp as target and the target system is SUSE Linux Enterprise, then enable authentication using either of the following ways:

Java packages are changed to follow the JPackage Standard (http://www.jpackage.org/). For more information, see the documentation in /usr/share/doc/packages/jpackage-utils/.

To avoid the mail-flood caused by cron status messages, the default value of SEND_MAIL_ON_NO_ERROR in /etc/sysconfig/cron is now set to "no" for new installations. Even with this setting to "no", cron data output will still be send to the MAILTO address, as documented in the cron manpage.

In the update case it is recommended to set these values according to your needs.