• Drivers Xpc Drivers
• Drivers Xpc Taylormade
• Drivers Xp-640
• Drivers Cpc Card
• Drivers Xpc Golf
• Drivers Cpc Exemptions

The lowest layer of OS X includes the kernel, drivers, and BSD portions of the system and is based primarily on open source technologies. OS X extends this low-level environment with several core infrastructure technologies that make it easier for you to develop software.

High-Level Features

The following sections describe features in the Kernel and Device Drivers layer of OS X.

A fully assembled system with preinstalled components that is ready to go out of the box. Installed components include a processor, memory, storage drive(s), operating system and more based on custom configurations. Welcome to the MSI Global official site. We are the top Gaming gear provider. Download the latest drivers, firmware, and software for your HP Compaq dc7900 Small Form Factor PC.This is HP’s official website that will help automatically detect and download the correct drivers free of cost for your HP Computing and Printing products for Windows and Mac operating system.

XPC Interprocess Communication and Services

XPC is an OS X interprocess communication technology that complements App Sandbox by enabling privilege separation. Privilege separation, in turn, is a development strategy in which you divide an app into pieces according to the system resource access that each piece needs. The component pieces that you create are called XPC services.

You create an XPC service as an individual target in your Xcode project. Each service gets its own sandbox—specifically, it gets its own container and its own set of entitlements. In addition, an XPC service that you include with your app is accessible only by your app. These advantages add up to making XPC the best technology for implementing privilege separation in an OS X app.

XPC is integrated with Grand Central Dispatch (GCD). When you create a connection, you associate it with a dispatch queue on which message traffic executes.

When the app is launched, the system automatically registers each XPC service it finds into the namespace visible to the app. An app establishes a connection with one of its XPC services and sends it messages containing events that the service then handles.

For more on XPC Services, read Creating XPC Services in Daemons and Services Programming Guide. To learn more about App Sandbox, read App Sandbox Design Guide.

Caching API

The libcache API is a low-level purgeable caching API. Aggressive caching is an important technique in maximizing app performance. However, when caching demands exceed available memory, the system must free up memory as necessary to handle new demands. Typically, this means paging cached data to and from relatively slow storage devices, sometimes even resulting in systemwide performance degradation. Your app should avoid potential paging overhead by actively managing its data caches, releasing them as soon as it no longer needs the cached data.

In the wider system context, your app can also help by creating caches that the operating system can simply purge on a priority basis as memory pressure necessitates. The libcache library and Foundation framework’s NSCache class help you to create these purgeable caches.

For more information about the functions of the libcache library, see libcache Reference. For more information about the NSCache class, see NSCache Class Reference.

In-Kernel Video Capture

I/O Video provides a kernel-level C++ programming interface for writing video capture device drivers. I/O Video replaces the QuickTime sequence grabber API as a means of getting video into OS X.

I/O Video consists of the IOVideoDevice class on the kernel side (along with various related minor classes) that your driver should subclass, and a user space device interface for communicating with the driver.

For more information, see the IOVideoDevice.h header file in the Kernel framework.

The Kernel

Beneath the appealing, easy-to-use interface of OS X is a rock-solid, UNIX-based foundation that is engineered for stability, reliability, and performance. The kernel environment is built on top of Mach 3.0 and provides high-performance networking facilities and support for multiple, integrated file systems.

The following sections describe some of the key features of the kernel and driver portions of Darwin.

Mach

Mach is at the heart of Darwin because it provides some of the most critical functions of the operating system. Much of what Mach provides is transparent to apps. It manages processor resources such as CPU usage and memory, handles scheduling, enforces memory protection, and implements a messaging-centered infrastructure for untyped interprocess communication, both local and remote. Mach provides the following important advantages to Mac computing:

• Protected memory. The stability of an operating system should not depend on all executing apps being good citizens. Even a well-behaved process can accidentally write data into the address space of the system or another process, which can result in the loss or corruption of data or even precipitate system crashes. Mach ensures that an app cannot write in another app’s memory or in the operating system’s memory. By walling off apps from each other and from system processes, Mach makes it virtually impossible for a single poorly behaved app to damage the rest of the system. Best of all, if an app crashes as the result of its own misbehavior, the crash affects only that app and not the rest of the system.

• Preemptive multitasking. With Mach, processes share the CPU efficiently. Mach watches over the computer’s processor, prioritizing tasks, making sure activity levels are at the maximum, and ensuring that every task gets the resources it needs. It uses certain criteria to decide how important a task is and therefore how much time to allocate to it before giving another task its turn. Your process is not dependent on another process yielding its processing time.

