Creating and starting a vSIM VM on a Linux KVM host

Use the <name> element to assign each VM a meaningful name. The name should be composed of alphanumeric characters (spaces should be avoided) and must be unique within the scope of the host machine. Use the virsh list command to display the VM name. The following is an example of a <name> element:

<name>v-sim-01-control</name>

Each VM has a globally unique UUID identifier. The UUID format is described in RFC 4122. If you do not include a < uuid> element in the domain XML file, libvirt auto generates a value that you can display (after the VM is created) using the virsh dumpxml command. Setting the UUID value explicitly ensures that it matches the UUID specified in the software license. See vSIM software licensing for information about vSIM software licenses. The following is an example of a <uuid> element, using the correct RFC 4122 syntax:

The maximum memory (vRAM) allocated to a VM at boot time is defined in the <memory> element. The 'unit' attribute is used to specify the unit to count the vRAM size.

To express a memory requirement in gigabytes, include a unit=‛G’ (or unit=‛GiB’) attribute, as shown in the following example:

<memory unit='G'>6</memory>

The amount of vRAM needed for a vSIM VM depends on the vSIM system type, vSIM card type, and the MDAs installed in the system or card. See CPU and DRAM memory for more information.

The <vcpu> element defines the number of vCPU cores allocated to a VM. The minimum number of vCPUs that you can allocate to a vSIM VM is two.

The <vcpu> element contains the following attributes:

• cpuset

  The cpuset attribute provides a comma-separated list of physical CPU numbers or ranges, where ‟^” indicates exclusion. Any vCPU or vhost-net thread associated with the VM that is not explicitly assigned by the <cputune> configuration is assigned to one of the physical CPUs allowed by the cpuset attribute.

• current

  The current attribute allows fewer than the maximum vCPUs to be allocated to the VM at boot up. This attribute is not required for vSIM VMs because in-service changes to the vCPU allocation are not allowed.

• placement

  The placement attribute accepts a value of either 'static' or 'auto'. You should use 'static' when specifying a cpuset. When 'auto' is used, libvirt ignores the cpuset attribute and maps vCPUs to physical CPUs in a NUMA-optimized manner based on input from the numad process. The placement attribute defaults to the placement mode of <numatune>, or to static if a cpuset is specified.

The following example <vcpu> configuration for a vSIM VM allocates four vCPUs.

<vcpu>4</vcpu>

The <cpu> element specifies CPU capabilities and topology presented to the guest, and applies to the model of the CPU. The mode attribute of <cpu> supports the following values:

• custom

  In the custom mode, you must specify all the capabilities of the CPU that are presented to the guest.

• host-model

  In the host-model mode, the model and features of the host CPU are read by libvirt just before the VM is started and the guest is presented with almost identical CPU and features.

  If the exact host model cannot be supported by the hypervisor, libvirt falls back to the next closest supported model that has the same CPU features. This fallback is permitted by the <model fallback=‛allow’/> element.)

• host-passthrough

  In the host-passthrough mode, the guest CPU is represented as exactly the same as the host CPU, even for features that libvirt does not understand.

The <topology> child element specifies three values for the guest CPU topology: the number of CPU sockets, the number of CPU cores per socket, and the number of threads per CPU core.

The <numa> child element in the <cpu> element creates specific guest NUMA topology. However, this is not applicable to the vSIM because the vSIM software is not NUMA-aware.

The following is the recommended configuration of the <cpu> element for vSIM VMs:

<cpu mode="custom" match="minimum">
        <model>SandyBridge</model>
        <vendor>Intel</vendor>
</cpu>

The <sysinfo> element presents SMBIOS information to the guest. SMBIOS is divided into three blocks of information (blocks 0 to 2); each block consists of multiple entries. SMBIOS system block 1 is most important for the vSIM. The SMBIOS system block contains entries for the manufacturer, product, version, serial number, UUID, SKU number, and family.

SMBIOS provides a necessary way to pass vSIM-specific configuration information from the host to the guest so that it is available to vSIM software when it boots. When a vSIM VM is started, the vSIM software reads the product entry of the SMBIOS system block. If the product entry begins with 'TIMOS: ' (without the quotes and case insensitive), the software recognizes the string that follows as containing important initialization information. The string following the 'TIMOS: ' characters contains one or more attribute-value pairs formatted as follows:

attribute1=value1 attribute2=value2 attribute3=value3

This pattern continues until all attributes have been specified.

The supported attribute-value pairs and their uses are summarized in vSIM boot parameters in SMBIOS product entry.

The following <sysinfo> example personalizes a vSIM VM to emulate an iom4-e card installed in slot 1 of an SR-12 chassis equipped with an m-sfm5-12 switch fabric module The card is virtually equipped with one me10-10gb-sfp MDA and one me40-1gb-csfp MDA. Replace the attribute values in the SMBIOS product entry string with values appropriate for your deployment.

<sysinfo mode=smbios’>
   <system>
      <entry name='product'>TIMOS:slot=1 chassis=SR-12 sfm=m-sfm5-12 card=iom4-e mda/1=me10-10gb-sfp+ mda/2=me40-1gb-csfp</entry> 
   </system>
</sysinfo>

The following <sysinfo> example personalizes a vSIM VM to emulate a xcm-14s card installed in slot 1 of an SR-14s chassis. This chassis has the sfm-s switch fabric module. The following example simulates 2 XIOMs where the first one has two MDAs and the second one has one MDA. Replace the attribute values in the SMBIOS product entry string with values appropriate for your deployment.

