1. 12 May, 2011 1 commit
  2. 25 Mar, 2011 1 commit
  3. 21 Apr, 2010 1 commit
  4. 25 Aug, 2009 1 commit
    • Keir Fraser's avatar
      xend: Add support for URI ('file:' and 'data:' scheme) for PV/kernel · 8b72d820
      Keir Fraser authored
      and PV/ramdisk
      Add support for 'file:' and 'data:' URI schemes for the parameters
      'PV/kernel' and 'PV/ramdisk' in the VM.create() call. The 'data:'
      scheme handling enables using a file which is stored inside the
      management system (from where the XenAPI call is send) as kernel or
      o all included: a detailed description can be found in the xenapi
      o bumped up the version of the API document to 1.0.8 (because of
      (minimal) interface extension)
      o Future enhancements (like http:, ftp: schemes) fit seamlessly into
      the current design / classes
      o Unittest cases and xm-test case included
      Signed-off-by: default avatarAndreas Florath <xen@flonatel.org>
  5. 20 Aug, 2009 3 commits
  6. 05 Aug, 2009 5 commits
  7. 02 Aug, 2009 1 commit
  8. 29 Jul, 2009 1 commit
  9. 24 Jun, 2009 1 commit
  10. 06 Mar, 2009 1 commit
  11. 03 Jul, 2008 1 commit
    • Keir Fraser's avatar
      xm-test: Remove a policy reset from acm test case · 05af3b70
      Keir Fraser authored
      Remove the resetting of the policy from this point in the test case
      since the new default policy has the '__UNLABELED__' label, which is
      not expected in subsequent checks.
      Signed-off-by; Stefan Berger <stefanb@us.ibm.com>
  12. 30 Jun, 2008 1 commit
  13. 08 May, 2008 1 commit
  14. 03 Mar, 2008 1 commit
  15. 17 Jan, 2008 1 commit
    • Keir Fraser's avatar
      tools/docs: Fix example and default IP addresses. · 487e884d
      Keir Fraser authored
      In various places in documentation and code, IP addresses are provided
      as examples, defaults, or dummy configuration.  In general the
      specific IP addresses used in Xen are not always appropriate.  (For
      example, is used in a few places!)
      The following addresses should be used:
       * For examples and documentation,  (See RFC3330.)
       * For defaults for private networks, a random network from RFC1918.
         I have randomly selected for this purpose and
         documented this in at the only registry I know of,
         www.ucam.org/cam-grin.  This network should henceforth be used for
         default configurations of local bridges, test networks, etc. in
         Xen tools.
      The following addresses should NOT be used:
       * 10.0.*.*, 10.1.*.*, 192.168.0.*, 192.168.1.*, etc.  Using these
         addresses gives greatly increased likelihood of collision, as
         ignorant network administrators and reckless middlebox vendors
         often pick networks from the bottom of 10/8 and 192.168/16.
       * 169.254.*.*.  These are reserved for zeroconf (ad-hoc networking)
         and should not be used for Xen private networks, bridges, etc.,
         etc.  Use of these addresses by Xen scripts causes trouble on hosts
         (eg laptops) which find themselves in ad-hoc networking
         environments.  I think this is not hypothetical (!) since at least
         one Linux distribution have specific code to detect this case and
         cause Xen startup to fail iff the host already has an external
         zeroconf address.
       *  WTF !?
      I have also used in one place where apparently a dummy
      address is needed (some Linux kernels won't accept a lack of an NFS
      server address).  If is mistakenly used it is unlikely
      to do any damage to real traffic even if it does escape into the
      network at large.
      Signed-off-by: default avatarIan Jackson <ian.jackson@eu.citrix.com>
  16. 20 Dec, 2007 1 commit
  17. 10 Dec, 2007 1 commit
  18. 08 Dec, 2007 1 commit
  19. 06 Dec, 2007 1 commit
  20. 05 Dec, 2007 1 commit
    • Keir Fraser's avatar
      Implement legacy XML-RPC interface for ACM commands. · f01a7260
      Keir Fraser authored
      This patch implements a (non Xen-API) legacy XML-RPC interface for the
      ACM commands and funnels the calls into code introduced by the Xen-API
      support for ACM security management. Since some of the functionality
      has changed, also the xm applications have changed. In particular the
      following old commands have been removed along with some tools the
      have become obsolete now:
      - loadpolicy    (included in: setpolicy)
      - makepolicy    (included in: setpolicy)
      - cfgbootpolicy (included in: setpolicy)
      and the following commands been introduced:
      - setpolicy
      - getpolicy
      - resetpolicy
      All tools have been adapted to work in Xen-API and legacy XML-RPC
      mode. Both modes support the same functionality.
      Signed-off-by: default avatarStefan Berger <stefanb@us.ibm.com>
  21. 25 Oct, 2007 1 commit
    • Keir Fraser's avatar
      xm-test: various fixes · 43db4bd6
      Keir Fraser authored
      - recently I added an other_config field to the VTPM record which now
      needs to be accounted for otherwise the test determines a bad key
      - the dry-run command was throwing a different type of exception
      (ACMError) than what was caught (XSMError)
      - the tests based on the raw Xen-API need to build the PV_args
      parameters from the old 'root' and 'extra' parameters.
      Signed-off-by: default avatarStefan Berger <stefanb@us.ibm.com>
  22. 19 Oct, 2007 1 commit
  23. 02 Oct, 2007 1 commit
  24. 20 Sep, 2007 1 commit
  25. 11 Sep, 2007 1 commit
  26. 06 Sep, 2007 1 commit
  27. 12 Aug, 2007 1 commit
  28. 30 Jul, 2007 1 commit
    • kfraser's avatar
      [ACM] Some more fixes · cf1629c9
      kfraser authored
       - don't reload the policy if it has been loaded
       - don't always load the policy in the test suite when the policy is
         already loaded
       - skip tests 07 and 09 when ACM is not enabled and xm is not using the
       - fix a problem when trying to remove an invalid label
      Signed-off-by: default avatarStefan Berger <stefanb@us.ibm.com>
  29. 18 Jul, 2007 1 commit
  30. 17 Jul, 2007 1 commit
  31. 06 Jul, 2007 1 commit
  32. 24 May, 2007 1 commit
    • kfraser's avatar
      xm-test: ia64 min memory & arbitrarily large ramdisk · 5b482c9a
      kfraser authored
      1) Sets a minimum of 128MB RAM for an ia64 domU; this limit was set
      after experimentation, which seems to indicate it's a reasonable lower
      limit (the 32MB limit previously in place did not allow an ia64 domU
      to start).  If there's any problem with this, I don't mind splitting
      the patch and sending it to the ia64 list, but it was small, so I hope
      it's okay to include it.
      2) xm-test uses ramdisks built with uClibc, which doesn't compile on
      ia64.  I was able to create a ramdisk by hand, but as it was too
      large, the resultant domU crashed after boot.  This patch enables the
      use of an arbitrarily large ramdisk, so long as it's uncompressed.  As
      xm-test builds only uncompressed ramdisks, I figured this was
      reasonable for that specific application.  Suggestions on how to
      detect and handle a compressed ramdisk would be welcome.
      Signed-off-by: default avatarAlex Williamson <alex.williamson@hp.com>
  33. 26 Apr, 2007 2 commits