• Advanced virtual memory. In OS X, virtual memory is “on” all the time. The Mach virtual memory system gives each process its own private virtual address space. For 64-bit apps, the theoretical maximum is approximately 18 exabytes, or 18 billion billion bytes. Mach maintains address maps that control the translation of a task’s virtual addresses into physical memory. Typically only a portion of the data or code contained in a task’s virtual address space resides in physical memory at any given time. As pages are needed, they are loaded into physical memory from storage. Mach augments these semantics with the abstraction of memory objects. Named memory objects enable one task (at a sufficiently low level) to map a range of memory, unmap it, and send it to another task. This capability is essential for implementing separate execution environments on the same system.

• Real-time support. This feature guarantees low-latency access to processor resources for time-sensitive media apps.

Mach also enables cooperative multitasking, preemptive threading, and cooperative threading.

64-Bit Kernel

As of v10.8, OS X requires a Mac that uses the 64-bit kernel. A 64-bit kernel provides several benefits:

• The kernel can support large memory configurations more efficiently.

• The maximum size of the buffer cache is increased, potentially improving I/O performance.

• Performance is improved when working with specialized networking hardware that emulates memory mapping across a wire or with multiple video cards containing over 2 GB of video RAM.

Because a 64-bit kernel does not support 32-bit drivers and kernel extensions (KEXTs), those items must be built for 64-bit. Fortunately, for most drivers and KEXTs, building for a 64-bit kernel is usually not as difficult as you might think. For the most part, transitioning a driver or KEXT to be 64-bit capable is just like transitioning any other piece of code. For details about how to make the transition, including what things to check for in your code, see 64-Bit Transition Guide.

Device-Driver Support

Darwin offers an object-oriented framework for developing device drivers called the I/O Kit framework. This framework facilitates the creation of drivers for OS X and provides much of the infrastructure that they need. Written in a restricted subset of C++ and designed to support a range of device families, the I/O Kit is both modular and extensible.

Device drivers created with the I/O Kit acquire several important features:

• True plug and play

• Dynamic device management (“hot plugging”)

• Power management (for both desktops and portables)

If your device conforms to standard specifications—such as those for mice, keyboards, audio input devices, modern MIDI devices, and so on—it should just work when you plug it in. If your device doesn’t conform to a published standard, you can use the I/O Kit resources to create a custom driver to meet your needs. Devices such as AGP cards, PCI and PCIe cards, scanners, and printers usually require custom drivers or other support software in order to work with OS X.

For information on creating device drivers, see IOKit Device Driver Design Guidelines.

Network Kernel Extensions

Darwin allows kernel developers to add networking capabilities to the operating system by creating network kernel extensions (NKEs). The NKE facility allows you to create networking modules and even entire protocol stacks that can be dynamically loaded into the kernel and unloaded from it. NKEs also make it possible to configure protocol stacks automatically.

NKE modules have built-in capabilities for monitoring and modifying network traffic. At the cellspacing='0' cellpadding='5'>Table 6-1 Network protocols

Protocol

Description

802.1x

802.1x is a protocol for implementing port-based network access over wired or wireless LANs. It supports a wide range of authentication methods, including TLS, TTLS, LEAP, MDS, and PEAP (MSCHAPv2, MD5, GTC).

DHCP and BOOTP

The Dynamic Host Configuration Protocol and the Bootstrap Protocol automate the assignment of IP addresses in a particular network.

DNS

Domain Name Services is the standard Internet service for mapping host names to IP addresses.

FTP and SFTP

The File Transfer Protocol and Secure File Transfer Protocol are two standard means of moving files between computers on TCP/IP networks.

HTTP and HTTPS

The Hypertext Transport Protocol is the standard protocol for transferring webpages between a web server and browser. OS X provides support for both the insecure and secure versions of the protocol.

LDAP

The Lightweight Directory Access Protocol lets users locate groups, individuals, and resources such as files and devices in a network, whether on the Internet or on a corporate intranet.

NBP

The Name Binding Protocol is used to bind processes across a network.

NTP

The Network Time Protocol is used for synchronizing client clocks.

PAP

The Printer Access Protocol is used for spooling print jobs and printing to network printers.

PPP

For dial-up (modem) access, OS X includes PPP (Point-to-Point Protocol). PPP support includes TCP/IP as well as the PAP and CHAP authentication protocols.

PPPoE

The Point-to-Point Protocol over Ethernet protocol provides an Ethernet-based dial-up connection for broadband users.

