libvirt currently clamps the maximum number of vcpus to MAX_VIRT_CPUS == XEN_LEGACY_MAX_VCPUS, which on ARM is 1 (because all guests are expected to support vcpu info placement). Even on x86 this limitation is a hold over from an older xm interface where the maximum number of vcpus was expressed as a bitmap and so limited to the number of bits in an unsigned long (for which XEN_LEGACY_MAX_VCPUS is a convenient proxy), which doesn't apply to xl on x86 which uses a bitmap data type to express larger bitmaps. To do this it was necessary to add a new value to xenConfigVersionEnum corresponding to this new version. I've tested with tests/x?configtest (including new test case) on x86 and on ARM with xlconfigtest and via domxml-from-native. As you might infer from some of the changlogs I feel a bit like I am abusing xendConfigVersion somewhat here (given that xl != xend, and that real xend never went passed xend_config_version) but its use is quite widespread in the common xl/xm support code in libvirt so a great deal of refactoring/renaming would otherwise seem to be required. I'm open to other ideas or suggestions though. Ian. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list