7022995: Accessing All Open “Reflection Workspace” Objects in VBA Macro Code

Option Explicit

'Returns a Collection object that contains all open Reflection Frame objects

Function GetAllFrames() As Collection

Dim Frames As New Collection

Dim rApp As Attachmate_Reflection_Objects_Framework.ApplicationObject

On Error Resume Next

'By default, all Reflection Application objects will have the

'"AutomationServerName" of "Reflection Workspace".

'So, this method of discovering all currently-running Application

'objects works as long as you have not used another program

'that changes the default value on these to something else.

Do

Set rApp = GetObject("Reflection Workspace")

If Err = 0 Then

Frames.Add rApp.GetObject("Frame")

rApp.AutomationServerName = "already got this one"

Else

Err.Clear

Exit Do

End If

Loop

'Reset back to the original AutomationServerName...

Do

Set rApp = GetObject("already got this one")

If Err = 0 Then

rApp.AutomationServerName = "Reflection Workspace"

Else

Err.Clear

Exit Do

End If

Loop

Set GetAllFrames = Frames

End Function

'Returns a Collection object that contains all open Views

'in all Open Reflection Frame objects.

Function GetAllViews() As Collection

Dim Frames As Collection

Dim Views As New Collection

Dim i As Long

Dim f As Frame

Set Frames = GetAllFrames()

For Each f In Frames

If f.ViewCount <> 0 Then

For i = 1 To f.ViewCount

Views.Add f.View(i)

Next

End If

Next

Set GetAllViews = Views

End Function

'test...

Sub ReportAllViewTitles()

Dim Views As Collection

Dim v As View

Set Views = GetAllViews()

For Each v In Views

Debug.Print v.titleText

Next

End Sub

Related:

  • No Related Posts

7023078: Security Vulnerability: “L1 Terminal Fault” (L1TF) ??? Hypervisor Information (CVE-2018-3620, CVE-2018-3646, XSA-273).

Full mitigation for this issue requires a combination of hardware and software changes. Depending on the guest type, software changes may be required at both the Hypervisor and guest level.

Updated Intel microcode (provided through your hardware / BIOS vendor or by SUSE) introduces a new feature called “flush_l1d”. Hypervisors and bare-metal kernels use this feature to flush the L1 data cache during operations which may be susceptible to data leakage (e.g. when switching between VMs in Hypervisor environments).

Software mitigations exist for the Linux Kernel and for Hypervisors. These mitigations include support for new CPU features, passing these features to guests, and support for enabling/disabling/tuning the mitigations. Recommended mitigations vary depending on the environment.

For the Linux kernel (on both bare metal and virtual machines) L1TF mitigation is controlled through the “l1tf” kernel boot parameter. For complete information on this parameter, see TID 7023077.

KVM

For KVM host environments, mitigation can be achieved through L1D cache flushes, and/or disabling Extended Page Tables (EPT) and Simultaneous MultiThreading (SMT).

The L1D cache flush behavior is controlled through the “kvm-intel.vmentry_l1d_flush” kernel command line option:

kvm-intel.vmentry_l1d_flush=always

The L1D cache is flushed on every VMENTER.

kvm-intel.vmentry_l1d_flush=cond

The L1D cache is flushed on VMENTER only when there can be leak of host memory between VMEXIT and VMENTER. This could still leak some host data, like address space layout.

kvm-intel.vmentry_l1d_flush=never

Disables the L1D cache flush mitigation.

The default setting here is “cond”.

The l1tf “full” setting overrides the settings of this configuration variable.


L1TF can be used to bypass Extended Page Tables (EPT). To mitigate this risk, it is possible to disable EPT and use shadow pages instead. This mitigation is available through the “kvm-intel.enable_ept” option:
kvm-intel.enable_ept=0

The Extended Page tables support is switched off.
As shadow pages are much less performant than EPT, SUSE recommends leaving EPT enabled, and use L1D cache flush and SMT tuning for full mitigation.


To eliminate the risk of untrusted processes or guests exploiting this vulnerability on a sibling hyper-thread, Simultaneous MultiThreading (SMT) can be disabled completely.