S/MIME

The Secure/Multipurpose Internet Mail Extensions protocol supports encryption of email and the attachment of digital signatures to validate email addresses.

SLP

Service Location Protocol is designed for the automatic discovery of resources (servers, fax machines, and so on) on an IP network.

SOAP

The Simple Object Access Protocol is a lightweight protocol for exchanging encapsulated messages over the web or other networks.

SSH

The Secure Shell protocol is a safe way to perform a remote login to another computer. Session information is encrypted to prevent unauthorized access of data.

TCP/IP and UDP/IP

OS X provides two transmission-layer protocols, TCP (Transmission Control Protocol) and UDP (User Datagram Protocol), to work with the network-layer Internet Protocol (IP). (OS X includes support for IPv6 and IPSec.)

XML-RPC

XML-RPC is a protocol for sending remote procedure calls using XML over the web.

OS X also implements a number of file-sharing protocols; see Table 6-4 for a summary of these protocols.

Network Technologies

OS X supports the network technologies listed in Table 6-2.

Network Diagnostics

Network diagnostics is a way of helping the user solve network problems. Although modern networks are generally reliable, there are still times when network services may fail. Sometimes the cause of the failure is beyond the ability of the desktop user to fix, but sometimes the problem is in the way the user’s computer is configured. The network diagnostics feature provides a diagnostic app to help the user locate problems and correct them.

If your app encounters a network error, you can use the diagnostic interfaces of CFNetwork to launch the diagnostic app and attempt to solve the problem interactively. You can also choose to report diagnostic problems to the user without attempting to solve them.

For more information on using this feature, see Using Network Diagnostics.

File-System Support

The file-system component of Darwin is based on extensions to BSD and an enhanced Virtual File System (VFS) design. The file-system component includes the following features:

• Permissions on removable media. This feature is based on a globally unique ID registered for each connected removable device (including USB and FireWire devices) in the system.

• Access control lists, which support fine-grained access to file-system objects.

• URL-based volume mounts, which enable users (via a Finder command) to mount such things as AppleShare and web servers

• Unified buffer cache, which consolidates the buffer cache with the virtual-memory cache

• Long filenames (255 characters or 755 bytes, based on UTF-8)

• Support for hiding filename extensions on a per-file basis

• Journaling of all file-system types to aid in data recovery after a crash

Because of its multiple app environments and the various kinds of devices it supports, OS X handles file data in many standard volume formats. Table 6-3 lists the supported formats.

HFS+ volumes support aliases, symbolic links, and hard links, whereas UFS volumes support symbolic links and hard links but not aliases. Although an alias and a symbolic link are both lightweight references to a file or directory elsewhere in the file system, they are semantically different in significant ways. For more information, see Aliases and Symbolic Links in File System Overview.

Note: OS X does not support stacking in its file-system design.

Because OS X is intended to be deployed in heterogeneous networks, it also supports several network file-sharing protocols. Table 6-4 lists these protocols.

Security

The roots of OS X in the UNIX operating system provide a robust and secure computing environment whose track record extends back many decades. OS X security services are built on top of BSD (Berkeley Software Distribution), an open-source standard. BSD is a form of the UNIX operating system that provides basic security for fundamental services, such as file and network access.

The CommonCrypto library, which is part of libSystem, provides raw cryptographic algorithms. It is intended to replace similar OpenSSL interfaces.

Note: CDSA (Common Data Security Architecture) and OpenSSL are deprecated and their further use is discouraged. Consider using Security Transforms technology to replace CDSA and CommonCrypto to replace OpenSSL. Security Transforms, which are part of the Security framework, are described in Security Services.

OS X also includes the following security features:

• Adoption of Mandatory Access Control, which provides a fine-grained security architecture for controlling the execution of processes at the kernel level. This feature enables the “sandboxing” of apps, which lets you limit the access of a given app to only those features you designate.

• Support for code signing and installer package signing. This feature lets the system validate apps using a digital signature and warn the user if an app is tampered with.

• Compiler support for fortifying your source code against potential security threats. This support includes options to disallow the execution of code located on the stack or other portions of memory containing data.

• Support for putting unknown files into quarantine. This is especially useful for developers of web browsers or other network-based apps that receive files from unknown sources. The system prevents access to quarantined files unless the user explicitly approves that access.

For an introduction to OS X security features, see Security Overview.

Drivers Xpc Drivers

Scripting Support