<sysinfo mode=smbios'>
   <system>
      <entry name='product'>TIMOS:slot=1 chassis=SR-14s sfm=sfm-s card=xcm-14s xiom/x1=iom-s-3.0t mda/x1/1=ms18-100gb-qsfp28 mda/x1/2=ms4-400gb-qsfpdd+4-100gb-qsfp28 xiom/x2=iom-s-3.0t mda/x2/1=ms6-200gb-cfp2-dco</entry> 
   </system>
</sysinfo>

The following <sysinfo> example personalizes a vSIM VM to emulate a cpm5 card installed in slot A of an SR-12 chassis. This chassis has the m-sfm5-12 switch fabric module. Replace the attribute values in the SMBIOS product entry string with values appropriate for your deployment.

<sysinfo mode=smbios'>
   <system>
     <entry name='product'>TIMOS:slot=A chassis=SR-12 sfm=m-sfm5-12 card=cpm5 \
      system-base-mac=de:ad:be:ef:00:01 \
      address=192.0.2.124@active address=192.0.2.2/24@standby \
      primary-config=ftp://user01:pass@10.0.0.1/home/user01/SR-12/config.cfg \
      license-file=ftp://user01:pass@10.0.0.1/home/user01/license.txt</
      entry>
   </system>
</sysinfo>

The <os> element provides information about the guest OS to the hypervisor. It contains a <type> element that specifies the guest operating system type. For vSIM VMs, the <type> element must specify hvm, which means that the guest OS is designed to run on bare metal and requires full virtualization.

The arch attribute of the <type> element specifies the CPU architecture that is presented to the guest. For vSIM VMs, you must specify arch=x86_64 to allow the vSIM software to take advantage of 64-bit instructions and addressing.

The machine attribute of the <type> element specifies how QEMU should model the motherboard chipset in the guest system. For vSIM VMs, you should specify machine='pc', which is an alias for the latest I440FX/PIIX4 architecture supported by the hypervisor when the VM is created. The I440FX is a (1996 era) motherboard chipset that combines both Northbridge (memory controller) and Southbridge (IO devices) functionality.

QEMU-KVM can also emulate a Q35 chipset, if you specify machine='q35'. Q35 is a relatively modern (2009 era) chipset design; it separates the Northbridge controller (MCH) from the Southbridge controller (ICH9) and provides the guest with advanced capabilities such as IOMMU and PCI-E.

Although the I440FX emulation is the older machine type, it is the more mature and hardened option and is recommended by Nokia.

The <os> element also contains the <smbios> child element that you must include in the configuration of vSIM VMs. Set the mode attribute to ‟sysinfo”, which allows you to pass the information specified in the <sysinfo> element (including the product entry) to the vSIM guest.

The <os> element can also include one or more <boot> child elements. The dev attribute of each <boot> element specifies a device such as 'hd' (hard drive), 'fd' (disk), 'cdrom', or 'network', which indicates that the guest should load its OS from this device. The order of multiple <boot> elements determines the boot order. For vSIM VMs, you should always boot from the 'hd' device that vSIM translates to its CF3 disk.

The following <os> example shows element configuration suitable for vSIM VMs of all types.

<os>
    <type arch='x86_64' machine='pc'>hvm</type>
    <boot dev='hd'/>
    <smbios mode='sysinfo'/>
</os>

The <clock> element controls specific aspects of timekeeping within the guest. Each guest must initialize its clock to the correct time-of-day when booting and update its clock accurately as time passes.

The offset attribute of <clock> controls how the of the time-of-day clock of the guest is initialized at bootup. For vSIM VMs, the offset attribute value should be set to utc, which enable the host and guest to belong to different timezones, if required.

The vSIM and other guests update the time-of-day clock by counting ticks of virtual timer devices. The hypervisor injects ticks to the guest in a manner that emulates traditional hardware devices, for example, the Programmable Interrupt Timer (PIT), CMOS Real Time Clock (RTC), or High Precision Event Timer (HPET). Each virtual timer presented to the guest is defined by a <timer> sub-element of <clock>. The name attribute of <timer> specifies the device name (for example, 'pit', 'rtc' or 'hpet'), the present attribute indicates whether the particular timer should be made available to the guest, and the tickpolicy attribute controls the action taken when the hypervisor (QEMU) discovers that it has missed a deadline for injecting a tick to the guest. A tickpolicy value set to 'delay' means the hypervisor should continue to delay ticks at the normal rate, with a resulting slip in guest time relative to host time. A tickpolicy value set to 'catchup' means the hypervisor should deliver ticks at a higher rate to compensate for the missed tick.

The following <clock> example shows element configuration suitable for vSIM VMs.

<clock offset='utc'>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='rtc' tickpolicy='catchup'/>
    <time name='hpet' present='no'/>
</clock>

Use the <devices> element to add various devices to the VM, including hard drives, network interfaces, and serial console ports.

The <devices> element requires that the file path of the program used to emulate the devices must be specified in the <emulator> child element. On Centos and Red Hat hosts the emulator is a binary called qemu-kvm; on Ubuntu hosts, the emulator is called qemu-system-x86_64.

The device types are as follows:

• Disk devices

• Network interfaces

• Console and serial ports

The <seclabel> element controls the generation of security labels required by security drivers such as SELinux or AppArmor. These are not supported with vSIM VMs and therefore you must specify <seclabel type='none'> in the domain XML.