Driver Disk for Emulex Be2net 11.1.196.6 – For XenServer 7.2

Who Should Install this Driver Disk?

Customers running Citrix XenServer 7.2.0 who use Emulex’s Be2net driver and wish to use the latest version of the following:

Driver Module Version
Be2net 11.1.196.6

Issues Resolved In this Driver Disk

Includes general enhancements and bug fixes.

Note: If your device has been branded by your OEM, please ensure that you consult them regarding the currently supported driver/firmware versions.

Installing the Driver Disk

Customers should use XenServer Command Line Interface (CLI) to install this update. Once the driver has been installed, the server must be restarted. As with any software update, Citrix advises customers to back up their data before applying this driver disk.

Please note that the attachment to this article is a zip file. It contains both the drive disk ISO mentioned below, and the source code for the driver. The zip file should be unzipped (to produce the driver disk ISO image), before carrying out the steps below. The source code file is not necessary for driver disk installation: it is provided to fulfill licensing obligations.

Installing as Part of a Clean XenServer Installation

  1. Once you have selected your keyboard layout at the first installer prompt, you will be presented with a welcome screen. At this point, press F9 on your keyboard, and insert the CD with the driver disk in it, or use one of the other methods such as installation over the network.

    Users should note that if installation over HTTP or FTP is to be used, the ISO image must be unpacked at that location (i.e. the installer expects to find the contents of the ISO at that network location, not the ISO itself).

  2. The installer will proceed to attempt to load the driver. If this is successful, you can continue with the installation as normal. Near the end of the installation, you will be prompted to re-insert the driver disk (otherwise known as a XenServer supplemental pack) so that the driver can be installed onto disk. You must re-supply the driver disk at this point. Failure to do so will mean that the installation will not contain the new drivers. After this step, no further action is required.

If the installer fails to load the new driver from the driver disk, it is likely to be because an earlier version of the driver has already been loaded. In general, this is because a hardware component is present that is supported by the version of the driver that ships as part of XenServer (even if another component is present that requires a newer version of the driver). To avoid the existing driver being loaded, use the following procedure.

  1. Reboot the host, leaving the XenServer installation CD-ROM in the drive.
  2. At the boot: prompt, type:

    shell

  3. You will now be presented with a command prompt. Type the following:

    rmmod Be2net

    If this succeeds (i.e. there are no error messages printed), the installer’s versions of the drivers have been unloaded. If error messages are presented, it is likely that other drivers depend on one or more of the drivers you are attempting to unload. If this is the case, please contact Citrix Technical Support.

  4. Type

    exit

    or press Control+D on your keyboard, to return to the installer.

  5. Use the procedure described above to provide the driver disk to the installer, which should now load correctly.

Installing the Update by using the xe Command Line Interface

Perform the following steps to install the update remotely using the xe CLI:

  1. Download the update to a known location on a computer that has XenCenter installed.
  2. Upload the update:

    xe update-upload file-name=driver-emulex-be2net-11.1.196.6.iso

    Note: The UUID of the update is returned when the upload completes.

  3. Apply the update:

    xe update-apply uuid=0e15fa69-d2c4-4f8b-b35c-ca7ec421d574

  4. To complete the installation, restart the host. This ensures that the driver loads correctly.

Files

Update Files

Component Details
Filename driver-emulex-be2net-11.1.196.6.iso
File sha256 a0343c7d10f81cb0b310955afe64c13d46cb3645651e7c5f03ae9536fc27b275
Source Filename driver-emulex-be2net-11.1.196.6-sources.iso
Source File sha256 01a97928652cbf68760a7274a43d2da4bc675ba04fd099f975e45192f94dca16
Zip Filename driver-emulex-be2net-11.1.196.6.zip
Zip File sha256 5eb0387b8ae6b460ebd64e3a2faf0a0b99992cead6ad58eb5ea73b61e50ecc85
Size of the Zip file 0.24 MB

RPMs Provided

RPM Name
emulex-be2net-11.1.196.6-2.x86_64.rpm

More Information

If you experience any difficulties, contact Citrix Technical Support.