SMT can be controlled through kernel boot command line parameters, or on-the-fly through sysfs:

On the kernel boot command line:

nosmt

SMT is disabled, but can be later reenabled in the system.

nosmt=force

SMT is disabled, and can not be reenabled in the system.

If this option is not passed, SMT is enabled. Any SMT options used with the “l1tf” kernel parameter option overrides this “nosmt” option.


SMT can also be controlled through sysfs:

/sys/devices/system/cpu/smt/control

This file allows to read the current control state and allows to disable or (re)enable SMT.

Possible states are:

on

SMT is supported and enabled.

off

SMT is supported, but disabled. Only primary SMT threads can be onlined.

forceoff

SMT is supported, but disabled. Further control is not possible.

notsupported

SMT is not supported.

Potential values that can be written into this file:

on

off

forceoff

/sys/devices/system/cpu/smt/active

This file contains the state of SMT, if it is enabled and active, where active means that multiple threads run on 1 core.

Xen

For Xen hypervisor environments, mitigation is enabled by default and varies based on guest type. Manual adjustment of the “smt=” parameter is recommended, but the remaining parameters are best left at default values.A description of all relevant parameters are provided in the event any changes are necessary.

PV guests achieve mitigation at the Xen Hypervisor level. If a PV guest attempts to write an L1TF-vulnerable PTE, the hypervisor will force shadow mode and prevent the vulnerability. PV guests which fail to switch to shadow mode (e.g. due to a memory shortage at the hypervisor level) are intentionally crashed.

pv-l1tf=[ <bool>, dom0=<bool>, domu=<bool> ]

By default, pv-l1tf is enabled for DomU environments and, for stability and performance reasons, disabled for Dom0.

HVM guests achieve mitigation through a combination of L1D flushes, and disabling SMT.

spec-ctrl=l1d-flush=<bool>

This parameter determines whether or not the Xen hypervisor performs L1D flushes on VMEntry. Regardless of this setting, this feature is virtualized and passed to HVM guests for in-guest mitigation.

smt=<bool>
This parameter can be used to enable/disable SMT from the hypervisor. Xen environments hosting any untrusted HVM guests, or guests not under the full control of the host admin, should either disable SMT (through BIOS or smt=<bool> means), or ensure HVM guests use shadow mode (hap=0) in order to fully mitigate L1TF. It is also possible to reduce the risk of L1TF through the use of CPU pinning, custom CPU pools and/or soft-offlining of some hyper-threads.
These approaches are beyond the scope of this TID, but are documented in the standard Xen documentation.

WARNING – The combination of Meltdown mitigation (KPTI) and shadow mode on hardware which supports PCID can result in a severe performance degradation.

NOTE – Efforts are ongoing to implement scheduling improvements that allow hyper-thread siblings to be restricted to threads from a single guest. This will reduce the exposure of L1TF, and the requirement to disable SMT in many environments.

Related:

  • No Related Posts

7022995: Enumerating All Open “Reflection Workspace” Objects in VBA Macro Code

Option Explicit

‘Returns a Collection object that contains all open Reflection Frame objects

Function GetAllFrames() As Collection

Dim Frames As New Collection

Dim rApp As Attachmate_Reflection_Objects_Framework.ApplicationObject

On Error Resume Next

‘By default, all Reflection Application objects will have the

‘”AutomationServerName” of “Reflection Workspace”.

‘So, this method of discovering all currently-running Application

‘objects works as long as you have not used another program

‘that changes the default value on these to something else.

Do

Set rApp = GetObject(“Reflection Workspace”)

If Err = 0 Then

Frames.Add rApp.GetObject(“Frame”)

rApp.AutomationServerName = “already got this one”

Else

Err.Clear

Exit Do

End If

Loop

‘Reset back to the original AutomationServerName…

Do

Set rApp = GetObject(“already got this one”)

If Err = 0 Then

rApp.AutomationServerName = “Reflection Workspace”

Else

Err.Clear