Darwin includes all of the scripting languages commonly found in UNIX-based operating systems. In addition to the scripting languages associated with command-line shells (such as bash and csh), Darwin also includes support for Perl, Python, Ruby, Ruby on Rails, and others.

OS X provides scripting bridges to the Objective-C classes of Cocoa. These bridges let you use Cocoa classes from within your Python and Ruby scripts. For information about using these bridges, see Ruby and Python Programming Topics for Mac.

Threading Support

OS X provides full support for creating multiple preemptive threads of execution inside a single process. Threads let your program perform multiple tasks in parallel. For example, you might create a thread to perform some lengthy calculations in the background while a separate thread responds to user events and updates the windows in your app. Using multiple threads can often lead to significant performance improvements in your app, especially on computers with multiple CPU cores. Multithreaded programming is not without its dangers though. It requires careful coordination to ensure your app’s state does not get corrupted.

All user-level threads in OS X are based on POSIX threads (also known as pthreads). A pthread is a lightweight wrapper around a Mach thread, which is the kernel implementation of a thread. You can use the pthreads API directly or use any of the threading packages offered by Cocoa. Although each threading package offers a different combination of flexibility versus ease-of-use, all packages offer roughly the same performance.

In general, you should try to use Grand Central Dispatch or operation objects to perform work concurrently. However, there might still be situations where you need to create threads explicitly. For more information about threading support and guidelines on how to use threads safely, see Threading Programming Guide.

X11

The X11 windowing system is provided as an optional installation component for the system. This windowing system is used by many UNIX applications to draw windows, controls, and other elements of graphical user interfaces. The OS X implementation of X11 uses the Quartz drawing environment to give X11 windows a native OS X feel. This integration also makes it possible to display X11 windows alongside windows from native apps written in Cocoa.

Software Development Support

The following sections describe some additional features of OS X that affect the software development process.

Binary File Architecture

The underlying architecture of OS X executables was built from the beginning with flexibility in mind. This flexibility became important as Mac computers have transitioned from using PowerPC to Intel CPUs and from supporting only 32-bit apps to 64-bit apps. The following sections provide an overview of the types of architectures you can support in your OS X executables along with other information about the runtime and debugging environments available to you.

Hardware Architectures

When OS X was first introduced, it was built to support a 32-bit PowerPC hardware architecture. With Apple’s transition to Intel-based Mac computers, OS X added initial support for 32-bit Intel hardware architectures. In addition to 32-bit support, OS X v10.4 added some basic support for 64-bit architectures as well and this support was expanded in OS X v10.5. This means that apps and libraries can now support two different architectures:

• 32-bit Intel (i386)

• 64-bit Intel (x86_64)

Although apps can support all of these architectures in a single binary, doing so is not required. The ability to create “universal binaries” that run natively on all supported architectures gives OS X the flexibility it needs for the future.

Supporting multiple architectures requires careful planning and testing of your code for each architecture. There are subtle differences from one architecture to the next that can cause problems if not accounted for in your code. For example, some built-in data types have different sizes in 32-bit and 64-bit architectures. Accounting for these differences is not difficult but requires consideration to avoid coding errors.

Xcode provides integral support for creating apps that support multiple hardware architectures. For information about tools support and creating universal binaries. For information about 64-bit support in OS X, including links to documentation for how to make the transition, see 64-Bit Support.

64-Bit Support

OS X was initially designed to support binary files on computers using a 32-bit architecture. In OS X v10.4, however, support was introduced for compiling, linking, and debugging binaries on a 64-bit architecture. This initial support was limited to code written using C or C++ only. In addition, 64-bit binaries could link against the Accelerate framework and libSystem.dylib only.

Starting in OS X v10.5, most system libraries and frameworks are 64-bit ready, meaning they can be used in both 32-bit and 64-bit apps. Frameworks built for 64-bit means you can create apps that address extremely large data sets, up to 128 TB on the current Intel-based CPUs. On Intel-based Macintosh computers, some 64-bit apps may even run faster than their 32-bit equivalents because of the availability of extra processor resources in 64-bit mode.

There are a few technologies that have not been ported to 64-bit. Development of 32-bit apps with these APIs is still supported, but if you want to create a 64-bit app, you must use alternative technologies. Among these APIs are the following:

• The entire QuickTime C API (deprecated in OS X v10.9; in a 64-bit app, use AV Foundation instead)

• HIToolbox, Window Manager, and most other user interface APIs (in general, use Cocoa UI classes and other alternatives); see 64-Bit Guide for Carbon Developers for the list of specific APIs and transition paths.

