shaba/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2025-03-11 00:58:38 +03:00
Code Releases Activity
f64e658df0
libvirt/tests/xmconfigdata/test-paravirt-vcpu.cfg

15 lines
358 B
INI
Raw Normal View History

vcpu: improve vcpu support in xen command line This patch series focuses on xendConfigVersion 2 (xm_internal) and 3 (xend_internal), but leaves out changes for xenapi drivers. See this link for more details about vcpu_avail for xm usage. http://lists.xensource.com/archives/html/xen-devel/2009-11/msg01061.html This relies on the fact that def->maxvcpus can be at most 32 with xen. * src/xen/xend_internal.c (xenDaemonParseSxpr) (sexpr_to_xend_domain_info, xenDaemonFormatSxpr): Use vcpu_avail when current vcpus is less than maximum. * src/xen/xm_internal.c (xenXMDomainConfigParse) (xenXMDomainConfigFormat): Likewise. * tests/xml2sexprdata/xml2sexpr-pv-vcpus.sexpr: New file. * tests/sexpr2xmldata/sexpr2xml-pv-vcpus.sexpr: Likewise. * tests/sexpr2xmldata/sexpr2xml-pv-vcpus.xml: Likewise. * tests/xmconfigdata/test-paravirt-vcpu.cfg: Likewise. * tests/xmconfigdata/test-paravirt-vcpu.xml: Likewise. * tests/xml2sexprtest.c (mymain): New test. * tests/sexpr2xmltest.c (mymain): Likewise. * tests/xmconfigtest.c (mymain): Likewise.
2010-10-05 08:18:52 -06:00
name = "XenGuest1"
uuid = "c7a5fdb0-cdaf-9455-926a-d65c16db1809"
maxmem = 579
memory = 394
Xen: support maxvcpus in xm and xl config From: Ian Campbell <ian.campbell@citrix.com> xend prior to 4.0 understands vcpus as maxvcpus and vcpu_avail as a bit map of which cpus are online (default is all). xend from 4.0 onwards understands maxvcpus as maxvcpus and vcpus as the number which are online (from 0..N-1). The upstream commit (68a94cf528e6 "xm: Add maxvcpus support") claims that if maxvcpus is omitted then the old behaviour (i.e. obeying vcpu_avail) is retained, but AFAICT it was not, in this case vcpu==maxcpus==online cpus. This is good for us because handling anything else would be fiddly. This patch changes parsing of the virDomainDef maxvcpus and vcpus entries to use the corresponding 'maxvcpus' and 'vcpus' settings from xm and xl config. It also drops use of the old Xen 3.x 'vcpu_avail' setting. The change also removes the maxvcpus limit of MAX_VIRT_VCPUS (since maxvcpus is simply a count, not a bit mask), which is particularly crucial on ARM where MAX_VIRT_CPUS == 1 (since all guests are expected to support vcpu placement, and therefore only the boot vcpu's info lives in the shared info page). Existing tests adjusted accordingly, and new tests added for the 'maxvcpus' setting.
2015-12-15 14:47:40 -07:00
maxvcpus = 4
vcpus = 2
Xen: Fix <clock> handling 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: Philipp Hahn <hahn@univention.de>
2012-02-08 17:32:34 +01:00
localtime = 0
vcpu: improve vcpu support in xen command line This patch series focuses on xendConfigVersion 2 (xm_internal) and 3 (xend_internal), but leaves out changes for xenapi drivers. See this link for more details about vcpu_avail for xm usage. http://lists.xensource.com/archives/html/xen-devel/2009-11/msg01061.html This relies on the fact that def->maxvcpus can be at most 32 with xen. * src/xen/xend_internal.c (xenDaemonParseSxpr) (sexpr_to_xend_domain_info, xenDaemonFormatSxpr): Use vcpu_avail when current vcpus is less than maximum. * src/xen/xm_internal.c (xenXMDomainConfigParse) (xenXMDomainConfigFormat): Likewise. * tests/xml2sexprdata/xml2sexpr-pv-vcpus.sexpr: New file. * tests/sexpr2xmldata/sexpr2xml-pv-vcpus.sexpr: Likewise. * tests/sexpr2xmldata/sexpr2xml-pv-vcpus.xml: Likewise. * tests/xmconfigdata/test-paravirt-vcpu.cfg: Likewise. * tests/xmconfigdata/test-paravirt-vcpu.xml: Likewise. * tests/xml2sexprtest.c (mymain): New test. * tests/sexpr2xmltest.c (mymain): Likewise. * tests/xmconfigtest.c (mymain): Likewise.
2010-10-05 08:18:52 -06:00
on_poweroff = "destroy"
on_reboot = "restart"
on_crash = "restart"
vif = [ "mac=00:16:3e:66:94:9c,bridge=br0,script=vif-bridge" ]
xenconfig: move <os> parsing/formating to config-specific 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.
2015-03-19 18:28:49 -06:00
bootloader = "/usr/bin/pygrub"
tests: xmconfigtest: add tests for cmdline formating Commit 656151bf fixed formatting of the <cmdline> element. Perhaps it would have been noticed and fixed earlier if we had a test. With this change, all possible cases of formatting <cmdline> from xmconfig are covered 1. no 'extra=' or 'root=' in xm.cfg 2. 'extra=' but no 'root=' in xm.cfg 3. 'root=' but no 'extra=' in xm.cfg 4. both 'root=' and 'extra=' in xm.cfg Case 1 is covered by all existing paravirt tests since they have no 'extra=' or 'root='. Case 2 is covered by adding 'extra=' to a few of the existing paravirt tests. Cases 3 and 4 are covered by new tests that only test conversion of xm.cfg to xml. Signed-off-by: Jim Fehlig <jfehlig@suse.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2018-05-23 15:09:45 -06:00
extra = "console=hvc0"
src/xenconfig: wrap common formatting code Wrap formatting code common to xm and xl in xenFormatConfigCommon and export it. Signed-off-by: Kiarie Kahurani <davidkiarie4@gmail.com> Signed-off-by: Jim Fehlig <jfehlig@suse.com>
2014-08-12 00:21:35 +03:00
disk = [ "phy:/dev/HostVG/XenGuest1,xvda,w" ]
Copy Permalink