Exit Do

End If

Loop

Set GetAllFrames = Frames

End Function

‘Returns a Collection object that contains all open Views

‘in all Open Reflection Frame objects.

Function GetAllViews() As Collection

Dim Frames As Collection

Dim Views As New Collection

Dim i As Long

Dim f As Frame

Set Frames = GetAllFrames()

For Each f In Frames

If f.ViewCount <> 0 Then

For i = 1 To f.ViewCount

Views.Add f.View(i)

Next

End If

Next

Set GetAllViews = Views

End Function

‘test…

Sub ReportAllViewTitles()

Dim Views As Collection

Dim v As View

Set Views = GetAllViews()

For Each v In Views

Debug.Print v.titleText

Next

End Sub

Related:

  • No Related Posts

Citrix XenServer Security Update for CVE-2018-3639

Customers wishing to expose the new host firmware functionality to their guest VMs should install both the Citrix XenServer hotfixes and updated host firmware or BIOS code. The locations of the Citrix XenServer hotfixes are listed below; Citrix recommends following your hardware supplier’s guidance for firmware updates.

Citrix XenServer 7.4: CTX235133 – https://support.citrix.com/article/CTX235133

Citrix XenServer 7.3: CTX235132 – https://support.citrix.com/article/CTX235132

Citrix XenServer 7.1 LTSR CU1: CTX235131 – https://support.citrix.com/article/CTX235131

Citrix XenServer 7.0: CTX235130 – https://support.citrix.com/article/CTX235130

Note that, in line with previous issues that were not vulnerabilities in Citrix XenServer, mitigations are not available for versions 6.x of Citrix XenServer.

Related:

  • No Related Posts

How to get Windows I/O driver updates on XenServer 7.0 and later

Windows Updates

If you are running Windows VMs on XenServer, you can get the Windows I/O driver updates automatically, provided:

  • You are running XenServer Enterprise Edition, or have access to XenServer through XenApp/XenDesktop entitlement
  • Your VM was created with XenServer 7.0 or higher
  • You have installed XenServer Tools issued with XenServer 7.0 or higher
  • Windows Update is enabled within the VM
  • The Windows VM has access to the Internet

Microsoft Windows checks and downloads Windows I/O driver updates as part of its regular scheduled update process.

Note: If you would like to review the Windows I/O Driver updates before they are automatically installed on the VMs, you can redirect the updates to an internal web server. For more information, see section 7.3.3 Managing Automatic Updates in the XenServer Virtual Machine User’s Guide.

Management Agent Updates

If you choose not to use Windows Updates or your VMs can’t receive Windows I/O driver updates through Windows Updates, you can receive and install these updates through the Management Agent, provided:

  • You are running XenServer Enterprise Edition, or have access to XenServer through XenApp/XenDesktop entitlement
  • Your VM was created with XenServer 7.0 or higher
  • You have installed XenServer Tools issued with XenServer 7.0 or higher
  • The Windows VM has access to the Internet

You can configure the Management Agent to update the Windows I/O drivers by using the Citrix XenServer Management Agent Setup wizard. This capability is disabled by default. For more information, see XenServer Virtual Machine User’s Guide.

If you use the Management Agent to install Windows I/O driver updates on your VM, ensure that Windows Updates are disabled for the VM.

Hotfixes

Windows I/O drivers are periodically rolled up into hotfixes. If you are running XenServer Standard Edition, you must apply updates to your Windows drivers from hotfixes.

To apply these drivers, install the hotfix on your XenServer host and use the updated guest_tools.iso to reinstall the XenServer Tools in your Windows VMs.

Related:

  • No Related Posts

7018463: Upgrade SLES11 Xen DomU to SLES12

1. Select “New” at the top left corner of the Virtual Machine Manager


2. Choose “I need to upgrade an existing operating system” from the given options.

3. After selecting the DomU on the next screen and choosing the SLES12 installation media, select the “Upgrade” button.

4. (if needed) If the Xen guest is still powered on, the following dialogue box will be presented:

