1. 15 7月, 2019 1 次提交
  2. 11 7月, 2019 2 次提交
    • D
      vz: acquire a pidfile in the driver root directory · 7cefe611
      Daniel P. Berrangé 提交于
      When we allow multiple instances of the driver for the same user
      account, using a separate root directory, we need to ensure mutual
      exclusion. Use a pidfile to guarantee this.
      
      In privileged libvirtd this ends up locking
      
         /var/run/libvirt/vz/driver.pid
      
      In unprivileged libvirtd this ends up locking
      
        /run/user/$UID/libvirt/vz/run/driver.pid
      
      NB, the latter can vary depending on $XDG_RUNTIME_DIR
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      7cefe611
    • E
      snapshot: Add VIR_DOMAIN_SNAPSHOT_CREATE_VALIDATE flag · 95f8e323
      Eric Blake 提交于
      We've been doing a terrible job of performing XML validation in our
      various API that parse XML with a corresponding schema (we started
      with domains back in commit dd69a14f, v1.2.12, but didn't catch all
      domain-related APIs, didn't document the use of the flag, and didn't
      cover other XML). New APIs (like checkpoints) should do the validation
      unconditionally, but it doesn't hurt to continue retrofitting existing
      APIs to at least allow the option.
      
      While there are many APIs that could be improved, this patch focuses
      on wiring up a new snapshot XML creation flag through all the
      hypervisors that support snapshots, as well as exposing it in 'virsh
      snapshot-create'.  For 'virsh snapshot-create-as', we blindly set the
      flag without a command-line option, since the XML we create from the
      command line should generally always comply (note that validation
      might cause failures where it used to succeed, such as if we tighten
      the RNG to reject a name of '../\n'); but blindly passing the flag
      means we also have to add in fallback code to disable validation if
      the server is too old to understand the flag.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Acked-by: NPeter Krempa <pkrempa@redhat.com>
      95f8e323
  3. 28 5月, 2019 1 次提交
  4. 09 5月, 2019 2 次提交
  5. 17 4月, 2019 5 次提交
  6. 22 3月, 2019 2 次提交
    • E
      snapshot: Rename virDomainSnapshotObjPtr · e055a816
      Eric Blake 提交于
      Now that the core of SnapshotObj is agnostic to snapshots and can be
      shared with upcoming checkpoint code, it is time to rename the struct
      and the functions specific to list operations. A later patch will
      shuffle which file holds the common code. This is a fairly mechanical
      patch.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
      e055a816
    • E
      snapshot: Drop virDomainSnapshotDef.current · f1056279
      Eric Blake 提交于
      The only use for the 'current' member of virDomainSnapshotDef was with
      the PARSE/FORMAT_INTERNAL flag for controlling an internal-use
      <active> element marking whether a particular snapshot definition was
      current, and even then, only by the qemu driver on output, and by qemu
      and test driver on input. But this duplicates vm->snapshot_current,
      and gets in the way of potential simplifications to have qemu store a
      single file for all snapshots rather than one file per snapshot.  Get
      rid of the member by adding a bool* parameter during parse (ignored if
      the PARSE_INTERNAL flag is not set), and by adding a new flag during
      format (if FORMAT_INTERNAL is set, the value printed in <active>
      depends on the new FORMAT_CURRENT).
      
      Then update the qemu driver accordingly, which involves hoisting
      assignments to vm->current_snapshot to occur prior to any point where
      a snapshot XML file is written (although qemu kept
      vm->current_snapshot and snapshot->def_current in sync by the end of
      the function, they were not always identical in the middle of
      functions, so the shuffling gets a bit interesting). Later patches
      will clean up some of that confusing churn to vm->current_snapshot.
      
      Note: even if later patches refactor qemu to no longer use
      FORMAT_INTERNAL for output (by storing bulk snapshot XML instead), we
      will always need PARSE_INTERNAL for input (because on upgrade, a new
      libvirt still has to parse XML left from a previous libvirt).
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
      f1056279
  7. 08 3月, 2019 1 次提交
    • E
      snapshot: Give virDomainSnapshotDefFormat its own flags · c5029559
      Eric Blake 提交于
      virDomainSnapshotDefFormat currently takes two sets of knobs:
      an 'unsigned int flags' argument that can currently just be
      VIR_DOMAIN_DEF_FORMAT_SECURE, and an 'int internal' argument used as
      a bool to determine whether to output an additional element.  It
      then reuses the 'flags' knob to call into virDomainDefFormatInternal(),
      which takes a different set of flags. In fact, prior to commit 0ecd6851
      (1.2.12), the 'flags' argument actually took the public
      VIR_DOMAIN_XML_SECURE, which was even more confusing.  Let's borrow
      from the style of that earlier commit, by introducing a function
      for translating from the public flags (VIR_DOMAIN_SNAPSHOT_XML_SECURE
      was just recently introduced) into a new enum specific to snapshot
      formatting, and adjust all callers to use snapshot-specific enum
      values when formatting, and where the formatter now uses a new
      variable 'domainflags' to make it obvious when we are translating
      from snapshot flags back to domain flags.  We don't even have to
      use the conversion function for drivers that don't accept the
      public VIR_DOMAIN_SNAPSHOT_XML_SECURE flag.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
      c5029559
  8. 20 2月, 2019 2 次提交
    • E
      snapshot: Define explicit flags for snapshot xml · a27031c4
      Eric Blake 提交于
      Commit f609cb85 (0.9.5) introduced virDomainSnapshotGetXMLDesc()'s use
      of @flags as a subset of virDomainXMLFlags, documenting that 2 of the
      3 flags defined at the time would never be valid.  Later, commit
      28f8dfdc (1.0.0) introduced a new flag, VIR_DOMAIN_XML_MIGRATABLE, but
      did not adjust the snapshot documentation to declare it as invalid.
      However, since the flag is not accepted as valid by any of the
      drivers (remote is just passthrough; esx and vbox don't support flags;
      qemu, test, and vz only support VIR_DOMAIN_XML_SECURE), and it is
      unlikely that the domain state saved off during a snapshot creation
      needs to be migration-friendly (as the snapshot is not the source of
      a migration), it is easier to just define an explicit set of supported
      flags directly related to the snapshot API rather than trying to
      borrow from domain API, and risking confusion if even more domain
      flags are added later (in fact, I have an upcoming patch that plans to
      add a new flag to virDomainGetXMLDesc that makes no sense for
      snapshots).
      
      There is no API or ABI impact (since we purposefully used unsigned int
      rather than an enum type in public API, and since the new flag name
      carries the same value as the reused name).
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
      a27031c4
    • E
      domain: Fix unknown flags diagnosis in virDomainGetXMLDesc · 27c8fd74
      Eric Blake 提交于
      Many drivers had a comment that they did not validate the incoming
      'flags' to virDomainGetXMLDesc() because they were relying on
      virDomainDefFormat() to do it instead. This used to be the case
      (at least since 461e0f1a and friends in 0.9.4 added unknown flag
      checking in general), but regressed in commit 0ecd6851 (1.2.12),
      when all of the drivers were changed to pass 'flags' through the
      new helper virDomainDefFormatConvertXMLFlags(). Since this helper
      silently ignores unknown flags, we need to implement flag checking
      in each driver instead.
      
      Annoyingly, this means that any new flag values added will silently
      be ignored when targeting an older libvirt, rather than our usual
      practice of loudly diagnosing an unsupported flag.  Add comments
      in domain_conf.[ch] to remind us to be extra vigilant about the
      impact when adding flags (a new flag to add data is safe if the
      older server omitting the requested data doesn't break things in
      the newer client; a new flag to suppress data rather than enhancing
      the existing VIR_DOMAIN_XML_SECURE may form a data leak or even a
      security hole).
      
      In the qemu driver, there are multiple callers all funnelling to
      qemuDomainDefFormatBufInternal(); many of them already validated
      flags (and often only a subset of the full set of possible flags),
      but for ease of maintenance, we can also check flags at the common
      helper function.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
      27c8fd74
  9. 04 2月, 2019 1 次提交
  10. 28 1月, 2019 1 次提交
    • M
      lib: Use more of VIR_STEAL_PTR() · 5772885d
      Michal Privoznik 提交于
      We have this very handy macro called VIR_STEAL_PTR() which steals
      one pointer into the other and sets the other to NULL. The
      following coccinelle patch was used to create this commit:
      
        @ rule1 @
        identifier a, b;
        @@
      
        - b = a;
          ...
        - a = NULL;
        + VIR_STEAL_PTR(b, a);
      
      Some places were clean up afterwards to make syntax-check happy
      (e.g. some curly braces were removed where the body become a one
      liner).
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NErik Skultety <eskultet@redhat.com>
      5772885d
  11. 05 12月, 2018 1 次提交
  12. 20 9月, 2018 2 次提交
  13. 17 9月, 2018 1 次提交
  14. 28 5月, 2018 3 次提交
  15. 04 5月, 2018 1 次提交
    • J
      conf: Clean up object referencing for Add and Remove · b04629b6
      John Ferlan 提交于
      When adding a new object to the domain object list, there should
      have been 2 virObjectRef calls made one for each list into which
      the object was placed to match the 2 virObjectUnref calls that
      would occur during Remove as part of virHashRemoveEntry when
      virObjectFreeHashData is called when the element is removed from
      the hash table as set up in virDomainObjListNew.
      
      Some drivers (libxl, lxc, qemu, and vz) handled this inconsistency
      by calling virObjectRef upon successful return from virDomainObjListAdd
      in order to use virDomainObjEndAPI when done with the returned @vm.
      While others (bhyve, openvz, test, and vmware) handled this via only
      calling virObjectUnlock upon successful return from virDomainObjListAdd.
      
      This patch will "unify" the approach to use virDomainObjEndAPI
      for any @vm successfully returned from virDomainObjListAdd.
      
      Because list removal is so tightly coupled with list addition,
      this patch fixes the list removal algorithm to return the object
      as entered - "locked and reffed".  This way, the callers can then
      decide how to uniformly handle add/remove success and failure.
      This removes the onus on the caller to "specially handle" the
      @vm during removal processing.
      
      The Add/Remove logic allows for some logic simplification such
      as in libxl where we can Remove the @vm directly rather than
      needing to set a @remove_dom boolean and removing after the
      libxlDomainObjEndJob completes as the @vm is locked/reffed.
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      Reviewed-by: NErik Skultety <eskultet@redhat.com>
      b04629b6
  16. 23 4月, 2018 2 次提交
  17. 20 4月, 2018 2 次提交
    • J
      vz: Use virDomainObjListFindBy{UUID|ID}Ref · 3c66d510
      John Ferlan 提交于
      For vzDomainLookupByID and vzDomainLookupByUUID let's
      return a locked and referenced @vm object so that callers
      can then use the common and more consistent virDomainObjEndAPI
      in order to handle cleanup rather than needing to know that the
      returned object is locked and calling virObjectUnlock.
      
      The LookupByName already returns the ref counted and locked object,
      so this will make things more consistent.
      
      Also adjust the prlsdkHandle{VmState|VmRemoved|Perf}Event APIs
      in the same manner.
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      Reviewed-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
      3c66d510
    • J
      vz: Unify vzDomObjFromDomain{Ref} · d758374d
      John Ferlan 提交于
      Rather than have two API's doing different things for different
      callers, let's make one API that will always return a locked and
      ref counted object. That way, the callers will always know that
      they must call virDomainObjEndAPI and not have to decide whether
      they should call virObjectUnlock instead.
      
      This will make things consistent with LookupByName which returns
      the locked and ref counted object.
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      Reviewed-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
      d758374d
  18. 19 4月, 2018 1 次提交
  19. 18 4月, 2018 2 次提交
  20. 12 4月, 2018 4 次提交
  21. 16 3月, 2018 1 次提交
  22. 28 2月, 2018 1 次提交
  23. 03 11月, 2017 1 次提交
    • A
      Remove backslash alignment attempts · 3e7db8d3
      Andrea Bolognani 提交于
      Right-aligning backslashes when defining macros or using complex
      commands in Makefiles looks cute, but as soon as any changes is
      required to the code you end up with either distractingly broken
      alignment or unnecessarily big diffs where most of the changes
      are just pushing all backslashes a few characters to one side.
      
      Generated using
      
        $ git grep -El '[[:blank:]][[:blank:]]\\$' | \
          grep -E '*\.([chx]|am|mk)$$' | \
          while read f; do \
            sed -Ei 's/[[:blank:]]*[[:blank:]]\\$/ \\/g' "$f"; \
          done
      Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
      3e7db8d3