1. 23 1月, 2015 1 次提交
  2. 23 12月, 2014 3 次提交
    • P
      qemu: migration: Unlock vm on failed ACL check in protocol v2 APIs · cd3d695a
      Peter Krempa 提交于
      Avoid leaving the domain locked on a failed ACL check in
      qemuDomainMigratePerform() and qemuDomainMigrateFinish2().
      
      Introduced in commit abf75aea (Add ACL checks into the QEMU driver).
      
      (cherry picked from commit 2bdcd29c)
      cd3d695a
    • M
      wireshark: Honor API change coming with 1.12 release · f0905f7a
      Michal Privoznik 提交于
      https://bugs.gentoo.org/show_bug.cgi?id=508336
      
      At wireshark, they have this promise to change public dissector APIs
      only with minor version number change. Which they did when releasing
      the version of 1.12.
      
      Firstly, they've changed tvb_memdup() in
      a0c53ffaa1bb46d8c9db2ec739401aa411c9790e so now it takes four arguments
      instead of three. The new argument is placed at the very beginning of
      the list of arguments and basically says the scope where we'd like to
      allocate the memory. According to the documentation NULL should be the
      default value.
      
      Then, the tcp_dissect_pdus() signature changed too. Well, the function
      that actually dissects reassembled packets as tcp_dissect_pdus()
      reorder TCP packets into one big chunk and then calls a user function
      to dissect the PDU at once. The change is dated back to
      8081cf1d90397cbbb4404f9720595e1537ed5e14.
      
      Then, WS_DLL_PUBLIC_NOEXTERN was replaced with WS_DLL_PUBLIC_DEF in
      5d87a8c46171f572568db5a47c093423482e342f.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      (cherry picked from commit e74fa570)
      f0905f7a
    • M
      wireshark: Include more of libvirt internals · c6948801
      Michal Privoznik 提交于
      The rationale is to not duplicate code which is done in
      packet-libvirt.h for instance. Moreover, this way we can drop
      __attribute_((unused)) used int packet-libvirt.c in favor of
      ATTRIBUTE_UNUSED.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      (cherry picked from commit 906d0abf)
      c6948801
  3. 13 11月, 2014 1 次提交
    • L
      util: eliminate "use after free" in callers of virNetDevLinkDump · 644eb23f
      Laine Stump 提交于
      virNetDevLinkDump() gets a message from netlink into "resp", then
      calls nlmsg_parse() to fill the table "tb" with pointers into resp. It
      then returns tb to its caller, but not before freeing the buffer at
      resp. That means that all the callers of virNetDevLinkDump() are
      examining memory that has already been freed. This can be verified by
      filling the buffer at resp with garbage prior to freeing it (or, I
      suppose, just running libvirtd under valgrind) then performing some
      operation that calls virNetDevLinkDump().
      
      The upstream commit log incorrectly states that the code has been like
      this ever since virNetDevLinkDump() was written. In reality, the
      problem was introduced with commit e95de74d, first in libvirt-1.0.5,
      which was attempting to eliminate a typecast that caused compiler
      warnings. It has only been pure luck (or maybe a lack of heavy load,
      and/or maybe an allocation algorithm in malloc() that delays re-use of
      just-freed memory) that has kept this from causing errors, for example
      when configuring a PCI passthrough or macvtap passthrough network
      interface.
      
      The solution taken in this patch is the simplest - just return resp to
      the caller along with tb, then have the caller free it after they are
      finished using the data (pointers) in tb. I alternately could have
      made a cleaner interface by creating a new struct that put tb and resp
      together along with a vir*Free() function for it, but this function is
      only used in a couple places, and I'm not sure there will be
      additional new uses of virNetDevLinkDump(), so the value of adding a
      new type, extra APIs, etc. is dubious.
      
      (cherry picked from commit f9f9699f)
      644eb23f
  4. 07 11月, 2014 1 次提交
    • E
      CVE-2014-7823: dumpxml: security hole with migratable flag · 2cfd147c
      Eric Blake 提交于
      Commit 28f8dfdc (v1.0.0) introduced a security hole: in at least
      the qemu implementation of virDomainGetXMLDesc, the use of the
      flag VIR_DOMAIN_XML_MIGRATABLE (which is usable from a read-only
      connection) triggers the implicit use of VIR_DOMAIN_XML_SECURE
      prior to calling qemuDomainFormatXML.  However, the use of
      VIR_DOMAIN_XML_SECURE is supposed to be restricted to read-write
      clients only.  This patch treats the migratable flag as requiring
      the same permissions, rather than analyzing what might break if
      migratable xml no longer includes secret information.
      
      Fortunately, the information leak is low-risk: all that is gated
      by the VIR_DOMAIN_XML_SECURE flag is the VNC connection password;
      but VNC passwords are already weak (FIPS forbids their use, and
      on a non-FIPS machine, anyone stupid enough to trust a max-8-byte
      password sent in plaintext over the network deserves what they
      get).  SPICE offers better security than VNC, and all other
      secrets are properly protected by use of virSecret associations
      rather than direct output in domain XML.
      
      * src/remote/remote_protocol.x (REMOTE_PROC_DOMAIN_GET_XML_DESC):
      Tighten rules on use of migratable flag.
      * src/libvirt-domain.c (virDomainGetXMLDesc): Likewise.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      (cherry picked from commit b1674ad5)
      
      Conflicts:
      	src/libvirt-domain.c - file split from older src/libvirt.c
      Signed-off-by: NEric Blake <eblake@redhat.com>
      2cfd147c
  5. 02 10月, 2014 1 次提交
  6. 18 9月, 2014 1 次提交
  7. 02 7月, 2014 1 次提交
    • P
      qemu: copy: Accept 'format' parameter when copying to a non-existing img · 961758a1
      Peter Krempa 提交于
      We have the following matrix of possible arguments handled by the logic
      statement touched by this patch:
             | flags & _REUSE_EXT | !(flags & _REUSE_EXT)
      -------+--------------------+----------------------
       format| (1)                | (2)
      -------+--------------------+----------------------
      !format| (3)                | (4)
      -------+--------------------+----------------------
      
      In cases 1 and 2 the user provided a format, in cases 3 and 4 not. The
      user requests to use a pre-existing image in 1 and 3 and libvirt will
      create a new image in 2 and 4.
      
      The difference between cases 3 and 4 is that for 3 the format is probed
      from the user-provided image, whereas in 4 we just use the existing disk
      format.
      
      The current code would treat cases 1,3 and 4 correctly but in case 2 the
      format provided by the user would be ignored.
      
      The particular piece of code was broken in commit 35c7701c
      but since it was introduced a few commits before that it was never
      released as working.
      
      (cherry picked from commit 42619ed0)
      Signed-off-by: NEric Blake <eblake@redhat.com>
      
      Conflicts:
      	src/qemu/qemu_driver.c - no refactoring of commit 7b7bf001
      961758a1
  8. 27 6月, 2014 2 次提交
    • J
      test: add user_xattr check for securityselinuxlabeltest · 080d3b0f
      Jincheng Miao 提交于
      libvirt unit test used setxattr with "user.libvirt.selinux" name to
      emulate setfilecon of selinux. But for some old kernel filesystem
      (like 2.6.32-431.el6.x86_64), if the filesystem is not mounted with
      user_xattr flag, the setxattr with "user.libvirt.selinux" will fail.
      
      So adding testUserXattrEnabled() in securityselinuxlabeltest.c,
      if user_xattr is not enabled, skip this case.
      
      The user_xattr is departed in newer kernel, therefore this commit is
      only for the compatablity for old kernel.
      Signed-off-by: NJincheng Miao <jmiao@redhat.com>
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Tested-by: NScott Sullivan <ssullivan@liquidweb.com>
      (cherry picked from commit caf164f1)
      080d3b0f
    • E
      docs: publish correct enum values · ff947e98
      Eric Blake 提交于
      We publish libvirt-api.xml for others to use, and in fact, the
      libvirt-python bindings use it to generate python constants that
      correspond to our enum values.  However, we had an off-by-one bug
      that any enum that relied on C's rules for implicit initialization
      of the first enum member to 0 got listed in the xml as having a
      value of 1 (and all later members of the enum were equally
      botched).
      
      The fix is simple - since we add one to the previous value when
      encountering an enum without an initializer, the previous value
      must start at -1 so that the first enum member is assigned 0.
      
      The python generator code has had the off-by-one ever since DV
      first wrote it years ago, but most of our public enums were immune
      because they had an explicit = 0 initializer.  The only affected
      enums are:
      - virDomainEventGraphicsAddressType (such as
      VIR_DOMAIN_EVENT_GRAPHICS_ADDRESS_IPV4), since commit 987e31ed
      (libvirt v0.8.0)
      - virDomainCoreDumpFormat (such as VIR_DOMAIN_CORE_DUMP_FORMAT_RAW),
      since commit 9fbaff00 (libvirt v1.2.3)
      - virIPAddrType (such as VIR_IP_ADDR_TYPE_IPV4), since commit
      03e0e79e (not yet released)
      
      Thanks to Nehal J Wani for reporting the problem on IRC, and
      for helping me zero in on the culprit function.
      
      * docs/apibuild.py (CParser.parseEnumBlock): Fix implicit enum
      values.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      (cherry picked from commit 9b291bbe)
      ff947e98
  9. 26 6月, 2014 1 次提交
  10. 11 6月, 2014 1 次提交
    • E
      storage: fix memory leak with encrypted images · c9606d3d
      Eric Blake 提交于
      Jim Fehlig reported a regression found by libvirt-TCK tests:
      
      > ~ # perl /usr/share/libvirt-tck/tests/qemu/100-disk-encryption.t
      ...
      > ok 4 - defined persistent domain config
      > # Starting inactive domain config
      > libvirt error code: 1, message: internal error: unable to execute QEMU command
      > 'cont': 'drive-ide0-0-1'
      > (/var/cache/libvirt-tck/300-disk-encryption/demo.qcow2) is encrypted
      
      Commit 2279d560 converted a boolean into a pointer with the intent of
      transferring that pointer out of a temporary object into the caller's
      data structure.  The temporary structure meant that meta->encryption
      was always NULL on entry, so we could get away with blindly allocating
      the pointer when the header said so.  But later, commit 8823272d
      tweaked things to do backing chain detection in-place, rather than via
      a temporary object; this has the net result that meta->encryption can
      be non-NULL on entry.  Not only did this turn the latent behavior into
      a memory leak, it is also a behavior regression: blindly allocating a
      new pointer wipes out what secrets we already knew about the chain,
      making it impossible to restart the domain.
      
      Of course, no one in their right mind should be relying on qcow2
      encryption - it is fundamentally flawed.  And sadly, the TCK tests
      don't get run often enough, and this shows that our virstoragetest
      does not exercise encrypted images at all.  Otherwise, we could
      have avoided a release containing this regression.
      
      * src/util/virstoragefile.c (virStorageFileGetMetadataInternal):
      Don't nuke an already-existing encryption.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      (cherry picked from commit 1c7eb95c)
      c9606d3d
  11. 06 6月, 2014 1 次提交
  12. 02 6月, 2014 2 次提交
  13. 01 6月, 2014 1 次提交
    • L
      util: fix DST end date in virtimetest timezones · 83c41ceb
      Laine Stump 提交于
      Reported by: Roman Bogorodskiy <bogorodskiy@gmail.com>
      
      Some of the tests for virTimeLocalOffsetFromUTC set an imaginary
      timezone that attempts to force dyalight savings time active all the
      time by setting a start date of 0/00:00:00 and end date of
      366/23:59:59. Since the day is 0-based, 366 really means "day 367"
      which will never occur - this was an attempt to eliminate problems
      with DST not being active in some cases right around midnight on
      January 1. Even though it didn't completely solve the problem, it
      didn't seem to cause harm so it was left in the test timezones.
      
      Although Linux glibc doesn't mind having a DST end date of 366,
      FreeBSD refuses to use such timezones, so the tests fail. This patch
      changes the 366 to 365.
      
      This may or may not cause failure of the remaining DST tests around
      midnight Jan 1. If so, we will need to disable those tests at year's
      end too.
      83c41ceb
  14. 31 5月, 2014 1 次提交
    • E
      build: avoid compiler warning on 32-bit platform · c7ca02e6
      Eric Blake 提交于
      On a 32-bit platform:
      
      virstringtest.c: In function 'mymain':
      virstringtest.c:673: warning: this decimal constant is unsigned only in ISO C90
      
      I already had a comment in the file about the 64-bit counterpart;
      the easiest fix was to make both sites use the standardized macro
      that is guaranteed to work.
      
      * tests/virstringtest.c (mymain): Minimum signed integers are a pain.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      c7ca02e6
  15. 29 5月, 2014 13 次提交
    • P
      qemu: snapshot: Improve detection of mixed snapshots · 23f38f88
      Peter Krempa 提交于
      Currently we don't support mixed (external + internal) snapshots. The
      code detecting the snapshot type didn't make sure that the memory image
      was consistent with the snapshot type leading into strange error
      message:
      
       $ virsh snapshot-create-as --domain VM --diskspec vda,snapshot=internal --memspec snapshot=external,file=/tmp/blah
       error: internal error: unexpected code path
      
      Fix the mixed detection code to detect this kind of mistake:
      
       $ virsh snapshot-create-as --domain VM --diskspec vda,snapshot=internal --memspec snapshot=external,file=/tmp/blah
       error: unsupported configuration: mixing internal and external targets for a snapshot is not yet supported
      23f38f88
    • P
      qemu: snapshot: Reject internal active snapshot without memory state · d2e668e5
      Peter Krempa 提交于
      A internal snapshot of a active VM with the memory snapshot disabled
      explicitly would actually still take the memory snapshot. Reject it
      explicitly.
      
      Before:
       $ virsh snapshot-create-as --domain VM --diskspec vda,snapshot=internal --memspec snapshot=no
       Domain snapshot 1401353155 created
      
      After:
       $ virsh snapshot-create-as --domain VM --diskspec vda,snapshot=internal --memspec snapshot=no
       error: Operation not supported: internal snapshot of a running VM must include the memory state
      
      Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1083345
      d2e668e5
    • P
      util: storage: Fix crash of libvirtd on network backed guest block-pull · 4a051b80
      Peter Krempa 提交于
      For guests backed by gluster volumes (or other network storage) we don't
      fill the backing chain (see qemuDomainDetermineDiskChain). This leaves
      the "relPath" field of the top image NULL. This causes a crash in
      virStorageFileChainLookup() when looking up a backing element for such a
      disk.
      
      Since I'm working on adding support for network storage and one of the
      steps will make the "relPath" field optional let's use STREQ_NULLABLE
      instead of STREQ in virStorageFileChainLookup() to avoid the problem.
      4a051b80
    • L
      util: fix virTimeLocalOffsetFromUTC DST processing · 26d43113
      Laine Stump 提交于
      The original version of virTimeLocalOffsetFromUTC() would fail for
      certain times of the day if daylight savings time was active. This
      could most easily be seen by uncommenting the TEST_LOCALOFFSET() cases
      that include a DST setting.
      
      After a lot of experimenting, I found that the way to solve it in
      almost all test cases is to set tm_isdst = -1 in the struct tm prior
      to calling mktime(). Once this is done, the correct offset is returned
      for all test cases at all times except the two hours just after
      00:00:00 Jan 1 UTC - during that time, any timezone that is *behind*
      UTC, and that is supposed to always be in DST will not have DST
      accounted for in its offset.
      
      I believe that the code of virTimeLocalOffsetFromUTC() actually is
      correct for all cases, but the problem still encountered is due to our
      inability to come up with a TZ string that properly forces DST to
      *always* be active. Since a modfication of the (currently fixed)
      expected result data to account for this would necessarily use the
      same functions that we're trying to test, I've instead just made the
      test program conditionally bypass the problematic cases if the current
      date is either December 31 or January 1. This way we get maximum
      testing during 363 days of the year, but don't get false failures on
      Dec 31 and Jan 1.
      26d43113
    • E
      virsh: fix typos in virsh man page · be673413
      Eric Blake 提交于
      * tools/virsh.pod (attach-disk): Drop duplicate --config, fix typo
      in --sourcetype.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      be673413
    • E
      maint: fix typo in previous patch · 5fa10f32
      Eric Blake 提交于
      Use correct variable name.
      
      * m4/virt-selinux.m4: Fix one last variable name.
      5fa10f32
    • J
      maint: cleanup detection of const'ness of selinux ctx · b109c097
      Jim Fehlig 提交于
      Commit 292d3f2d fixed the build with libselinux 2.3, but missed
      some suggestions by eblake
      
      https://www.redhat.com/archives/libvir-list/2014-May/msg00977.html
      
      This patch changes the macro introduced in 292d3f2d to either be
      empty in the case of newer libselinux, or contain 'const' in the
      case of older libselinux.  The macro is then used directly in
      tests/securityselinuxhelper.c.
      b109c097
    • C
      build: fix build with libselinux 2.3 · 292d3f2d
      Cédric Bosdonnat 提交于
      Several function signatures changed in libselinux 2.3, now taking
      a 'const char *' instead of 'security_context_t'.  The latter is
      defined in selinux/selinux.h as
      
        typedef char *security_context_t;
      Signed-off-by: NEric Blake <eblake@redhat.com>
      292d3f2d
    • P
      qemu: managedsave: Don't spam logs with warnings about corrupted image · 0b317d61
      Peter Krempa 提交于
      Even successful start of a VM from a managed save image would spam the
      logs with the following message:
      
      Unable to restore from managed state [path]. Maybe the file is
      corrupted?
      
      Re-arrange the logic to output the warning only when the image is
      corrupted.
      
      The flaw was introduced in commit cfc28c66.
      0b317d61
    • P
      utils: storage: Canonicalize paths only for local filesystems · 92dc2dab
      Peter Krempa 提交于
      Now that virStorageFileGetMetadataFromBuf is used only for remote
      filesystems, don't canonicalize the path in it.
      92dc2dab
    • P
      storage: fs: Drop-in replace use of virStorageFileGetMetadataFromBuf · 34d86185
      Peter Krempa 提交于
      Use virStorageFileGetMetadataFromFD instead in
      virStorageBackendProbeTarget as it now returns all required data and the
      storage file is already open in a filedescriptor.
      
      Also fix improper error code being returned when virFileReadHeaderFD
      would fail as virStorageBackendUpdateVolTargetInfoFD would set the
      return code to 0.
      34d86185
    • P
      storage: Return backing format from virStorageFileGetMetadataFromFD · 5a1cf6bd
      Peter Krempa 提交于
      Add argument to return backing file format of a file probed by
      virStorageFileGetMetadataFromFD so that it can be used in place of
      virStorageFileGetMetadataFromBuf.
      5a1cf6bd
    • E
      qemu: reject rather than hang on blockcommit of active layer · e6bcbcd3
      Eric Blake 提交于
      qemu 2.0 added the ability to commit the active layer, but slightly
      differently than what libvirt had been anticipating in its
      implementation of the virDomainBlockCommit call.  As a result, if
      you attempt to do a 'virsh blockcommit $dom vda', qemu gets into a
      state where it is waiting on libvirt to end the job, while libvirt
      is waiting on qemu to end the job, and the guest is effectively
      hung with regards to further commands for that block device.
      
      I have patches coming down the pipeline that will add full support
      for blockcommit of the active layer when coupled with qemu 2.0 or
      later; but they depend on Peter's improvements to block job handling
      and form enough of a new feature that they are not ready for
      inclusion in the 1.2.5 release.  So for now, just reject the
      attempt, rather than letting the user get stuck.  This is no worse
      than the behavior of qemu 1.7 rejecting the job.
      
      * src/qemu/qemu_driver.c (qemuDomainBlockCommit): Reject active
      commit.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      e6bcbcd3
  16. 28 5月, 2014 1 次提交
  17. 27 5月, 2014 2 次提交
  18. 26 5月, 2014 6 次提交
    • D
      Fix an extra ' in a translated string · f07d24a6
      Daniel Veillard 提交于
      Raised by ukrainian translator Yuri Chornoivan
      https://fedora.transifex.com/projects/p/libvirt/translate/#uk/strings/25483059
      f07d24a6
    • J
      Clean up chardev sockets on QEMU shutdown · 205010c4
      Ján Tomko 提交于
      https://bugzilla.redhat.com/show_bug.cgi?id=1088787
      
      Clean up unix socket files for chardevs using mode='bind',
      like we clean up the monitor socket.
      They are created by QEMU on startup and not really useful
      after shutting it down.
      205010c4
    • L
      qemu: fix <clock offset='variable' basis='localtime'/> · cde8ca2d
      Laine Stump 提交于
      For a clock element as above, libvirt simply converts current system
      time with localtime_r(), then starts qemu with a time string that
      doesn't contain any timezone information. So, from qemu's point of
      view, the -rtc string it gets for:
      
         <clock offset='variable' basis='utc' adjustment='10800'/>
      
      is identical to the -rtc string it gets for:
      
         <clock offset='variable' basis='localtime' adjustment='0'/>
      
      (assuming the host is in a timezone that is 10800 seconds ahead of
      UTC, as is the case on the machine where this message is being
      written).
      
      Since the commandlines are identical, qemu will behave identically
      after this point in either case.
      
      There are two problems in the case of basis='localtime' though:
      
      Problem 1) If the guest modifies its RTC, for example to add 20
      seconds, the RTC_CHANGE event from qemu will then contain offset:20 in
      both cases. But libvirt will have saved the original adjustment into
      adjustment0, and will add that value onto the offset in the
      event. This means that in the case of basis=;utc', it will properly
      emit an event with offset:10820, but in the case of basis='localtime'
      the event will contain offset:20, which is *not* the new offset of the
      RTC from UTC (as the event it documented to provide).
      
      Problem 2) If the guest is migrated to another host that is in a
      different timezone, or if it is migrated or saved/restored after the
      DST status has changed from what it was when the guest was originally
      started, the newly restarted guest will have a different RTC (since it
      will be based on the new localtime, which could have shifted by
      several hours).
      
      The solution to both of these problems is simple - rather than
      maintaining the original adjustment value along with
      "basis='localtime'" in the domain status, when the domain is started
      we convert the adjustment offset to one relative to UTC, and set the
      status to "basis='utc'". Thus, whatever the RTC offset was from UTC
      when it was initially started, that offset will be maintained when
      migrating across timezones and DST settings, and the RTC_CHANGE events
      will automatically contain the proper offset (which should by
      definition always be relative to UTC).
      
      This fixes a problem that was implied but not openly stated in:
      
        https://bugzilla.redhat.com/show_bug.cgi?id=964177
      cde8ca2d
    • L
      qemu: fix RTC_CHANGE event for <clock offset='variable' basis='utc'/> · b62d67da
      Laine Stump 提交于
      commit e31b5cf3 attempted to fix libvirt's
      VIR_DOMAIN_EVENT_ID_RTC_CHANGE, which is documentated to always
      provide the new offset of the domain's real time clock from UTC. The
      problem was that, in the case that qemu is provided with an "-rtc
      base=x" where x is an absolute time (rather than "utc" or
      "localtime"), the offset sent by qemu's RTC_CHANGE event is *not* the
      new offset from UTC, but rather is the sum of all changes to the
      domain's RTC since it was started with base=x.
      
      So, despite what was said in commit e31b5cf3, if we assume that
      the original value stored in "adjustment" was the offset from UTC at
      the time the domain was started, we can always determine the current
      offset from UTC by simply adding the most recent (i.e. current) offset
      from qemu to that original adjustment.
      
      This patch accomplishes that by storing the initial adjustment in the
      domain's status as "adjustment0". Each time a new RTC_CHANGE event is
      received from qemu, we simply add adjustment0 to the value sent by
      qemu, store that as the new adjustment, and forward that value on to
      any event handler.
      
      This patch (*not* e31b5cf3, which should be reverted prior to
      applying this patch) fixes:
      
      https://bugzilla.redhat.com/show_bug.cgi?id=964177
      
      (for the case where basis='utc'. It does not fix basis='localtime')
      b62d67da
    • L
      Revert "qemu: Report the offset from host UTC for RTC_CHANGE event" · b8efa6f2
      Laine Stump 提交于
      This reverts commit e31b5cf3.
      
      This commit attempted to work around a bug in the offset value
      reported by qemu's RTC_CHANGE event in the case that a variable base
      date was given on the qemu commandline. The patch mixed up the math
      involved in arriving at the corrected offset to report, and in the
      process added an unnecessary private attribute to the clock
      element. Since that element is private/internal and not used by anyone
      else, it makes sense to simplify things by removing it.
      b8efa6f2
    • L
      util: new function virTimeLocalOffsetFromUTC · 1cddaea7
      Laine Stump 提交于
      Since there isn't a single libc API to get this value, this patch
      supplies one which gets the value by grabbing current time, then
      converting that into a struct tm with gmtime_r(), then back to a
      time_t using mktime.
      
      The returned value is the difference between UTC and localtime in
      seconds. If localtime is ahead of UTC (east) the offset will be a
      positive number, and if localtime is behind UTC (west) the offset will
      be negative.
      
      This function should be POSIX-compliant, and is threadsafe, but not
      async signal safe. If it was ever necessary to know this value in a
      child process, we could cache it with a one-time init function when
      libvirtd starts, then just supply the cached value, but that
      complexity isn't needed for current usage; that would also have the
      problem that it might not be accurate after a local daylight savings
      boundary.
      
      (If it weren't for DST, we could simply replace this entire function
      with "-timezone"; timezone contains the offset of the current timezone
      (negated from what we want) but doesn't account for DST. And in spite
      of being guaranteed by POSIX, it isn't available on older versions of
      mingw.)
      Signed-off-by: NEric Blake <eblake@redhat.com>
      1cddaea7