OS X uses the LP64 model that is in use by other 64-bit UNIX systems, which means fewer headaches when porting from other operating systems. For general information on the LP64 model and how to write 64-bit apps, see 64-Bit Transition Guide. For Cocoa-specific transition information, see 64-Bit Transition Guide for Cocoa.

Object File Formats

OS X is capable of loading object files that use several different object-file formats. Mach-O format is the format used for all native OS X app development.

For information about the Mach-O file format, see OS X ABI Mach-O File Format Reference. For additional information about using Mach-O files, see Mach-O Programming Topics.

Debug File Formats

Whenever you debug an executable file, the debugger uses symbol information generated by the compiler to associate user-readable names with the procedure and data address it finds in memory. Normally, this user-readable information is not needed by a running program and is stripped out (or never generated) by the compiler to save space in the resulting binary file. For debugging, however, this information is very important to be able to understand what the program is doing.

OS X supports two different debug file formats for compiled executables: Stabs and DWARF. The Stabs format is present in all versions of OS X and until the introduction of Xcode 2.4 was the default debugging format. Code compiled with Xcode 2.4 and later uses the DWARF debugging format by default. When using the Stabs format, debugging symbols, like other symbols are stored in the symbol table of the executable; see OS X ABI Mach-O File Format Reference. With the DWARF format, debugging symbols are stored either in a specialized segment of the executable or in a separate debug-information file.

For information about the DWARF standard, go to The DWARF Debugging Standard; for information about the Stabs debug file format, see STABS Debug Format. For additional information about Mach-O files and their stored symbols, see Mach-O Programming Topics.

Runtime Environments

Since its first release, OS X has supported several different environments for running apps. The most prominent of these environments is the dynamic link editor (dyld) environment, which is also the only environment supported for active development. Most of the other environments provided legacy support during the transition from Mac OS 9 to OS X and are no longer supported for active development. The following sections describe the runtime environments you may encounter in various versions of OS X.

dyld Runtime Environment

The dyld runtime environment is the native environment in OS X and is used to load, link, and execute Mach-O files. At the heart of this environment is the dyld dynamic loader program, which handles the loading of a program’s code modules and associated dynamic libraries, resolves any dependencies between those libraries and modules, and begins the execution of the program.

Upon loading a program’s code modules, the dynamic loader performs the minimal amount of symbol binding needed to launch your program and get it running. This binding process involves resolving links to external libraries and loading them as their symbols are used. The dynamic loader takes a lazy approach to binding individual symbols, doing so only as they are used by your code. Symbols in your code can be strongly linked or weakly linked. Strongly linked symbols cause the dynamic loader to terminate your program if the library containing the symbol cannot be found or the symbol is not present in the library. Weakly linked symbols terminate your program only if the symbol is not present and an attempt is made to use it.

For more information about the dynamic loader program, see the dyld man page. For information about building and working with Mach-O executable files, see Mach-O Programming Topics.

Language Support

The tools that come with OS X provide direct support for developing software using the Swift, C, C++, Objective-C, and Objective-C++ languages along with numerous scripting languages. Support for other languages may also be provided by third-party developers. For more information on the key features of Swift and Objective-C, see Development Languages

Copyright © 2004, 2015 Apple Inc. All Rights Reserved. Terms of Use | Privacy Policy | Updated: 2015-09-16

XCP-ng needs guest tools to be installed in the VMs in order to communicate with the guest operating system. This brings better performance and is required for various features.

In short: always install the guest tools to your VMs.

The tools are made of two main components:

• kernel drivers for the OS
• a management agent

# Linux

Xen guest drivers have been built-in in the Linux kernel for many years. All currently supported Linux distributions include them.

So all we need is to install the management agent, which comes either as a systemd or as a sysvinit service, depending on the Linux distribution. The service is usually named xe-linux-distribution.

Those guest tools can be installed:

• from the target distribution's online repositories if available
• from the Guest Tools ISO image that can be attached to any VM in XCP-ng

# Install from the distro's online repositories

Distros often have policies that forbid enabling new services by default, so most of the time the steps are:

• enable the appropriate repository
• install the package from it
• enable the service

# CentOS and Fedora

Enable the EPEL repository in the VM, then:

The service is not enabled by default, so enable it and start it:

# Alpine

Enable the community repository in /etc/apk/repositories, then:

The service is not enabled by default, so enable it and start it:

# Ubuntu

Feel free to add other distros to the above list if they provide the tools in their repositories.

# Install from the guest tools ISO

