libxl supports setting the domain real time clock to local time or
UTC via the localtime field of libxl_domain_build_info. Adjustment
of the clock is also supported via the rtc_timeoffset field. The
libvirt libxl driver has never supported these settings, instead
relying on libxl's default of a UTC real time clock with adjustment
set to 0.

There is at least one user that would like the ability to change
the defaults

https://www.redhat.com/archives/libvirt-users/2018-February/msg00059.html

Add support for specifying a local time clock and for specifying an
adjustment for both local time and UTC clocks. Add a test case to
verify the XML to libxl_domain_config conversion.

Local time clock and clock adjustment is already supported by the
XML <-> xl.cfg converter. What is missing is an explicit test for
the conversion. There are plenty of existing tests that all use UTC
with 0 adjustment. Hijack test-fullvirt-tsc-timer to test a local
time clock with 1 hour adjustment.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Some of the test configuration files in tests/xlconfigdata
use the old qemu-dm as the emulator. Many of the configuration
features tested (spice, rbd, multi-usb) are not even usable with
the old qemu. Change these files to use the new qemu-xen (also
known as qemu upstream) emulator.

Note: This change fixes xlconfigtest failures when the old
qemu is actually installed on the system. During device post
parse, the libxl driver attempts to invoke the emulator to
determine if it is the old or new qemu so it can properly set
video RAM defaults. With the old qemu installed, the default
video RAM was set differently than the expected value.
Changing all the test data files to use qemu-xen ensures
predictable results wrt default video RAM size.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

hap is enabled by default in xm and xl config and usually only
specified when it is desirable to disable hap (hap = 0). Change
the xm,xl <-> xml converter to behave similarly. I.e. only
produce 'hap = 0' when <hap state='off'/> and vice versa.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

The most formal form of xl disk configuration uses key=value
syntax to define each configuration item, e.g.

format=raw, vdev=xvda, access=rw, backendtype=phy, target=disksrc

Change the xl disk formatter to produce this syntax, which allows
target= to contain meta info needed to setup a network-based
disksrc (e.g. rbd, nbd, iscsi). For details on xl disk config
format, see  $xen-src/docs/misc/xl-disk-configuration.txt

Update the disk config in the tests to use the formal syntax.
But add tests to ensure disks specified with the positional
parameter syntax are correctly converted to <disk> XML.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

Both xm and xl config have long supported specifying vif rate
limiting, e.g.

vif = [ 'mac=00:16:3E:74:3d:76,bridge=br0,rate=10MB/s' ]

Add support for mapping rate to and from <bandwidth> in the xenconfig
parser and formatter. rate is mapped to the required 'average' attribute
of the <outbound> element, e.g.

  <interface type='bridge'>
    ...
    <bandwidth>
      <outbound average='10240'/>
    </bandwidth>
  </interface>

Also add a unit test to check the conversion logic.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

Change all tests to use the latest XEND_CONFIG_VERSION
(XEND_CONFIG_VERSION_3_1_0 = 4). Fix tests that do not conform to
the latest version.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

In xl config, hvmloader is implied for hvm guests.  It is not
specified with the "kernel" option like xm config.  The "kernel"
option, along with "ramdisk" and "extra", is used for HVM direct
kernel boot.  Instead of using "kernel" option to populate
virDomainDef object's os.loader->path, use hvmloader discovered
when gathering capabilities.

This change required fixing initialization of capabilities in
the test utils and removing 'kernel = "/usr/lib/xen/boot/hvmloader"'
from the test config files.

xl and xm differ a bit in how <os> configuration is represented.
E.g. xl config supports <os><nvram .../></os> via its "bios"
setting.

Move the xenParseOS and xenFormatOS functions from xen_common.c
and copy to xen_xl.c and xen_xm.c so they can be customized for
xm vs xl config.  An unfortunate fallout is reordering of entries
in the test config files.

Add disk and spice config tests for the xen_xl config parser
Signed-off-by: NKiarie Kahurani <davidkiarie4@gmail.com>
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

Wrap formatting code common to xm and xl in xenFormatConfigCommon
and export it.
Signed-off-by: NKiarie Kahurani <davidkiarie4@gmail.com>
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

XenD-3.1 introduced managed domains. HV-domains have rtc_timeoffset
(hgd24f37b31030 from 2007-04-03), which tracks the offset between the
hypervisors clock and the domains RTC, and is persisted by XenD.
In combination with localtime=1 this had a bug until XenD-3.4
(hg5d701be7c37b from 2009-04-01) (I'm not 100% sure how that bug
manifests, but at least for me in TZ=Europe/Berlin I see the previous
offset relative to utc being applied to localtime again, which manifests
in an extra hour being added)

XenD implements the following variants for clock/@offset:
- PV domains don't have a RTC → 'localtime' | 'utc'
- <3.1: no managed domains → 'localtime' | 'utc'
- ≥3.1: the offset is tracked for HV → 'variable'
        due to the localtime=1 bug → 'localtime' | 'utc'
- ≥3.4: the offset is tracked for HV → 'variable'

Current libvirtd still thinks XenD only implements <clock offset='utc'/>
and <clock offset='localtime'/>, which is wrong, since the semantic of
'utc' and 'localtime' specifies, that the offset will be reset on
domain-restart, while with 'variable' the offset is kept. (keeping the
offset over "virsh edit" is important, since otherwise the clock might
jump, which confuses certain guest OSs)

xendConfigVersion was last incremented to 4 by the xen-folks for
xen-3.1.0. I know of no way to reliably detect the version of XenD
(user space tools), which may be different from the version of the
hypervisor (kernel) version! Because of this only the change from
'utc'/'localtime' to 'variable' in XenD-3.1 is handled, not the buggy
behaviour of XenD-3.1 until XenD-3.4.

For backward compatibility with previous versions of libvirt Xen-HV
still accepts 'utc' and 'localtime', but they are returned as 'variable'
on the next read-back from Xend to libvirt, since this is what XenD
implements: The RTC is NOT reset back to the specified time on next
restart, but the previous offset is kept.
This behaviour can be turned off by adding the additional attribute
adjustment='reset', in which case libvirt will report an error instead
of doing the conversion. The attribute can also be used as a shortcut to
offset='variable' with basis='...'.

With these changes, it is also necessary to adjust the xen tests:

"localtime = 0" is always inserted, because otherwise on updates the
value is not changed within XenD.

adjustment='reset' is inserted for all cases, since they're all <
XEND_CONFIG_VERSION_3_1_0, only 3.1 introduced persistent
rtc_timeoffset.

Some statements change their order because code was moved around.
Signed-off-by: NPhilipp Hahn <hahn@univention.de>

Recent versions of Xen disable the virtual HPET by default.  This is
usually more precise because tick policies are not implemented for
the HPET in Xen.  However, there may be several reasons to control
the HPET manually: 1) to test the emulation; 2) because distros may
provide the knob while leaving the default to "enabled" for compatibility
reasons.

This patch provides support for the hpet item in both sexpr and xm
formats, and translates it to a <timer> element.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

The most common cause of errors with rhel5-api turn on was missing
"(type ioemu)" in sexpr or its equivalent in XM configuration file. This
happens because the presence of that part in sexpr (or cfg) depends on
xen version the host is running. Let's avoid it by explicitly specifying
interface model which ensures "type ioemu" will always be emitted.

This patch adds

    <model type='e1000'/>

withing the interface element in all affected xml files. And

    (model 'e1000')

to all corresponding sexpr files with similar fix to cfg files. Such
configuration works regardless on Xen version.