For information on how to build driver disks, refer to Citrix XenServer ® 7.2 Supplemental Packs and the DDK Guide.

Related:

Driver Disk for Qlogic qede 8.30.13.0 – For XenServer 7.2

Who Should Install this Driver Disk?

Customers running Citrix XenServer 7.2.0 who use qlogic’s qede driver and wish to use the latest version of the following:

Driver Module Version
qede 8.30.13.0

Issues Resolved In this Driver Disk

Includes general enhancements and bug fixes.

Note: If your device has been branded by your OEM, please ensure that you consult them regarding the currently supported driver/firmware versions.

Installing the Driver Disk

Customers should use XenServer Command Line Interface (CLI) to install this update. Once the driver has been installed, the server must be restarted. As with any software update, Citrix advises customers to back up their data before applying this driver disk.

Please note that the attachment to this article is a zip file. It contains both the drive disk ISO mentioned below, and the source code for the driver. The zip file should be unzipped (to produce the driver disk ISO image), before carrying out the steps below. The source code file is not necessary for driver disk installation: it is provided to fulfill licensing obligations.

Installing as Part of a Clean XenServer Installation

  1. Once you have selected your keyboard layout at the first installer prompt, you will be presented with a welcome screen. At this point, press F9 on your keyboard, and insert the CD with the driver disk in it, or use one of the other methods such as installation over the network.

    Users should note that if installation over HTTP or FTP is to be used, the ISO image must be unpacked at that location (i.e. the installer expects to find the contents of the ISO at that network location, not the ISO itself).

  2. The installer will proceed to attempt to load the driver. If this is successful, you can continue with the installation as normal. Near the end of the installation, you will be prompted to re-insert the driver disk (otherwise known as a XenServer supplemental pack) so that the driver can be installed onto disk. You must re-supply the driver disk at this point. Failure to do so will mean that the installation will not contain the new drivers. After this step, no further action is required.

If the installer fails to load the new driver from the driver disk, it is likely to be because an earlier version of the driver has already been loaded. In general, this is because a hardware component is present that is supported by the version of the driver that ships as part of XenServer (even if another component is present that requires a newer version of the driver). To avoid the existing driver being loaded, use the following procedure.

  1. Reboot the host, leaving the XenServer installation CD-ROM in the drive.
  2. At the boot: prompt, type:

    shell

  3. You will now be presented with a command prompt. Type the following:

    rmmod qede

    If this succeeds (i.e. there are no error messages printed), the installer’s versions of the drivers have been unloaded. If error messages are presented, it is likely that other drivers depend on one or more of the drivers you are attempting to unload. If this is the case, please contact Citrix Technical Support.

  4. Type

    exit

    or press Control+D on your keyboard, to return to the installer.

  5. Use the procedure described above to provide the driver disk to the installer, which should now load correctly.

Installing the Update by using the xe Command Line Interface

Perform the following steps to install the update remotely using the xe CLI:

  1. Download the update to a known location on a computer that has XenCenter installed.
  2. Upload the update:

    xe update-upload file-name=driver-qlogic-fastlinq-8.30.13.0.iso

    Note: The UUID of the update is returned when the upload completes.

  3. Apply the update:

    xe update-apply uuid=24097536-ba7d-400c-80fa-411739ccb5be

  4. To complete the installation, restart the host. This ensures that the driver loads correctly.

Files

Update Files

Component Details
Filename driver-qlogic-fastlinq-8.30.13.0.iso
File sha256 69d92d0bd3cb2067b00074501d235e8e03c9cda6f3e32ad07e503d791d35c698
Source Filename driver-qlogic-fastlinq-8.30.13.0-sources.iso
Source File sha256 cff9f5f036688bb93abbf1c34c368dafe5ea817e2a827fcc16b5839556324d86
Zip Filename driver-qlogic-fastlinq-8.30.13.0.zip
Zip File sha256 6f84191596fdbfec94cfa98e65aa37a49629e39c53de4f66d35a59ee33c9b1be
Size of the Zip file 11.16 MB

RPMs Provided