# 'Supported' Linux distributions

For distros that are supported by the install.sh script (Debian, CentOS, RHEL, SLES, Ubuntu...), the process is:

• Attach the guest tools ISO to the guest from Xen Orchestra or using xe.
• Then inside the VM, as root:

• No need to reboot the VM even if the script asks to. That's an old message from back when it was needed to install a kernel module in addition to the management agent. We'll get rid of it at some point.
• Eject the guest tools ISO

# Derived Linux distributions

If your Linux distribution is not recognized by the installation script but derives from one that is supported by the script, you can override the detection and force the tools to install by using:

Examples:

The likeliness for the installation to work correctly will depend on how much those distros differ from their 'parent'.

# Other Linux distributions

For the remaining Linux distributions, mount the guest tools ISO as described above, then look for the xe-guest-utilities_*_all.tgz archive. Copy its contents on the system in /etc and /usr. It contains a System V init script by default but there's also a systemd unit file available on the ISO (xe-linux-distribution.service).

See also Contributing below.

# Update the guest tools

It's a good habit, and may be even required in some cases (that would then be described in the Release Notes, to update the guest tools to their latest version when your XCP-ng hosts are updated.

Depending on the situation, just update from your distribution's online repositories, or follow the above installation process again.

# FreeBSD

FreeBSD is a 30-year-old operating system used widely to run all sorts of systems and has served as the basis for a number of operating systems, including MacOS, pfSense, and FreeNAS. The Xen kernel modules are built and distributed in the GENERIC kernel, so if you haven't customised or recompiled your kernel, the drivers will be present.

To communicate with the hypervisor, you need to install two ports(opens new window):

The install.sh script on the guest tools ISO does not yet support FreeBSD, so there is no point in mounting the guest tools ISO on a FreeBSD VM.

To manually install xe-guest-utilities from a package(opens new window) you can run:

By default the xe-daemon will run if FreeBSD detects the Xen hypervisor at boot. If that autodetection fails for some reason, you can force it to try by putting xenguest_enable=YES in your rc.conf file: sysrc xenguest_enable=YES.

Run service xenguest [stop|start|restart] to respectively stop, start, or restart the xe-daemon.

# OpenBSD

On OpenBSD, the xen drivers are also already part of the kernel. The install.sh script doesn't support OpenBSD, but there are ways to install the management agent anyway.

TIP

For OpenBSD search the forum(opens new window). See for example this thread(opens new window).

# FreeNAS/TrueNAS

FreeNAS is a locked-down version of FreeBSD, with many packages disabled to ensure a more stable environment for the fileserver. xe-guest-utilities is part of the packages that are not available in FreeNAS. But because it's based on FreeBSD, the packages from that OS can be installed, at your own risk. This is not a big issue for this particular package, because it's a leaf in the chain of dependencies - nothing in FreeNAS depends on it.

To install it on versions 11 or higher, until version 12.0-U1 of TrueNAS that includes it as default, follow these steps.

1. Enable the FreeBSD repo first:

   If you are using FreeNAS v11.2 or higher, you also have to disable the local package repository to avoid an issue in that particular release and that may affect later versions(opens new window) before running pkg install:

2. Create a temporary directory and move into it:

3. Fetch the required packages. A directory All will be created and you will find the packages with their current versions under there:

4. Add the downloaded packages, without their dependencies:

   The versions reported here are just the current version and they maybe different in your installation.

5. Revert the repos to their original settings to avoid surprises down the road. The second command should be run just if you disabled the local repo in step 1:

   A restart of the VM will perform a reset of these files to their original settings too.

6. Once the package is installed, you need to tell FreeNAS to start the xe-daemon process when starting:

   1. Go to Tasks -> Init/Shutdown Script
   2. Create a new task with the following settings:
      • Type: Command
      • Command: /usr/local/sbin/xe-daemon -p /var/run/xe-daemon.pid &
      • When: Pre Init
      • Enabled: Checked

7. Reboot. If you do not plan to reboot the VM, you can start the daemon manually running the command /usr/local/sbin/xe-daemon -p /var/run/xe-daemon.pid &. After you'll see a FreeBSD icon in your VM list on Xen Orchestra, and you can restart/shutdown the VM properly from the Web UI.

More insights and options are available in this issue(opens new window) or this issue(opens new window).

Drivers Xpc Taylormade

# Windows

Windows guests need both the device drivers and the management agent.

• The device drivers bring optimized I/O performances.
• The management agent brings more manageability of the VM from XCP-ng, and guest metrics reporting to the host.

