Skip to main content

Answer file

How to build an answer file?

To create a fully automated and unattended installation of XCP-ng, you can rely on an answer file.

This file is an XML, here is an example:

<?xml version="1.0"?>
    <installation sr-type="ext">
        <primary-disk>sda</primary-disk>
        <guest-disks>
            <guest-disk>sdb</guest-disk>
        </guest-disks>
        <keymap>us</keymap>
        <root-password>myrootpassword</root-password>
        <source type="url">http://pxe.example.org/xcp-ng/</source>
        <post-install-script type="url">
          http://pxe.example.org/myscripts/post-install-script
        </post-install-script>
        <admin-interface name="eth0" proto="dhcp" />
        <timezone>Europe/Paris</timezone>
    </installation>
tip

Since XCP-ng 8.3, the local SR is ext (thin-provisioned) by default. Set sr-type="lvm" to get a thick-provisioned LVM SR instead.

Answer file values​

Here is the list of all entries.

Install​

<installation>
…
</installation>
tip

<installation mode="fresh"> will not make any backup if there's a previous installation

Re-install (backup, no config preservation):

<installation mode="reinstall">
…
</installation>

Upgrade (backup, preserve config):

<installation mode="upgrade">
…
</installation>

Restore:

<restore>
…
</restore>

Install options​

netinstall-gpg-check=bool

Check authenticity of repository metadata and RPMs (GPG signatures) (new in 8.0). It's True by default.

Common Elements​

Source​

  <source type="type">repo</source>
  <driver-source type="type">repo</driver-source>

Where type is one of:

  • local (repo ignored)
  • url
  • nfs

source defines the location of the installation repository or a Supplemental Pack. There may be multiple 'source' elements.

driver-source defines the source of a Supplemental Pack containing device drivers to be loaded by the installer and included after installation of the main repository.

Repository formats:

  • nfs - server:/path/
  • url - one of:
    • http://[user[:passwd]]@host[:port]/path/
    • https://[user[:passwd]]@host[:port]/path/
    • ftp://[user[:passwd]]@host[:port]/path/
    • file:///path/
    • nfs://server:/path/

Bootloader​

Defines the bootloader variant and location. Optional.

  <bootloader location="mbr|partition">grub2</bootloader>

Default is mbr.

The optional attribute is write-boot-entry=bool, whether to modify the EFI Boot manager and write a boot entry for a UEFI installation. It's true by default.

Network backend​

Defines the network stack variant. Optional.

  <network-backend>bridge|openvswitch|vswitch</network-backend>

Default: vswitch.

Stage​

Defines a shell or python script to be invoked at the defined stage. Optional.

<script stage="stage" type="type">url</script>

Where stage is one of:

  • installation-start
  • filesystem-populated
  • installation-complete

And type is one of:

  • nfs
  • url

Args passed to the script:

  • installation-start: None
  • filesystem-populated: mnt (mount point of root filesystem)
  • installation-complete: 0 | 1 (success or failure)

FCoE​

Specifies interfaces to run Fibre Channel over Ethernet VLAN Discovery on.

<fcoe-interface name="eth"/> | <fcoe-interface hwaddr="mac"/>

(Re)Install Elements​

Initial Partitions​

Create primary partitions before installation. Used by XenRT to test preservation of Dell utility partitions.

  <initial-partitions>
    <partition number="n" size="sz" id="id"/>
  </initial-partitions>

Software RAID​

Specifies the target disks and md device for creating a software RAID 1 array. The md device can then be used in <primary-disk> below. New in XCP-ng 7.5.0-2 and 7.6.

  <raid device="dev">
    <disk>dev1</disk>
    <disk>dev2</disk>
  </raid>

Primary disk​

Specifies the target disk for installation.

  <primary-disk>dev</primary-disk>

Optional attribute:

  • guest-storage=bool. Include the remaining space of the primary disk in the local SR. True by default.
  • sr-at-end=bool. Location of SR partition on the physical disk. Used by XenRT to simulate a host that has been migrated from an OEM release. Default: True.
  • preserve-first-partition=true|yes|false|no|if-utility. Defines the action to perform on detecting a non-XS partition at the start of the disk. Default : if-utility. Values:
    • true|yes: Unconditionally preserve
    • false|no: Unconditionally destroy
    • if-utility: Preserve if ID == 0xDE (MBR) or GUID == C12A7328-F81F-11D2-BA4B-00A0C93EC93B and partition label == 'DELLUTILITY' (GPT).

