search for: domain_create_info

.../tools/ocaml/test/build_domain.ml Tue Nov 20 17:22:21 2012 +0000 @@ -0,0 +1,42 @@ +open Arg +open Printf +open Xentoollog +open Xenlight + +let _ = + let logger = Xentoollog.create_stdio_logger ~level:Xentoollog.Debug () in + let ctx = Xenlight.ctx_alloc logger in + let c_info = { + Xenlight.Domain_create_info.hap = None; + Xenlight.Domain_create_info.oos = None; + Xenlight.Domain_create_info.name = "Test; + } + and b_info = { + Xenlight.Domain_build_info.max_vcpus = 1; + Xenlight.Domain_build_info.avail_vcpus = [| |]; + Xenlight.Domain_build_info.cpumap = [| |]; + Xenlight.Domai...

Hi, I''ve installed xen-unstable 4.2 from actual git (last commit was 4dc7dbef5400f0608321d579aebb57f933e8f707). When I start a domU with xm all is fine include the cpu_weight I configured in my domU config. When I start the domU with xl then all my domU have the default cpu_weight of 256 instead of the configured one. Was the name of cpu_weight being changed for xl command ? My domU

Hi, I''ve installed xen-unstable 4.2 from actual git (last commit was 4dc7dbef5400f0608321d579aebb57f933e8f707). When I start a domU with xm all is fine include the cpu_weight I configured in my domU config. When I start the domU with xl then all my domU have the default cpu_weight of 256 instead of the configured one. Was the name of cpu_weight being changed for xl command ? My domU

The following series of patches fill in most of the gaps in the OCaml bindings to libxl, to make them useful for clients such as xapi/xenopsd (from XCP). There are a number of bugfixes to the existing bindings as well. I have an experimental version of xenopsd that successfully uses the new bindings. An earlier version of the first half of the series was submitted to the last by Ian Campbell on

The following series implements libxl_domain_config_init as per the libxl API requirement that each type has an init function. The first function does this in an open coded manner and is proposed for Xen 4.2. The second function is RFC only since it moves the definition of this type into the IDL and makes the required infrastructure updates to enable this. I think this is more 4.3 material at

This patch series is a reworking of a series developed by Mukesh Rathor at Oracle. The entirety of the design and development was done by him; I have only reworked, reorganized, and simplified things in a way that I think makes more sense. The vast majority of the credit for this effort therefore goes to him. This version is labelled v13 because it is based on his most recent series, v11.

The series introduces auto-generation of the type definitions used in the libxl interface followed by auto-generation of a destructor function for each type. In the future it may be possible to use the related data structures for other purposes, for example auto-generation of the functions to marshal between C and language binding data types. tools/_libxl_types.h should be identical both before