# Citrix tools vs XCP-ng tools

There exists two different set of tools that you can use on your VMs: the official tools from Citrix Hypervisor, or the fully open-source tools from XCP-ng. Both work well. The important point is not to mix them in the same VM.

Citrix tools:

• ➕ Benefit from all the testing by Citrix QA team.
• ➕ The drivers can be updated through Windows Update.
• ➖ Proprietary, closed-source.

XCP-ng tools:

• ➕ Fully open-source.
• ➕ Maintained by the XCP-ng project.
• ➕ ➖ The sources for the drivers are from the Xen project directly, without additional Citrix patches. This is good, but it may be that in some specific situations Citrix drivers behave better (None known at the moment).
• ➖ The sources for the management agent are older than that of Citrix (they have stopped updating GitHub a while ago).
• ➖ Maintained by one overloaded community member until Vates finds a developer to hire or contract with in order to maintain them more efficiently.
• ➖ Won't transparently replace existing Citrix tools. You need to remove Citrix tools first if they are present, in order to install XCP-ng tools.

It's now up to you to choose.

Drivers Xp-640

# XCP-ng Windows Guest Tools

Drivers built by the XCP-ng community.

Download: https://github.com/xcp-ng/win-pv-drivers/releases(opens new window)

Stability and testing status: Windows guest tools community testing(opens new window).

# How to know if tools are already installed and working

The VM needs to be running for this test.

# From Xen Orchestra

• Management agent + device drivers: XO displays 'Hardware virtualization with paravirtualization drivers enabled (PVHVM)'
• Device drivers alone: Xen Orchestra is currently (2020-03-30) unable to detect if the device drivers are installed if the management agent is not installed either. See https://github.com/vatesfr/xen-orchestra/issues/4783(opens new window). If it displays 'No tools detected', it is still possible that the device drivers are present.

# From command line

Drivers Cpc Card

• Device drivers: xe vm-param-get param-name=PV-drivers-detected uuid={VM-UUID}
• Management agent: xe vm-param-get param-name=PV-drivers-version uuid={VM-UUID} (ok if not empty)

# Installing on fresh installed Windows

# Prerequisite: Disable 'Windows Update tools'

The first step, before the VM creation and first start, is to make sure than Windows Update is not going to install Citrix tools automatically at first boot. This behaviour is governed by the 'Windows Update tools' parameter in a VMs advanced view. It must be off.

Before creating the VM:

• Make sure you are not creating it from a custom template than has the 'Windows Update tools enabled.
• ⚠️ Do not create it from XCP-ng Center. XCP-ng Center automatically enables that option when the license allows it (and in XCP-ng the license always allows it...). This behaviour may be modified in the future.

Before starting the VM:

• Check the value of 'Windows Update tools' in the Advanced tab of your VM in Xen Orchestra. Must be off.

If you already started the VM with the option on, then the Citrix drivers have been installed automatically. Restart from scratch or see below how to remove them.

Tip: you can also check the value of the parameter from the command line.

True means that it's active, False that it isn't. It needs to be False.

# Install the XCP-ng drivers

0. snapshot before just in case
1. unpack the ZIP file
2. start setup.exe
3. follow the install wizard

Note: Restart can take a while if your windows is currently updating. Restart only occurs after windows has the updates finished.

4. after restart one of two messages should pop up
   • request for restart <- just restart!
   • Management Agent installed successfully <- enjoy 😃

# Upgrade from Citrix ®️ XenServer ®️ client tools

Our installer is not able currently to cleanly uninstall Citrix tools. Citrix tools' uninstaller itself isn't either: it leaves various things behind.

So we need to perform a complete manual clean-up of the tools:

• either entirely manually
• or using the experimental PowerShell script contributed by one of our users at https://github.com/siodor/win-tools-cleanup(opens new window)

⚠️ In any case, first disable 'Windows Update tools' for the VM (Xen Orchestra, advanced tab) and reboot it.

Following is the manual process.

# The confident option

You can try a simple process first with some chances of success.

0. Make a snapshot so you can rollback. Windows can get unstable/unbootable if things go wrong.
1. Uninstall Citrix ®️ XenServer ®️ Client Tools
2. Reboot
3. Uninstall XenServer PV-Drivers in Device Manager in following order (reboots may be needed):
   • XenServer PV Network Device (one ore more Devices)
   • XenServer PV Storage Host Adapter
   • XenServer PV Network Class
   • XenServer Interface
   • XenServer PV Bus (c000) (if present)
   • XenServer PV Bus (0002) or XenServer PV Bus (0001)