Once the guest is shut off, the upgrade can then be started by selecting the “Upgrade” button again.

Related:

  • No Related Posts

Retired Feature: VMPR for XenServer 6.2.0

Information

A selected number of features are being retired or deprecated in XenServer v6.2.0. Some features will be re-architected for current and emerging requirements while others will be superseded by best-of-breed products in an extended third-party environment. This will result in a superior product and platform for the emerging needs of all our customers.

The Virtual Machine Protection and Recovery (VMPR) feature is being retired within this release. Note that the Snapshot capability remains in XenServer.

Retired Features

  • A retired feature is no longer available in XenServer v6.2.0

  • The XenServer upgrade process will notify the user before commencing

  • XenCenter supports these features on earlier versions of XenServer

Background

The VMPR feature enables administrators to create snapshot and archival policies for regularly scheduled snapshots to help protect against data loss in case of a VM failure. Limitations of VMPR such as the usage of snapshots, lack of de-duplication support do not fulfill the backup and restoration requirements of customers.

Third-Party Alternatives

Enterprise-level backup solutions are available from vendors such as Quadric Software, SEP, and PHD Virtual. There are also a number of free third-party options.

More Information

Related:

  • No Related Posts

FAQ: Can we use XenCenter to connect to Xenserver on SDX?

Question:

===

Can I use XenCenter to manage/view/console access to XenServer on SDX?

Answer:

===

The use of XenCenter to monitor/console/etc to XenServer on SDX is not supported and changes made from XenCenter can cause the SVM to crash or abnormal issues. The SVM expects to be the only entity that can make changes to the XenServer and any changes outside of the SVM can cause serious problems, whose resolution can even require a factory reset of the entire SDX to recover from.

It can still be used for viewing purpose (using commands) but not for any configuration changes. Always use SVM to make any config changes for SDX appliance.

NOTE: Because the use of XenCenter is not supported on SDX, the Management IP on the XenServer is NOT configured during SDX install and if configured, is removed during upgrades. This is by design.

Related:

  • No Related Posts

Recommended XenMobile Scalability and performance specification document

Understanding the scale of your XenMobile infrastructure plays a significant role in how you decide to deploy and configure XenMobile. This article contains data from scalability tests and guidance on determining infrastructure requirements for performance and scalability for small- to large-scale, on-premises XenMobile enterprise deployments.

Scalability is defined here in terms of the ability of devices already enrolled in the deployment to reconnect to the deployment at the same time.

  • Scalability is defined as the maximum number of devices enrolled in the deployment.
  • Login Rate is defined maximum rate at which existing devices can reconnect to the deployment.

The data in this article are derived from testing on deployments ranging in size from 10,000 to 75,000 devices. The tests comprised mobile device using known workloads.

All testing was done on XenMobile Enterprise edition.

Testing was done using the NetScaler Gateway 8200. NetScaler appliance with similar or greater capacity can be expected to produce similar or greater scalability and performance.

This table summarizes the scalability test results:

Scalability Up to 75,000 devices
Login rate Reconnection rate of existing users Up to 9,375 devices per hour
Configuration NetScaler Gateway MPX 8200
XenMobile Enterprise Edition XenMobile Server 7-node cluster
Database Microsoft SQL Server external database

This table provides scalability test results for deployment device populations and hardware configurations tested.

Number of devices

12,500

30,000

60,000

75,000

Reconnection rate of existing devices per hour

1,250

3,750

7,500

9,375

XenMobile Server – mode

Standalone

Cluster

Cluster

Cluster

XenMobile Server – cluster

N/A

3

5

7

XenMobile Server – virtual appliance

Memory = 8 GB RAM

vCPUs = 4

Memory = 16 GB RAM

vCPUs = 6

Memory = 24 GB RAM

vCPUs = 8

Memory = 24 GB RAM

vCPUs = 8

Active Directory

Memory = 4 GB RAM

vCPUs = 2

Memory = 8 GB RAM

vCPUs = 4

Memory = 16 GB RAM

vCPUs = 4

Memory = 16 GB RAM