RPM Name
qlogic-fastlinq-8.30.13.0-1.x86_64.rpm

More Information

If you experience any difficulties, contact Citrix Technical Support.

For information on how to build driver disks, refer to Citrix XenServer ® 7.2 Supplemental Packs and the DDK Guide.

Related:

How to remove “Ghost” NIC devices from Windows

Unidesk 2.X releases before 2.8.3: After Desktops have been backed up and restored to a new CachePoint, the NIC doesn’t come up. Even after restarting to apply changes and rediscovering the disks, the driver does not appear to install correctly. This can also happen during layer changes on a desktop.

For all versions of Unidesk & App Layering: The underlying problem is that every new instance of a VMXNet3 network device is detected by Windows as a completely separate device. Unlike E1000-compatible devices, which re-use the same device nodes, every new MAC address on a VMXNet3, even if it’s in the same virtual PCI location, causes a new device detection. So these devices accumulate in the registry as no-longer-present devices. When Unidesk is attempting to merge multiple VMXNet3 device nodes from multiple layer sources, we sometimes fail to merge them properly. This can result in Windows not being able to bring up any network interface until the excess nonpresent device records are removed.

VMware is aware of the VMXNet3 proliferation problem. They may recommend an MS patch referenced in this VMware KB: http://kb.vmware.com/kb/1020078. However, Unidesk has observed this patch to break the VMXNet3 driver when included in an OS layer update, so we do not currently recommend it. If you apply this patch in an OS layer version, you may wind up with desktops with a non-functional VMXNet3 device, and uninstalling it from the device manager does not actually remove it.

Related:

How to configure a GSLB Service Group in NetScaler 12.0 57.19

Tradução automática

Эта статья была переведена автоматической системой перевода и не был рассмотрен людьми. Citrix обеспечивает автоматический перевод с целью расширения доступа для поддержки контента; Однако, автоматически переведенные статьи могут может содержать ошибки. Citrix не несет ответственности за несоответствия, ошибки, или повреждения, возникшие в результате использования автоматически переведенных статей.

Related:

  • No Related Posts

Citrix NetScaler Application Delivery Controller and NetScaler Gateway Multiple Security Updates

These vulnerabilities have been addressed in the following versions of Citrix NetScaler ADC and NetScaler Gateway:

  • Citrix NetScaler ADC and NetScaler Gateway version 12.0 Build 57.19 and later
  • Citrix NetScaler ADC and NetScaler Gateway version 11.1 Build 56.15 and later
  • Citrix NetScaler ADC and NetScaler Gateway version 11.0 Build 71.18 and later
  • Citrix NetScaler ADC and NetScaler Gateway version 10.5 Build 67.10 and later

Citrix recommends that affected customers upgrade their NetScaler appliances to a version of the appliance firmware that contains a fix for these issues as soon as their patching schedule allows.

These versions are available on the Citrix website at the following addresses:

https://www.citrix.com/downloads/netscaler-adc/

https://www.citrix.com/downloads/netscaler-gateway/

Related:

Http/1.1 Internal Server Error 43550 with AAA session timeout and re-authentication

Tradução automática

Эта статья была переведена автоматической системой перевода и не был рассмотрен людьми. Citrix обеспечивает автоматический перевод с целью расширения доступа для поддержки контента; Однако, автоматически переведенные статьи могут может содержать ошибки. Citrix не несет ответственности за несоответствия, ошибки, или повреждения, возникшие в результате использования автоматически переведенных статей.

Related:

  • No Related Posts

NetScaler Drops a DNS UDP Response Larger than 512 Bytes

Tradução automática

Эта статья была переведена автоматической системой перевода и не был рассмотрен людьми. Citrix обеспечивает автоматический перевод с целью расширения доступа для поддержки контента; Однако, автоматически переведенные статьи могут может содержать ошибки. Citrix не несет ответственности за несоответствия, ошибки, или повреждения, возникшие в результате использования автоматически переведенных статей.

Related:

  • No Related Posts

Receiver for Windows 4.9LTSR/4.10 – Citrix HDX Engine Crash When Connecting to Linux VDA

