1. 18 Dec, 2009 1 commit
    • Leigh B. Stoller's avatar
      Changes to support the SPP nodes. My approach was a little odd. · fd015646
      Leigh B. Stoller authored
      What I did was create node table entries for the three SPP nodes.
      These are designated as local, shared nodes, reserved to a holding
      experiment. This allowed me to use all of the existing shared node
      pool support, albeit with a couple of tweaks in libvtop that I will
      not bother to mention since they are hideous (another thing I need to
      The virtual nodes that are created on the spp nodes are figments; they
      will never be setup, booted or torn down. They exist simply as place
      holders in the DB, in order hold the reserved bandwidth on the network
      interfaces. In other words, you can create as many of these imaginary
      spp nodes (in different slices if you like) as there are interfaces on
      the spp node. Or you can create a single spp imaginary node with all
      of the interfaces. You get the idea; its the reserved bandwidth that
      drives the allocation.
      There are also some minor spp specific changes in vnode_setup.in to
      avoid trying to generalize things. I will return to this later as
      See this wiki page for info and sample rspecs:
  2. 29 Oct, 2009 1 commit
  3. 21 Oct, 2009 1 commit
  4. 20 Oct, 2009 1 commit
  5. 12 Oct, 2009 1 commit
    • David Johnson's avatar
      Add the ability to load images on virtnodes. For now, we just overload · c6c57bc9
      David Johnson authored
      the tb-set-node-os command with a second optional argument; if that is
      present, the first arg is the child OS and the second is the parent OS.
      We add some new features in ptopgen (OS-parentOSname-childOSname) based
      off a new table that maps which child OSes can run on which parents, and
      the right desires get added to match.  We setup the reloads in os_setup
      along with the parents.  Also needed a new opmode, RELOAD-PCVM, to handle
      all this.
      For now, users only have to specify that their images can run on pcvms, a
      special hack for which type the images can run on.  This makes sense in
      general since there is no point conditionalizing childOS loading on
      hardware type at the moment, but rather on parentOS.  Hopefully this stuff
      wiill mostly work on shared nodes too, although we'll have to be more
      aggressive on the client side garbage collecting old frisbee'd images for
      long-lived shared hosts.
      I only made these changes in libvtop, so assign_wrapper folks are left in
      the dark.
      Currently, the client side supports frisbee.  Only in openvz for now, and
      this probably breaks libvnode_xen.pm.  Also in here are some openvz
      improvements, like ability to sniff out which network is the public
      control net, and which is the fake virtual control net.
  6. 07 Oct, 2009 1 commit
  7. 29 Sep, 2009 1 commit
  8. 24 Sep, 2009 1 commit
  9. 16 Sep, 2009 1 commit
  10. 24 Aug, 2009 1 commit
  11. 07 Aug, 2009 1 commit
  12. 04 Aug, 2009 3 commits
  13. 20 Jul, 2009 1 commit
  14. 16 Jul, 2009 3 commits
  15. 15 Jul, 2009 1 commit
  16. 09 Jul, 2009 1 commit
  17. 07 Jul, 2009 1 commit
  18. 30 Jun, 2009 2 commits
  19. 28 Jun, 2009 1 commit
  20. 11 Jun, 2009 1 commit
    • Leigh B. Stoller's avatar
      Many many changes for supporting shared physical hosts on local · 4de4fcbc
      Leigh B. Stoller authored
      cluster nodes. Not going to try and describe all these changes.
      Note that I have not back ported this into the old assign wrapper. We
      move inexorably forward.
      Worth mentioning:
      * Users get VMs only on shared hosts.
      * Multiple experiments from multiple projects can share a node.
      * Nodes that are acting as shared hosts are in a holding experiment
        and have a tag in the reserved table. All of the links in the
        experiment are tied together in one giant super vlan. We then
        multipleax over that using our standard mechanisms (veths, vlans,
      * Lots of complication in the link setup code for dealing with links
        between a virtual node on a shared node, and a private physical
        node. Requires additional vlans and trunking between those
        interfaces. To make life easier, all of the links in the afore
        mentioned super vlan are trunked in dual mode.
      * I had to change Mike's code that does the encap determination, since
        openvz nodes cannot do veth encap. I add some new osfeatures
        (veth-ne, veth-en, and vlans).
      * On and on and on ...
  21. 18 May, 2009 1 commit
  22. 04 May, 2009 1 commit
    • Leigh B. Stoller's avatar
      Rob and I talked about regression testing last week, and we decided · e401c0f1
      Leigh B. Stoller authored
      that depending on different versions of assign to find the exact same
      solution on the same top/ptop, is asking for trouble. And in fact, the
      new assign is slightly different and the solutions do not match.
      So the idea we came up with is to first run the old version, and then
      fixnode the results for the input to the new version. assign should
      run cleanly and the results will be the same. Then reverse the
      situation and run the new version, then fixnode those results for a
      run of the old version. Then compare all the results.
  23. 01 May, 2009 1 commit
  24. 22 Apr, 2009 2 commits
  25. 21 Apr, 2009 1 commit
  26. 20 Apr, 2009 2 commits
  27. 17 Apr, 2009 1 commit
    • Leigh B. Stoller's avatar
      Add a "regression" mode to both the old assign_wrapper and the new · ecb66ab5
      Leigh B. Stoller authored
      mapper wrapper. In regression mode, the wrapper/mapper proceeds
      normally, creating a .vtop file, and then running assign with a fixed
      seed. If the wrapper and the mapper agree on the .vtop file, then the
      solution from assign should be identical.
      The wrapper/mapper then proceeds normally, reserving resources and
      making all the DB changes. Needless to say, this has to be on a
      private copy of the database, with all nodes free. Creating that DB
      was a tale in its own right.
      At completion, call the existing BackupPhysicalState() function that
      we use in swapmod, and write all the physical tables we have changed
      (just the rows corresponding to the experiment of course). The delete
      all that state, and free the nodes.
      If everything is working correctly, those physical tables should be
      identical when created by the mapper or the wrapper.
      Of course, its not quite there yet. I have a few things to fix up
      before diff -r produces no results.
  28. 16 Apr, 2009 1 commit
  29. 15 Apr, 2009 1 commit
  30. 13 Apr, 2009 1 commit
  31. 08 Apr, 2009 1 commit
  32. 06 Apr, 2009 1 commit
  33. 03 Apr, 2009 1 commit