vCPUs = 4

Microsoft SQL Server external database

Memory = 8 GB RAM

vCPUs = 4

Memory = 16 GB RAM

vCPUs = 8

Memory = 24 GB RAM

vCPUs = 16

Memory = 24 GB RAM

vCPUs = 16

These tables summarize the test profile used derive the data in this article:

Active Directory Configuration Profile used
Users 100,000
Groups 200,000
Levels of nesting 5

XenMobile Server Configuration Total Per user
Policies 20 20
Apps 270 50
Public app 200 0
MDX 50 30
Web and SaaS 20 20
Actions 50
Delivery groups 20
Active Directory groups per delivery group 10

SQL
Number of databases 1

Related:

  • No Related Posts

Power Settings in XenServer: C-states, Turbo and CPU Frequency Scaling

This article explains changes introduced in XenServer 6.5 to the handling of power settings and describes how users with specific needs can change the configuration.

XenServer’s default power settings are optimal for most users, so do not normally need to be modified.

By default, XenServer 6.5 and later has the following power settings.

For Intel processors:

  • Use all available C-states regardless of BIOS settings

  • Use the “performance” CPU frequency governor

  • Use frequency scaling and Turbo mode as controlled by the BIOS settings

For AMD processors:

  • Use the BIOS settings to know which C-states are supported

  • Use the more power-friendly “ondemand” CPU frequency governor

  • Use frequency scaling and Turbo mode as controlled by the BIOS settings

It is recommended to use XenServer’s default configuration and to enable OS-controlled frequency scaling and Turbo mode in the BIOS.

C-states

For Intel processors, XenServer 6.5 and later uses all the available C-states regardless of the BIOS C-state settings.

In previous versions of XenServer, Xen used information from the BIOS to know which C-states the processor supported. In XenServer 6.5 and later, that information from the BIOS is not used for Intel processors by default. This means that enabling or disabling C-states and C1E in the BIOS has no effect for Intel processors, unlike in previous releases.

Note: For AMD processors, the C-state configuration remains the same as for previous versions of XenServer. Changing C-state settings in the BIOS does have an effect for AMD processors.

XenServer 6.5 and later use Xen Project Hypervisor 4.4’s new means of enumerating and using C-states for newer Intel processors. Xen Project Hypervisor 4.4 comes preloaded with the C-states and performance characteristics of each processor family (like Sandy Bridge, Haswell, etc). It chooses the correct information at boot based on the processor used. This improves performance because Xen can make more accurate decisions about which C-state to use. For example, C1 and C1E are treated as two separate states which gives Xen more flexibility in the choice of C-state. Modern CPUs can transition between C-states very quickly so the use of deep C-states has minimal performance impact but provides great potential for power saving.

Falling back to use of BIOS C-state settings

In order to revert to the C-state configuration for Intel processors that was used by previous versions of XenServer, use the following command in dom0:

/opt/xensource/libexec/xen-cmdline –set-xen mwait-idle=false

A reboot is required for this change to take effect. After this, controlling C-states in the BIOS will have an effect on XenServer. This is not a recommended configuration as it is likely to lead to reduced performance.

To go back to the default configuration, use the following and reboot:

/opt/xensource/libexec/xen-cmdline –delete-xen mwait-idle

Exploiting Turbo mode

Using all the available C-states gives the processor most thermal headroom to enter Turbo mode. Hence the default configuration that uses all available C-states should give the best performance for processors supporting a Turbo mode.

For maximum performance, it is recommended that Turbo mode is enabled in the BIOS.

To determine whether Turbo mode is enabled, use the following command in dom0:

# xenpm get-cpufreq-para | fgrep turboturbo mode : enabled

To verify that Turbo mode is being used stress the CPU in a VM and check that the CPU frequency is higher than the rated value:

# grep "model name" /proc/cpuinfomodel name : Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz

With VMs idle:

# xenpm start 1|grep "Avg freq" Avg freq 3503030 KHz Avg freq 2856840 KHz Avg freq 2788820 KHz Avg freq 2312680 KHz Avg freq 2210650 KHz Avg freq 3537040 KHz Avg freq 3469020 KHz Avg freq 2584760 KHz