There are two possible workarounds for this issue:

1. If the Receiver is a clean install and you see the partial grey screen issue, reducing the number of virtual channels on the Receiver side ( so that they are less than or equal to 32 in number ) would resolve the problem. To reduce the virtual channels, perform the following steps:

1. Exit Receiver from System tray.

2. Open Registry on the client machine.

3. Browse to the following key:

HKEY_LOCAL_MACHINESOFTWAREWOW6432NodeCitrixICA ClientEngineConfigurationAdvancedModulesICA 3.0

Modify the VirtualDriver key on the right hand pane and remove the entries that are not needed in your environment. Some candidates are:

vd3d (Desktop Composition Redirection – deprecated)

Framehawk (recommended only for extreme WAN scenarios and where server resource usage is not an issue)

ZL_FONT (Zero Latency, only supported up to XA 6.5)

ZLC (Zero Latency, only supported up to XA 6.5)

For example, removing vd3d and Framehawk, following would be the contents of VirtualDriver key:

Thinwire3.0, ClientDrive, ClientPrinterQueue, ClientPrinterPort, Clipboard, ClientComm, ClientAudio, LicenseHandler, TWI,ZL_FONT,ZLC,SmartCard,Multimedia,ICACTL,SSPI,TwainRdr,UserExperience,VDTUI,DVCAdapter,GenericUSB, Flash,FlashV2,MobileReceiver,Sensor,Multitouch,VDIME,WebPageRedirection,PortForward,NSAP

2. If the Receiver is an upgrade from 4.9 to 4.10, uninstalling the receiver and performing a clean install (instead of upgrade) will resolve the issue. This is because the clean install has a different ordering of Virtual Channels compared to an upgrade.

Citrix team is currently working on enhancing the Linux VDA to support 64 Virtual channels. This support is expected to be included in the future version of Linux VDA.

Related:

  • No Related Posts

Citrix App Layering Appliance or VMs Spontaneously Lose IP Addresses

If you are using DHCP reservations to assign your IP addressing for your appliance VMs, any prob;lems with DHCP can break your addressing. For ninstance, if the DHCP server on your local subnet becomes unresponsive when your address lease expires, you will lose your IP address without even needing to reboot. Or if your DHCP server changes the range it’s allowed to lease, or even if it gives your address to another machine, you may lose networking.

The solution is, if you can’t completely trust your DHCP reservations, to set a fixed address directly on the appliance VM. Login as the “administrator” account through the VM console or SSH and set the networking configuration there.

In addition to checking from the “administrator” configuration menu, you can see whether your appliance is using DHCP by checking /var/log/messages for events from dhclient:

Feb 19 07:28:19 localhost dhclient[999]: DHCPREQUEST on eth0 to 128.104.155.41 port 67 (xid=0x426f83d6)

Feb 19 07:28:19 localhost dhclient[999]: DHCPACK from 128.104.155.41 (xid=0x426f83d6)

Feb 19 07:28:21 localhost dhclient[999]: bound to 10.128.101.251 — renewal in 120621 seconds.

Errors would look more like this:

Feb 25 06:01:26 localhost dhclient[935]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 15 (xid=0x469ee39c)

Feb 25 06:01:41 localhost dhclient[935]: No DHCPOFFERS received.

Related:

Policies with GSLB Wildcard Location expressions not getting a hit on build 11.1-53.11 and above

Policies with GSLB Wildcard Location expressions not getting a hit on build 11.1-53.11 and above. For example, if we have a policy configured with Location Wildcard expression “North America.US.*.*.*.*” :

User-added image


and a request comes from Source IP with location as “North America.US.Illinois.*.Chicago.*” (as per the location database installed on NetScaler), then it will not match the wildcard expression and the policy will not get a hit.

User-added image


However, if you configure a policy with exact match, i.e. with Location Expression “North America.US.Illinois.*.Chicago.*”or on the basis of IP, it will work :

User-added image


The policy will also get a hit if the request comes from an IP which falls under “North America.US.*.*.*.*” as it would be an exact match and not wildcard match. For example :

User-added image

Related: