1. 27 Feb, 2017 1 commit
  2. 29 Sep, 2016 1 commit
    • Mike Hibler's avatar
      Performance improvements to the vnode startup path. · 87eed168
      Mike Hibler authored
      The bigest improvement happened on day one when I took out the 20 second sleep
      between vnode starts in bootvnodes. That appears to have been an artifact of
      an older time and an older Xen. Or, someone smarter than me saw the potential
      of getting bogged down for, oh say three weeks, trying to micro-optimize the
      process and instead just went for the conservative fix!
      
      Following day one, the ensuing couple of weeks was a long strange trip to
      find the maximum number of simultaneous vnode creations that could be done
      without failure. In that time I tried a lot of things, generated a lot of
      graphs, produced and tweaked a lot of new constants, and in the end, wound
      up with the same two magic numbers (3 and 5) that were in the original code!
      To distinguish myself, I added a third magic number (1, the loneliest of
      them all).
      
      All I can say is that now, the choice of 3 or 5 (or 1), is based on more
      solid evidence than before. Previously it was 5 if you had a thin-provisioning
      LVM, 3 otherwise. Now it is based more directly on host resources, as
      described in a long comment in the code, the important part of which is:
      
       #
       # if (dom0 physical RAM < 1GB) MAX = 1;
       # if (any swap activity) MAX = 1;
       #
       #    This captures pc3000s/other old machines and overloaded (RAM) machines.
       #
       # if (# physical CPUs <= 2) MAX = 3;
       # if (# physical spindles == 1) MAX = 3;
       # if (dom0 physical RAM <= 2GB) MAX = 3;
       #
       #    This captures d710s, Apt r320, and Cloudlab m510s. We may need to
       #    reconsider the latter since its single drive is an NVMe device.
       #    But first we have to get Xen working with them (UEFI issues)...
       #
       # else MAX = 5;
      
      In my defense, I did fix some bugs and stuff too (and did I mention
      the cool graphs?) See comments in the code and gitlab emulab/emulab-devel
      issue #148.
      87eed168
  3. 31 Aug, 2016 1 commit
  4. 01 Dec, 2015 1 commit
    • Leigh B Stoller's avatar
      Add an "interruptible" option to TBScriptLock(). When set, each time · 08ce72b6
      Leigh B Stoller authored
      through the loop we look to see if signals are pending, and if so we return
      early with an error. The caller (libvnode_xen) can use this to avoid really
      long waits, when the server has said to stop what its doing. For example, a
      vnode setup is waiting for an image lock, but the server comes along ands
      to stop setting up. Previously, we would wait for the lock, now we return
      early. This is to help with cancelation where it is nice if the server can
      stop a CreateSliver() in its tracks, when it is safe to do so.
      08ce72b6
  5. 27 Oct, 2015 1 commit
    • Leigh B Stoller's avatar
      Some fixes to ensure that vnodepreconfig can do all the same stuff at · 70c210e4
      Leigh B Stoller authored
      reboot that it does when the filesystems are first created, so as redo what
      might have been lost, say by prepare before snapshot. This required saving
      some private data in the non private section of the data blob we store to
      disk for each VM so that we have enough info to mount and fix the root FS
      of the node being rebooted.
      70c210e4
  6. 05 Mar, 2015 1 commit
  7. 25 Jul, 2014 1 commit
  8. 11 Jul, 2014 1 commit
  9. 22 Apr, 2014 1 commit
  10. 26 Mar, 2014 1 commit
  11. 07 Mar, 2014 1 commit
  12. 27 Feb, 2014 1 commit
  13. 26 Feb, 2014 1 commit
  14. 24 Jan, 2014 1 commit
  15. 16 Dec, 2013 1 commit
    • Leigh B Stoller's avatar
      Couple of fixes for XEN. · 8311c7f3
      Leigh B Stoller authored
      1. The backend process that starts the XEN vm (xl/xm) was not happy
         with the signal mask settings. By pass that for the vnodeboot call
         so that xl/xm sees a clean mask. The sympton was processes getting
         left behind.
      
      2. Watch for a XEN container being rebooted from inside, by waiting a
         little bit to see if comes back on its own. We used to fold right
         away, but now keep running.
      8311c7f3
  16. 19 Sep, 2013 1 commit
  17. 23 Jul, 2013 1 commit
  18. 30 Apr, 2013 1 commit
  19. 27 Feb, 2013 2 commits
  20. 30 Jan, 2013 1 commit
    • Kirk Webb's avatar
      Refactor generic vnode setup code a bit for OS independence · f7c51ea6
      Kirk Webb authored
      In order to hook in via the "generic vnode" path for setting up
      blockstores under FreeNAS, I've done a bit of shuffling in order to
      make things more OS-independent and reusable.
      
      * mkvnode.pl
      
      Moved to clientside/tmcc/common.  OS-dependent bits (really only some
      IPtables stuff) abstracted, and moved to tmcc/linux/libvnode.pm.
      
      * libvnode.pm
      
      Moved generic vnode stuff to a new module.  Moved miscellaneous
      utility functions to a new module.  Left OS-specific stuff.  Not
      really sure if what is left should be merged into libsetup/liblocsetup
      or left here - deferring this decision for now.
      
      * libgenvnode.pm
      
      New module currently containing generic vnode stuff.  Currently, the
      VNODE_* predicates are here.
      
      * libutil.pm
      
      New module containing miscellaneous utility functions (fatal,
      mysystem, mysystem2, setState, etc.)
      
      Files referencing libvnode.pm have been updated, as have the relevant
      Makefiles.
      f7c51ea6
  21. 03 Oct, 2012 1 commit
  22. 28 Sep, 2012 2 commits
  23. 25 Sep, 2012 1 commit
    • Leigh B Stoller's avatar
      Changes to support XEN shared nodes and guest snapshots. · 2489c09b
      Leigh B Stoller authored
      Snapshots are done a little differently then openvz of course, since
      there are potentially multiple disk partitions and a kernel. The basic
      operation is:
      
      1. Fire off reboot_prepare from boss. Changes to reboot_prepare result
         in the guest "halting" insted of rebooting.
      
      2. Fire off the create-image client script, which will take imagezips
         of all of the disks (except the swap partition), and grab a copy of
         the kernel. A new xm.conf file is written, and then the directory
         is first tar'ed and then we imagezip that bundle for upload.
      
      3. When booting a guest, we now look for guest images that are
         packaged in this way, although we still support the older method
         for backwards compatability. All of the disks are restored, and a
         new xm.conf created that points to the new kernel.
      2489c09b
  24. 24 Sep, 2012 1 commit
    • Eric Eide's avatar
      Replace license symbols with {{{ }}}-enclosed license blocks. · 6df609a9
      Eric Eide authored
      This commit is intended to makes the license status of Emulab and
      ProtoGENI source files more clear.  It replaces license symbols like
      "EMULAB-COPYRIGHT" and "GENIPUBLIC-COPYRIGHT" with {{{ }}}-delimited
      blocks that contain actual license statements.
      
      This change was driven by the fact that today, most people acquire and
      track Emulab and ProtoGENI sources via git.
      
      Before the Emulab source code was kept in git, the Flux Research Group
      at the University of Utah would roll distributions by making tar
      files.  As part of that process, the Flux Group would replace the
      license symbols in the source files with actual license statements.
      
      When the Flux Group moved to git, people outside of the group started
      to see the source files with the "unexpanded" symbols.  This meant
      that people acquired source files without actual license statements in
      them.  All the relevant files had Utah *copyright* statements in them,
      but without the expanded *license* statements, the licensing status of
      the source files was unclear.
      
      This commit is intended to clear up that confusion.
      
      Most Utah-copyrighted files in the Emulab source tree are distributed
      under the terms of the Affero GNU General Public License, version 3
      (AGPLv3).
      
      Most Utah-copyrighted files related to ProtoGENI are distributed under
      the terms of the GENI Public License, which is a BSD-like open-source
      license.
      
      Some Utah-copyrighted files in the Emulab source tree are distributed
      under the terms of the GNU Lesser General Public License, version 2.1
      (LGPL).
      6df609a9
  25. 29 Aug, 2012 1 commit
  26. 16 Aug, 2012 1 commit
  27. 17 Jul, 2012 1 commit
    • Leigh B Stoller's avatar
      Add tracking of control net mac addresses in the node_history. · bb66f52e
      Leigh B Stoller authored
      For InstaGeni, need to record and be able to search for history by
      control net mac address. We now record this in the node_history table,
      with corresponding change to the ShowNodeHistory web page.
      
      The backend changes required are that we 1) actually generate a mac
      address for VMs and stick it into the interfaces record, 2) return
      that mac from tmcd in the jailconfig, and 3) have the openvz library
      create the control net interface using that mac.
      
      On the openvz image, needed to switch to using a control network
      bridge for all interfaces (not just routable ones) so that traffic
      leaves the node with the correct mac.
      bb66f52e
  28. 05 Jul, 2012 2 commits
  29. 02 Jul, 2012 1 commit
  30. 06 Jun, 2012 1 commit
  31. 23 May, 2012 1 commit
  32. 17 Jan, 2012 1 commit
  33. 10 Jan, 2012 1 commit
  34. 09 Jan, 2012 1 commit
  35. 04 Jan, 2012 1 commit
    • Leigh B Stoller's avatar
      A big set of robustness changes to how vnodes are created and · 6991d85f
      Leigh B Stoller authored
      managed.
      
      * Try much harder to prevent broken VMs from getting left behind.
      
      * Try even harder to prevent left of state (devices, volumes, etc)
        from getting left behind once a VM breaks.
      
      * Store all the assorted bits of state we create in a file so that it
        it can be cleaned up later.
      
      * Watch for "stale" VMs that got left behind, using the UUID, which is
        regenerated each time an experiment is swapped in. Since we now
        store all the state that was associated with the stale VM, we can
        actually tear it down later. To do this by hand:
      
         node> sudo /usr/local/etc/emulab/mkvnode.pl -c pcvmXXX-YYY
      
      * Lots of changes to signal handling to avoid a common problem case;
        trying to reboot or halt a VM that is still setting up.
      6991d85f
  36. 19 Nov, 2011 1 commit
  37. 21 Jul, 2011 1 commit