With VMs busy:

# xenpm start 1|grep "Avg freq" Avg freq 3673080 KHz Avg freq 3571050 KHz Avg freq 3503030 KHz Avg freq 3537040 KHz Avg freq 3469020 KHz Avg freq 3537040 KHz Avg freq 3469020 KHz Avg freq 3571050 KHz

Avoiding Turbo mode

Some users might wish to avoid using Turbo mode, for example when running workloads that require low-latency wakeups, or when desiring consistent rather than maximal performance. In practice, this can normally be achieved by forcing the processor to stay in C0.

The maximum C-state can be set as in previous versions of XenServer. To immediately force the processor to stay in C0, execute the following command in dom0:

xenpm set-max-cstate 0

Or, to make this change persist across reboots, use the following command and reboot:

/opt/xensource/libexec/xen-cmdline –set-xen max_cstate=0

Note that forcing the processor to stay in C0 will significantly increase the power consumption and may reduce the lifespan of the processor (From Section 4.2.2 of the 4th Generation Intel Core Datasheet Volume 1: “Long term reliability cannot be assured unless all the Low-Power Idle States are enabled”).

When setting a maximum C-state, note that C-state numbers do not necessarily correspond directly with ACPI C-state names. The C-states mentioned in the output of “xenpm get-cpuidle-states” are simply a numerical list of all the C-states that Xen knows about, listed as C0, C1, C2, etc. This means that ACPI C0 will appear as C0, ACPI C1 will appear as C1, ACPI C1E will appear as C2, and so on. Furthermore, some states might not be individually addressable with “xenpm set-max-cstate <X>” and setting the maximum C-state to X does not necessarily mean that only C0..CX will be used.

CPU Frequencies

Frequency scaling and Turbo mode are controlled by the BIOS settings, as with previous versions of XenServer. XenServer controls each processor core’s frequency by adjusting the P-state.

Citrix recommends configuring the BIOS frequency scaling settings to use “OS control” mode (or equivalent) and to enable Turbo mode.

In its default configuration, XenServer 6.5 and later use the “performance” governor for Intel processors and the more power-friendly “ondemand” governor for AMD processors. This is the recommended configuration.

  • The performance governor always sets the processor to its maximum P-state which results in the highest frequency being used.

  • The ondemand governor dynamically downclocks the cores. This can provide some power savings at the cost of performance.

For AMD processors, the “ondemand” governor is normally preferred as it gives a good compromise between performance and power-saving. By contrast, Intel processors typically save power by entering deep C-states so the “performance” governor is preferred.

Changing governor

Some users may wish to change the CPU frequency governor, e.g. in order to sacrifice performance to make power savings, or vice versa.

In order to use a different governor at runtime, run the following command in dom0:

xenpm set-scaling-governor performance

or:

xenpm set-scaling-governor ondemand

In order to make this change persist across reboots, use:

/opt/xensource/libexec/xen-cmdline –set-xen cpufreq=xen:performance

or:

/opt/xensource/libexec/xen-cmdline –set-xen cpufreq=xen:ondemand

Setting the CPU frequency governor to “performance” should not have a significantly detrimental effect on the ability of the processor to enter Turbo mode for Intel processors. Since entering Turbo mode usually relies on other cores being idle, having the idle cores at a higher frequency does not matter because the default C-state configuration allows the processor to stop its clocks when idle.

Thermal effects

In order to maximize performance, CPUs should be allowed to run at maximum frequency. However, many CPUs will decrease their operating frequency if they overheat. Overheating is more likely to happen if cores are forced to run in P0 and C0 or while there is a sustained high CPU load.

In order to avoid overheating, the CPU and chassis fans should be configured to maximum speed. This will ensure CPUs stay cool at the cost of increased power consumption. Note that “adaptive” or “automatic” fan speed settings may not always go to maximum speed so do not necessarily perform maximal cooling.

Related:

  • No Related Posts