Guest disks​

Specifies additional devices to be included in the local SR.

  <guest-disks>
    <guest-disk>dev</guest-disk>
  </guest-disks>

Admin interface​

Specifies the initial management interface.

Select an existing NIC by its interface name (name) or MAC address (hwaddr). For example, to use eth0 with DHCP:

<admin-interface name="eth0" proto="dhcp" />

To select the management NIC by MAC address instead, regardless of its current interface name:

<admin-interface hwaddr="00:11:22:33:44:55" proto="dhcp" />

Replace the example MAC address with the address of the physical NIC you want to use. Specify either name or hwaddr. Selecting a NIC this way does not rename it or change its MAC address. To assign names such as eth0 and eth1 to specific NICs, see Assigning interface names by MAC address.

Mandatory attributes:

  • proto="static|dhcp|none"

If the interface is static then the following elements must be present:

      <ipaddr>ip</ipaddr>

      <subnet>subnet</subnet>

      <gateway>gw</gateway>

If proto is specified as "none" then protov6 must be specified and must not be none. Default: none. Optional attributes:

  • vlan="vlan". Specifies tagged VLAN id for management interface. If not present, untagged VLAN is used as default. VLAN is supported from 1 to 4094.
  • protov6="static|dhcp|autoconf|none". Default: none.

If protov6 is static then the following elements must be present:

      <ipv6>ipv6/prefix_length</ipv6>
      <gatewayv6>gw</gatewayv6>

Assigning interface names by MAC address​

To make a particular physical NIC become eth0 or eth1, use the installer boot parameter map_netdev. Add it to the installer's vmlinuz command line in your boot menu or PXE configuration. It is not an answer file XML element.

For example, these parameters assign two NICs by MAC address:

map_netdev=eth0:s:00:11:22:33:44:55 map_netdev=eth1:s:00:11:22:33:44:66

Here, s selects a static naming rule. The first NIC becomes eth0 and the second becomes eth1; these rules are also saved on the installed host. Replace both MAC addresses with those of your NICs.

You can then select the mapped eth0 as the management interface in your answer file:

<admin-interface name="eth0" proto="dhcp" />

The NIC used to download a remote answer file is selected separately, before the XML is read. For example, add network_device=00:11:22:33:44:55 to the installer command line to fetch it through that NIC.

See the interface mapping boot parameter reference for a combined example.

Root password​

Specifies the root password. The value !! and a type of "hash" defers setting a password until first boot. Default: type="hash", !!.

  <root-password type="plaintext|hash">passwd</root-password>

How to create a hash.

mkpasswd -m SHA-512 'Password1'
$6$Vv6DgmVWmbZ.SdRl$AUWzbpE5luuNQIyW.CUEztWLKEJkSrBhfTKFdMaX1eJhPrtXworF4RIG.GQ9cBtxE0yNBI4weakgnHdGjljFg/

Name Server​

Specifies one or more DNS entries.

  <name-server>ip</name-server>

Hostname​

Specifies the hostname. Default: localhost.localdomain.

  <hostname>name</hostname>

Timezone​

Specifies the timezone (region/city).

  <timezone>tz</timezone>

NTP​

Specifies one or more NTP servers.

  <ntp-server>ntp</ntp-server>

Keymap​

Specifies the console keymap. Default: us.

  <keymap>kbd</keymap>

(Re)Install Attributes​

SR type​

Local SR type. Default: ext (XCP-ng 8.3; lvm on earlier releases). If the local SR disks have 4K logical blocks, the large-block SR type is used instead. The older srtype spelling is deprecated but still works.

  <installation sr-type="lvm|ext"?>

Upgrade Elements​

Existing installation​

Specifies the device containing the XCP-ng installation to be upgraded.

  <existing-installation>dev</existing-installation>

Restore Elements​

Backup disk​

Specifies the device containing the XCP-ng backup to be restored.

  <backup-disk>dev</backup-disk>

Upgrade answer file​

Your answer file can also be used to upgrade your machines. Here is an example:

<?xml version="1.0"?>
<installation mode="upgrade">
    <existing-installation>sda</existing-installation>
    <source type="url">http://pxehost.example.com/xcp-ng/</source>
    <post-install-script type="url">
        http://pxehost.example.com/myscripts/post-install-script
    </post-install-script>
</installation>

As you can see, mode is set to upgrade. Be sure to target the right disk to search for previous existing installations (here sda). Do NOT specify primary-disk and guest-disk!