4. Reboot
5. Check that you see this unknown device in Device Manager:
   • SCSI-Controller - PCI-Device ID 5853:0002
6. Unpack ZIP file
7. Start setup.exe
8. Follow the install wizard

Note: Restart can take a while if your windows is currently updating. Restart only occurs after windows has the updates finished.

# The nuclear option

If the confident option above didn't yield the expected results, then we switch to a more aggressive attitude towards the old tools.

TIP

What follows works in many cases, but some users occasionally still meet the following issues: XCP-ng tools not installing (but Citrix tools install well, so that is a solution to have working tools), and occasional BSODs in some cases or versions of Windows.

Drivers Xpc Golf

Through many tests, a user came up with a similar yet slightly different procedure that allowed them to avoid Blue Screens Of Death in their situation: https://xcp-ng.org/forum/post/27602.

Help is welcome to help us reconcile both procedures into one.

• Follow the steps 0 to 4 of the 'confident option' above if not done yet.
• Follow this (ignore steps 6 and 7, do not try to install the tools yet) https://support.citrix.com/article/CTX215427(opens new window)
• Now open regedit and go to HKLMSYSTEMCurrentControlSetServices and delete entries for all xen* services.
• In regedit, also go to HKLMSOFTWAREMicrosoftWindowsCurrentVersionDIFxDriverStore and remove ONLY xennet* xenvif*
• Go to C:WindowsSystem32 and remove: (you may not have all these)
  • xenbus_coinst*.dll
  • xenvbd_coinst*.dll
  • liteagent.exe
• Now go to C:WindowsSystem32drivers and remove any files named xen*
• Go to C:Windowssystem32DriverStoreFileRepository and remove xennet* and Xenvif* directories.
• Open the Device Manager and Click View --> Show Hidden Devices. Select Other Devices and Right click on XENBUS VIF and select uninstall. If it asks to delete the driver, check yes. Do this for any xen related thing you see in device manager. Also do the same for any unknown devices.
• Lastly, reboot the VM. You should now hopefully be able to install xen tools regularly.

Drivers Cpc Exemptions

Note: Also have a look at our Troubleshooting Guide - Windows PV-Tools.

# VMs with INACCESSIBLE_BOOT_DEVICE error

You can try to manually inject the missing drivers in recovery mode.

• Get the 'Drivers' folder from the XCP Tools installation path (C:PROGRAM FILES...) - from another VM or install the tools somewhere else to get it.
• Create an ISO-Image containing the 'Drivers' folder (see http://imgburn.com(opens new window)) and mount that ISO-Image to your VM
• Boot to recovery mode and use the command line and the tool 'dism' (see Microsoft Docs(opens new window)) to inject the drivers (specifically the xenbus and xenvbd drivers) - watch out for the drive letter of the Windows installation and the CD-Drive ('D' and 'E' in the following example):

# Using the Windows guest tools from Citrix

Tools from Citrix are not included in the guest tools ISO distributed with XCP-ng for legal reasons.

# A reminder

As written above:

• The device drivers bring optimized I/O performances.
• The management agent brings more manageability of the VM from XCP-ng, and guest metrics reporting to the host.

# Management agent + device drivers

The only way to get the management agent is from Citrix. It can be freely downloaded from the Citrix Hypervisor download page(opens new window), provided you create an account on their site. Name of the item: 'Citrix VM Tools for Windows'. The installer will install both the management agent and the device drivers.

# Automated installation via Windows Update: device drivers alone

If you are using Xen Orchestra, you can switch the 'Windows Update tools' advanced parameter on from the 'Advanced' tab of the VM view. This will install the device drivers automatically at next reboot ⚠️ but not the management agent which still needs to be installed from Citrix tools' installer.

... So the 'Windows Update tools' option is not a complete solution if you need the guest metrics from the management agent. However it may be a convenient way to get future driver updates if you wish so.

# Switching from XCP-ng tools to Citrix tools

If your VM already has XCP-ng tools and you wish to switch to Citrix tools, then you need to do the same kind of clean-up as described higher in this document for the opposite situation.

# Contributing

# Linux / xBSD

If you would like to contribute improvements to the install.sh script so that it supports your distro, create a pull request against: https://github.com/xcp-ng/xe-guest-utilities/tree/master/mk. Relevant files are usually xe-linux-distribution and install.sh.

# Windows

The XCP-ng team is looking for help in improving the guest tools installer, build process, and clean-up tools.