core-admin/xen-vm-config/vm-template.conf

#
# This is a Xen VM config file for Qubes VM
# DO NOT EDIT - autogenerated by qubes tools
#

kernel="{kerneldir}/vmlinuz"
ramdisk="{kerneldir}/initramfs"
extra="ro nomodeset console=hvc0 rd_NO_PLYMOUTH {kernelopts}"
root="/dev/mapper/dmroot"
tsc_mode = 2

memory = {mem}
maxmem = {maxmem}
name = "{name}"

disk = [ {rootdev}
         {privatedev}
         {volatiledev}
         {otherdevs}
       ]

vif = [ {netdev} ]

pci = [ {pcidev} ]

vcpus = {vcpus}

on_poweroff = 'destroy'
on_reboot   = 'destroy'
on_crash    = 'destroy'
dom0: Generate Xen VM config file from common template, on each VM start Do not use many different config templates for different types of VMs. Also regenerate config on each VM start to keep in synchronized with qubes.xml 2011-06-06 01:43:52 +02:00			`#`
			`# This is a Xen VM config file for Qubes VM`
			`# DO NOT EDIT - autogenerated by qubes tools`
			`#`

			`kernel="{kerneldir}/vmlinuz"`
			`ramdisk="{kerneldir}/initramfs"`
Remove default runlevel from VM kernel parameters Runlevels are not used anymore with systemd (it uses target concept). Remove the parameter as it causes problems with archlinux template. 2013-05-04 05:27:33 +02:00			`extra="ro nomodeset console=hvc0 rd_NO_PLYMOUTH {kernelopts}"`
dom0: Generate Xen VM config file from common template, on each VM start Do not use many different config templates for different types of VMs. Also regenerate config on each VM start to keep in synchronized with qubes.xml 2011-06-06 01:43:52 +02:00			`root="/dev/mapper/dmroot"`
dom0: fix clock problems which caused VM hangs during boot (~#253) The source of problem was clockevent_program_event returns -ETIME: ------------ kernel/time/clockevents.c: /** * clockevents_program_event - Reprogram the clock event device. * @expires: absolute expiry time (monotonic clock) * * Returns 0 on success, -ETIME when the event is in the past. / int clockevents_program_event(struct clock_event_device dev, ktime_t expires, ktime_t now) ------------- xen_vcpuop_set_next_event schedules event by getting current time (xen_clocksource_read()) (1) adding delta (expires-now) and programming event with VCPUOP_set_singleshot_timer hypercall. Then xen gets current time (2) and in some rare cases this time is after expected timer expiration... Even after VCPUOP_set_singleshot_timer hypercal, xen_clocksource_read() reports time slightly in the past comparing to xen time (reported by NOW() macro). I think this is because "current" time is calculated different way in 1 and 2. The *1 way is controlled by tsc_mode, which is described here: http://lxr.xensource.com/lxr/source/docs/misc/tscmode.txt. Default tsc_mode=0 is "smart" and I think because of that can be slightly before NOW() time. tsc_mode=2 is almost the same as NOW() macro works. After all tsc_mode=2 was default in xen-3.4. 2011-08-31 22:08:24 +02:00			`tsc_mode = 2`
dom0: Generate Xen VM config file from common template, on each VM start Do not use many different config templates for different types of VMs. Also regenerate config on each VM start to keep in synchronized with qubes.xml 2011-06-06 01:43:52 +02:00
			`memory = {mem}`
			`maxmem = {maxmem}`
			`name = "{name}"`

			`disk = [ {rootdev}`
			`{privatedev}`
			`{volatiledev}`
dom0+vm: Update VM kernel mechanism (#242) Get kernel from global kernels dir (/var/lib/qubes/vm-kernels), not per-VM. Can be configured by qvm-prefs (kernel parameter). New tool: qvm-set-default-kernel For backward compatibility kernel=None means kernel in VM dir (kernels subdir). (possibly empty) modules.img should be created in it. 2011-06-30 01:07:47 +02:00			`{otherdevs}`
dom0: Generate Xen VM config file from common template, on each VM start Do not use many different config templates for different types of VMs. Also regenerate config on each VM start to keep in synchronized with qubes.xml 2011-06-06 01:43:52 +02:00			`]`

			`vif = [ {netdev} ]`

			`pci = [ {pcidev} ]`

			`vcpus = {vcpus}`

			`on_poweroff = 'destroy'`
			`on_reboot = 'destroy'`
			`on_crash = 'destroy'`