Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Commits on Oct 5, 2012
Commits on Aug 24, 2012
  1. @djs55

    If Xenctrl.domain_set_mmap_limit fails, log and continue

    djs55 authored
    For an undiagnosed reason, this fails on xen-4.2
    Signed-off-by: David Scott <>
  2. @djs55

    Update to the Xen-4.2 interface (deactived by #ifdefs)

    djs55 authored
    We now have:
     * configurable xenstore and console backend domids
     * incrementable VM generation counts
    This is all disabled by #ifdef XENGUEST_4_2 for now.
    Signed-off-by: David Scott <>
Commits on Aug 16, 2012
  1. @robhoes

    CA-88283/CA-88859: Exclude dom0 from any squeeze activity

    robhoes authored
    This means that squeezed will never attempt to balloon down dom0.
    Signed-off-by: Rob Hoes <>
Commits on Aug 14, 2012
  1. CA-85776: Improve parsing of bootloader errors.

    eliloader should now always throw a RuntimeError in line with pygrub,
    so we now look for that in the stacktrace and raise the rest of the
    stacktrace as an error message.
    Signed-off-by: John Else <>
Commits on Aug 9, 2012
  1. Merge pull request #820 from djs55/CA-88488

    xen-git authored
  2. @djs55

    CA-88267: if a critical xenstore key is missing, the udev vif script …

    djs55 authored
    …will signal failure
    Rather than ignoring keys (such as vm/uuid) which should always be
    present, the udev script will log the problem and signal the error
    directly to the toolstack by writing
      hotplug-error = some error string
    Signed-off-by: David Scott <>
  3. @djs55

    CA-88488: VM.reboot still exposed transient states where VBDs,VIFs we…

    djs55 authored
    …re unplugged
    A VBD or VIF is said to be 'active' while it is associated with a VM
    even over a reboot. Unfortunately the record of which devices are 'active'
    was stored in xenstore and deleted during the destroy phase of a reboot.
    We now delay the deletion of the /vm/<uuid> tree until the VM metadata
    is removed from xenopsd.
    Signed-off-by: David Scott <>
Commits on Aug 6, 2012
  1. @mietek

    CA-86568: Kill only the vncterm parent process

    mietek authored
    Do not kill the process group.
    vncterm will now catch SIGTERM, pass it on to its child process,
    wait for it to exit, clean up, and finally exit itself.
Commits on Jul 31, 2012
  1. @djs55

    CA-87324: simulate VBD eject/insert as plug/unplug in xapi rather tha…

    djs55 authored
    …n xenopsd
    Simulating this in xenopsd leads to states where a VDI has been
    ejected but the device is still 'active' and therefore 'currently_attached=true'
    Although this is self-consistent, it confuses xapi and the regression
    tests using the XenAPI. Instead we fall back to transforming eject into
    unplug and insert into plug at the XenAPI level.
    Signed-off-by: David Scott <>
  2. @djs55

    CA-87324: return whether a VM is running HVM in VM.stat

    djs55 authored
    Signed-off-by: David Scott <>
  3. @djs55

    CA-87324: a non-existent xenstore device doesn't require any maintena…

    djs55 authored
    …nce action
    So 'device_action_request' should return None rather than throwing an exception.
    Signed-off-by: David Scott <>
Commits on Jul 26, 2012
  1. @djs55

    CA-85940: Use xenstore rather than the VmExtra for active_{vbds,vifs}

    djs55 authored
    Changing the VmExtra effectively changes the migrate protocol, which
    is a bad idea at this point in the development cycle.
    We also automatically delete the VBD and VIF metadata from xenopsd
    when currently_attached is set to false. To make this work we:
      1. set currently_attached to true in Xapi_xenops.start
      2. only push down currently_attached VBDs and VIFs in the Xenopsd_metadata
    Signed-off-by: David Scott <>
  2. @djs55

    CA-85940: when "cancelling" a xenguest subprocess, raise the Cancelle…

    djs55 authored
    …d exception
    Signed-off-by: David Scott <>
  3. @djs55

    CA-85940: add the concept of 'active' VBDs and VIFs to xenopsd

    djs55 authored
    During a VM.start we set all VBDs and VIFs to active. Within
    xenopsd a {VBD,VIF}.plug will be ignored if the device is not
    active. This means that on resume, when we bring back exactly
    those devices which were marked as "active" at the time of
    the preceeding VM.start.
    We now distinguish between a VBD_plug as part of a compound
    operation and a user-requested VBD_hotplug, where the latter
    also makes the device active.
    We set XenAPI {VIF,VBD}.currently_attached = active || plugged
     -- this means that on suspend, currently_attached stays true
        since we never set active to "false"
    Unfortunately the active flags get wiped in the middle of a
    reboot, so a reboot behaves the same way as a start i.e. it
    connects all devices, not just those which were connected before
    the shutdown.
    Signed-off-by: David Scott <>
  4. @djs55

    CA-85940: add a test-case to check each "cancel point"

    djs55 authored
    The test-case measures the number of "cancel points" traversed by
    each lifecycle operation. It then checks that, if a "cancel point"
    is triggered, that the system ends up getting into a valid state.
    In particular it looks for:
     * xen domains and devices
     * xenopsd VM metadata
     * xapi VM metadata
    all being in sync.
    Run the test on an arbitrary test VM as follows (in dom0):
    /root/cancel_tests -pw <password> -vm <VM name>
    Signed-off-by: David Scott <>
  5. @djs55

    CA-85940: never directly remove VIF/VBD metadata in failure paths

    djs55 authored
    A background thread constantly synchronises XenAPI metadata with xenopsd
    metadata, so it doesn't make sense to remove objects which will be
    immediately re-added.
    It is ok to 'refresh' the metadata in a {VIF,VBD}.plug operation.
    Redefinite what 'plugged' means for VIFs so that a VIF is always
    plugged while there is still pending cleanup action (e.g. in xenstore).
    This avoids a cancelled unplug leaving stale state lying around.
    Clarify the "epoch_{begin,end}" APIs -- these need to know the disk
    but not the whole Vbd.t
    Signed-off-by: David Scott <>
  6. @djs55

    CA-85940: VIF.unplug now passes the cancellation test

    djs55 authored
    This required a redefinition of what "plugged" means.
    We now consider a VIF to be "plugged" if the resources
    are still allocated by the host, as reflected by
    in xenstore.
    When the udev remove event fires and the "hotplug-status"
    node is removed, we consider the device as needing an
    explicit unplug via the "device action request" mechanism.
    Signed-off-by: David Scott <>
  7. @djs55

    CA-85940: xenopsd can now be set to trigger the cancellation of a tas…

    djs55 authored
    …k at a numbered cancellation point
    This allows a test harness to verify that cancellation is safe.
    Signed-off-by: David Scott <>
  8. @djs55

    CA-85940: add a Task.debug_info (string * string list) and return the…

    djs55 authored
    … number of "cancel points" seen
    The Task.debug_info can be used to return arbitrary data without
    officially extending (and polluting) the interface.
    The number of "cancel points" refers to the number of times the
    task could have been cancelled.
    Signed-off-by: David Scott <>
  9. @djs55

    CA-85940: rename Task.debug_info to Task.dbg for consistency

    djs55 authored
    We use the argument name "dbg" to refer to the debug token passed
    along with each API call. This value is then stored in the Task.dbg
    Signed-off-by: David Scott <>
  10. @djs55

    CA-85940: add "on failure" code to all the VM lifecycle operations

    djs55 authored
    After a partial failure (e.g. arbitrary process restart) xenopsd always
    leaves each VM in a state which is either
      * clearly marked as broken ("domain action request = poweroff")
      * intact (Running, Paused, Suspended etc)
    Therefore all we need to do after detecting a failure (or a restart)
    is to trigger a {VM,VBD,VIF,PCI}_check_state operation, which will
    then enqueue the appropriate corrective action i.e.
      * VM_poweroff if broken
      * nothing if intact
    In particular we should not try to perform bespoke, per-operation
    cleanup (e.g. VM_start -> VM_poweroff). Instead we simply invoke
    the correct trigger.
    Signed-off-by: David Scott <>
  11. @djs55

    CA-85940: log when we're about to raise a task Cancelling exception

    djs55 authored
    Signed-off-by: David Scott <>
Commits on Jul 25, 2012
Commits on Jul 24, 2012
  1. CA-81449: Take VCPUs_at_startup into account when starting a guest.

    Previously we were creating all the CPU devices as online.
    n.b. adding the "online" option to Device.Vcpu.add means it's
    functionally identical to Device.Vcpu.set
    Signed-off-by: John Else <>
Commits on Jul 23, 2012
  1. @djs55

    CA-86756: attempt to return Unix signal names rather than ocaml signa…

    djs55 authored
    …l numbers
    Signed-off-by: David Scott <>
Commits on Jul 19, 2012
  1. @jonludlam

    CA-86270: Remove VBDs from xenopsd when they're destroyed by xapi

    jonludlam authored
    Specifically the case where this currently fails is when ejecting
    a CD from a PV guest then destroying it.
    Signed-off-by: Jon Ludlam <>
Commits on Jul 18, 2012
  1. @djs55

    CA-85940: use the creation time measured with a monotonic clock to ju…

    djs55 authored
    …dge which domain is "newer" for a given UUID
    The previous metric (whether a VM had clocked up CPU time or not)
    would be confused if neither domain had started.
    Signed-off-by: David Scott <>
  2. @djs55

    CA-85224: ensure qemu watch "cancel paths" are unique per qemu instance

    djs55 authored
    Rather than determining the path based solely on the domain containing
    the qemu, use both the qemu domain and the guest domain id.
    This avoids two concurrent suspend/resumes from cancelling each other
    by accident (!)
    Signed-off-by: David Scott <>
  3. @jonludlam

    CA-86263: Revert patch for CA-85191.

    jonludlam authored
    The patch that's been reverted cancelled outstanding watches for devices
    associated with a domain when the domain was destroyed. However, the watches
    are for dom0 events which should not be dependent on the state of the
    domU. In the case where the original problem was identified, the domU had
    crashed and been left paused, leaving the devices up. The watches waiting
    for the backends to go away timed out, which is actually not unreasonable
    given that the backends still existed at that point.
    Signed-off-by: Jon Ludlam <>
Commits on Jul 13, 2012
  1. @rokstrnisa

    Adapted xen-api code to the changes in xenctrl (namespaces).

    rokstrnisa authored
    Signed-off-by: Rok Strnisa <>
Commits on Jul 11, 2012
Something went wrong with that request. Please try again.