1. 28 4月, 2015 11 次提交
  2. 20 4月, 2015 2 次提交
  3. 17 4月, 2015 1 次提交
    • E
      virsh: fix regression in 'virsh event' by domain · 44fdfbb0
      Eric Blake 提交于
      https://bugzilla.redhat.com/show_bug.cgi?id=1212620
      
      Commit a0670aef caused a regression in 'virsh event' and
      'virsh qemu-monitor-event' - if a user tries to filter the
      command to a specific domain, an error message is printed:
      
      $ virsh event dom --loop
      error: internal error: virsh qemu-monitor-event: no domain VSH_OT_DATA option
      
      and then the command continues as though no domain had been
      supplied (giving events for ALL domains, instead of the
      requested one).  This is because the code was incorrectly
      assuming that all "domain" options would be supplied via a
      mandatory VSH_OT_DATA, even though "domain" is optional for
      these two commands, so we had changed them to VSH_OT_STRING
      to quit failing for other reasons (ever since it was decided
      that VSH_OT_DATA and VSH_OT_STRING should no longer be
      synonyms).
      
      In looking at the situation, though, the code for looking up
      a domain was making a pointless check for whether the option
      exists prior to finding the option's string value, as
      vshCommandOptStringReq does just fine at reporting any errors
      when looking up a string whether or not the option was present.
      
      So this is a case of regression fixing by pure code deletion :)
      
      * tools/virsh-domain.c (vshCommandOptDomainBy): Drop useless filter.
      * tools/virsh-interface.c (vshCommandOptInterfaceBy): Likewise.
      * tools/virsh-network.c (vshCommandOptNetworkBy): Likewise.
      * tools/virsh-nwfilter.c (vshCommandOptNWFilterBy): Likewise.
      * tools/virsh-secret.c (vshCommandOptSecret): Likewise.
      * tools/virsh.h (vshCmdHasOption): Drop unused function.
      * tools/virsh.c (vshCmdHasOption): Likewise.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      (cherry picked from commit 31ef0836)
      44fdfbb0
  4. 16 4月, 2015 4 次提交
    • C
      virsh: Improve change-media success message · 8a5b7ecf
      Cole Robinson 提交于
      $ sudo virsh change-media f19 hdc /mnt/data/devel/media/Fedora-16-x86_64-Live-KDE.iso
      succeeded to complete action update on media
      
      Change the message to:
      
        Successfully {inserted,ejected,changed} media.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=967946
      (cherry picked from commit e3aa4c91)
      8a5b7ecf
    • M
      virNetSocketNewConnectUNIX: Use flocks when spawning a daemon · 59668f63
      Michal Privoznik 提交于
      https://bugzilla.redhat.com/show_bug.cgi?id=1200149
      
      Even though we have a mutex mechanism so that two clients don't spawn
      two daemons, it's not strong enough. It can happen that while one
      client is spawning the daemon, the other one fails to connect.
      Basically two possible errors can happen:
      
        error: Failed to connect socket to '/home/mprivozn/.cache/libvirt/libvirt-sock': Connection refused
      
      or:
      
        error: Failed to connect socket to '/home/mprivozn/.cache/libvirt/libvirt-sock': No such file or directory
      
      The problem in both cases is, the daemon is only starting up, while we
      are trying to connect (and fail). We should postpone the connecting
      phase until the daemon is started (by the other thread that is
      spawning it). In order to do that, create a file lock 'libvirt-lock'
      in the directory where session daemon would create its socket. So even
      when called from multiple processes, spawning a daemon will serialize
      on the file lock. So only the first to come will spawn the daemon.
      Tested-by: NRichard W. M. Jones <rjones@redhat.com>
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      (cherry picked from commit be78814a)
      59668f63
    • P
      rpc: Don't unref identity object while callbacks still can be executed · 72e4e1a1
      Peter Krempa 提交于
      While this thread is cleaning up the client and connection objects:
       #2  virFileReadAll (path=0x7f28780012b0 "/proc/1319/stat", maxlen=maxlen@entry=1024, buf=buf@entry=0x7f289c60fc40) at util/virfile.c:1287
       #3  0x00007f28adbb1539 in virProcessGetStartTime (pid=<optimized out>, timestamp=timestamp@entry=0x7f289c60fc98) at util/virprocess.c:838
       #4  0x00007f28adb91981 in virIdentityGetSystem () at util/viridentity.c:151
       #5  0x00007f28ae73f17c in remoteClientFreeFunc (data=<optimized out>) at remote.c:1131
       #6  0x00007f28adcb7f33 in virNetServerClientDispose (obj=0x7f28aecad180) at rpc/virnetserverclient.c:858
       #7  0x00007f28adba8eeb in virObjectUnref (anyobj=<optimized out>) at util/virobject.c:265
       #8  0x00007f28ae74ad05 in virNetServerHandleJob (jobOpaque=<optimized out>, opaque=0x7f28aec93ff0) at rpc/virnetserver.c:205
       #9  0x00007f28adbbef4e in virThreadPoolWorker (opaque=opaque@entry=0x7f28aec88030) at util/virthreadpool.c:145
      
      In stack frame #6 the client->identity object got unref'd, but the code
      that removes the event callbacks in frame #5 did not run yet as we are
      trying to obtain the system identity (frames #4, #3, #2).
      
      In other thead:
       #0  virObjectUnref (anyobj=anyobj@entry=0x7f288c162c60) at util/virobject.c:264
              klass = 0xdeadbeef
              obj = 0x7f288c162c60
       #1  0x00007f28ae71c709 in remoteRelayDomainEventCheckACL (client=<optimized out>, conn=<optimized out>, dom=dom@entry=0x7f28aecaafc0) at remote.c:164
       #2  0x00007f28ae71fc83 in remoteRelayDomainEventTrayChange (conn=<optimized out>, dom=0x7f28aecaafc0, ... ) at remote.c:717
       #3  0x00007f28adc04e53 in virDomainEventDispatchDefaultFunc (conn=0x7f287c0009a0, event=0x7f28aecab1a0, ...) at conf/domain_event.c:1455
       #4  0x00007f28adc03831 in virObjectEventStateDispatchCallbacks (callbacks=<optimized out>, ....) at conf/object_event.c:724
       #5  virObjectEventStateQueueDispatch (callbacks=0x7f288c083730, queue=0x7fff51f90030, state=0x7f288c18da20) at conf/object_event.c:738
       #6  virObjectEventStateFlush (state=0x7f288c18da20) at conf/object_event.c:816
       #7  virObjectEventTimer (timer=<optimized out>, opaque=0x7f288c18da20) at conf/object_event.c:562
       #8  0x00007f28adb859cd in virEventPollDispatchTimeouts () at util/vireventpoll.c:459
      
      Frame #0 is unrefing an invalid identity object while frame #2 hints
      that the client is still dispatching the event.
      
      For untrimmed backtrace see the bugzilla attachment.
      
      Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1203030
      (cherry picked from commit a98129c0)
      72e4e1a1
    • L
      lxc: create the required directories upon driver start · ed1cf00a
      Lubomir Rintel 提交于
      /var/run may reside on a tmpfs and we fail to create the PID file if
      /var/run/lxc does not exist.
      
      Since commit 0a8addc1, the lxc driver's state directory isn't
      automatically created before starting a domain. Now, the lxc driver
      makes sure the state directory exists when it initializes.
      Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
      (cherry picked from commit da33a1ac)
      ed1cf00a
  5. 03 4月, 2015 1 次提交
    • E
      qemu: read backing chain names from qemu · ece6debb
      Eric Blake 提交于
      https://bugzilla.redhat.com/show_bug.cgi?id=1199182 documents that
      after a series of disk snapshots into existing destination images,
      followed by active commits of the top image, it is possible for
      qemu 2.2 and earlier to end up tracking a different name for the
      image than what it would have had when opening the chain afresh.
      That is, when starting with the chain 'a <- b <- c', the name
      associated with 'b' is how it was spelled in the metadata of 'c',
      but when starting with 'a', taking two snapshots into 'a <- b <- c',
      then committing 'c' back into 'b', the name associated with 'b' is
      now the name used when taking the first snapshot.
      
      Sadly, older qemu doesn't know how to treat different spellings of
      the same filename as identical files (it uses strcmp() instead of
      checking for the same inode), which means libvirt's attempt to
      commit an image using solely the names learned from qcow2 metadata
      fails with a cryptic:
      
      error: internal error: unable to execute QEMU command 'block-commit': Top image file /tmp/images/c/../b/b not found
      
      even though the file exists.  Trying to teach libvirt the rules on
      which name qemu will expect is not worth the effort (besides, we'd
      have to remember it across libvirtd restarts, and track whether a
      file was opened via metadata or via snapshot creation for a given
      qemu process); it is easier to just always directly ask qemu what
      string it expects to see in the first place.
      
      As a safety valve, we validate that any name returned by qemu
      still maps to the same local file as we have tracked it, so that
      a compromised qemu cannot accidentally cause us to act on an
      incorrect file.
      
      * src/qemu/qemu_monitor.h (qemuMonitorDiskNameLookup): New
      prototype.
      * src/qemu/qemu_monitor_json.h (qemuMonitorJSONDiskNameLookup):
      Likewise.
      * src/qemu/qemu_monitor.c (qemuMonitorDiskNameLookup): New function.
      * src/qemu/qemu_monitor_json.c (qemuMonitorJSONDiskNameLookup)
      (qemuMonitorJSONDiskNameLookupOne): Likewise.
      * src/qemu/qemu_driver.c (qemuDomainBlockCommit)
      (qemuDomainBlockJobImpl): Use it.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      (cherry picked from commit f9ea3d60)
      ece6debb
  6. 17 3月, 2015 1 次提交
    • E
      daemon: avoid memleak when ListAll returns nothing · 117f60ca
      Eric Blake 提交于
      Commit 4f25146b (v1.2.8) managed to silence Coverity, but at the
      cost of a memory leak detected by valgrind:
      ==24129== 40 bytes in 5 blocks are definitely lost in loss record 355 of 637
      ==24129==    at 0x4A08B1C: realloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
      ==24129==    by 0x5084B8E: virReallocN (viralloc.c:245)
      ==24129==    by 0x514D5AA: virDomainObjListExport (domain_conf.c:22200)
      ==24129==    by 0x201227DB: qemuConnectListAllDomains (qemu_driver.c:18042)
      ==24129==    by 0x51CC1B6: virConnectListAllDomains (libvirt-domain.c:6797)
      ==24129==    by 0x14173D: remoteDispatchConnectListAllDomains (remote.c:1580)
      ==24129==    by 0x121BE1: remoteDispatchConnectListAllDomainsHelper (remote_dispatch.h:1072)
      
      In short, every time a client calls a ListAll variant and asks
      for the resulting list, but there are 0 elements to return, we
      end up leaking the 1-entry array that holds the NULL terminator.
      
      What's worse, a read-only client can access these functions in a
      tight loop to cause libvirtd to eventually run out of memory; and
      this can be considered a denial of service attack against more
      privileged clients.  Thankfully, the leak is so small (8 bytes per
      call) that you would already have some other denial of service with
      any guest calling the API that frequently, so an out-of-memory
      crash is unlikely enough that this did not warrant a CVE.
      
      * daemon/remote.c (remoteDispatchConnectListAllDomains)
      (remoteDispatchDomainListAllSnapshots)
      (remoteDispatchDomainSnapshotListAllChildren)
      (remoteDispatchConnectListAllStoragePools)
      (remoteDispatchStoragePoolListAllVolumes)
      (remoteDispatchConnectListAllNetworks)
      (remoteDispatchConnectListAllInterfaces)
      (remoteDispatchConnectListAllNodeDevices)
      (remoteDispatchConnectListAllNWFilters)
      (remoteDispatchConnectListAllSecrets)
      (remoteDispatchNetworkGetDHCPLeases): Plug leak.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      (cherry picked from commit 3c2ff502)
      117f60ca
  7. 10 3月, 2015 1 次提交
    • L
      qemu: don't fill in nicindexes for session mode libvirtd · a4613757
      Laine Stump 提交于
      Commit 4bbe1029 fixed a problem in commit f7afeddc by moving the call
      to virNetDevGetIndex() to a location common to all interface types (so
      that the nicindex array would be filled in for macvtap as well as tap
      interfaces), but the location was *too* common, as the original call
      to virNetDevGetIndex() had been in a section qualified by "if
      (cfg->privileged)". The result was that the "fixed" libvirtd would try
      to call virNetDevGetIndex() even for session mode libvirtd, and end up
      failing with the log message:
      
        Unable to open control socket: Operation not permitted
      
      To remedy that, this patch qualifies the call to virNetDevGetIndex()
      in its new location with cfg->privileged.
      
      This resolves https://bugzilla.redhat.com/show_bug.cgi?id=1198244
      
      (cherry picked from commit 705242f8)
      a4613757
  8. 02 3月, 2015 1 次提交
  9. 27 2月, 2015 3 次提交
  10. 26 2月, 2015 8 次提交
    • P
      util: storage: Fix error type in virStorageSourceParseBackingURI · ef2e6f40
      Peter Krempa 提交于
      The gluster volume name extraction code was copied from the XML parser
      without changing the VIR_ERR_XML_ERROR error code. Use
      VIR_ERR_CONFIG_UNSUPPORTED instead.
      ef2e6f40
    • P
      util: storagefile: Don't crash on gluster URIs without path · fc56ecd7
      Peter Krempa 提交于
      Similar to commit fdb80ed4 libvirtd
      would crash if a gluster URI without path would be used in the backing
      chain of a volume. The crash happens in the gluster specific part of the
      parser that extracts the gluster volume name from the path.
      
      Fix the crash by checking that the PATH is NULL.
      
      This patch does not contain a test case as it's not possible to test it
      with the current infrastructure as the test suite would attempt to
      contact the gluster server in the URI. I'm working on the test suite
      addition but that will be post-release material.
      
      Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1196528
      fc56ecd7
    • J
      conf: error out on missing dhcp host attributes · b15b21f3
      Ján Tomko 提交于
      In virNetworkDHCPHostDefParseXML an error is reported
      when partialOkay == true, and none of ip, mac, name
      were supplied.
      
      Add the missing goto and error out in this case.
      b15b21f3
    • L
      conf: error out on invalid host id · 719cd218
      Luyao Huang 提交于
      https://bugzilla.redhat.com/show_bug.cgi?id=1196503
      
      We already check whether the host id is valid or not, add a jump
      to forbid invalid host id.
      Signed-off-by: NLuyao Huang <lhuang@redhat.com>
      Signed-off-by: NJán Tomko <jtomko@redhat.com>
      719cd218
    • L
      qemu: fix ifindex array reported to systemd · 4bbe1029
      Laine Stump 提交于
      Commit f7afeddc added code to report to systemd an array of interface
      indexes for all tap devices used by a guest. Unfortunately it not only
      didn't add code to report the ifindexes for macvtap interfaces
      (interface type='direct') or the tap devices used by type='ethernet',
      it ended up sending "-1" as the ifindex for each macvtap or hostdev
      interface. This resulted in a failure to start any domain that had a
      macvtap or hostdev interface (or actually any type other than
      "network" or "bridge").
      
      This patch does the following with the nicindexes array:
      
      1) Modify qemuBuildInterfaceCommandLine() to only fill in the
      nicindexes array if given a non-NULL pointer to an array (and modifies
      the test jig calls to the function to send NULL). This is because
      there are tests in the test suite that have type='ethernet' and still
      have an ifname specified, but that device of course doesn't actually
      exist on the test system, so attempts to call virNetDevGetIndex() will
      fail.
      
      2) Even then, only add an entry to the nicindexes array for
      appropriate types, and to do so for all appropriate types ("network",
      "bridge", and "direct"), but only if the ifname is known (since that
      is required to call virNetDevGetIndex().
      4bbe1029
    • L
      util: check for null ifname inside virNetDevBandwidthSet() · 153b06c6
      Laine Stump 提交于
      Previously this function relied on having ATTRIBUTE_NONNULL(1) in its
      prototype rather than explicitly checking for a null
      ifname. Unfortunately, ATTRIBUTE_NONNULL is just a hint to the
      optimizer and code analyzers like Coverity, it doesn't actually check
      anything at execution time, so the result was possible warnings from
      Coverity, along with the possibility of null dereferences when ifname
      wasn't available.
      
      This patch removes the ATTRIBUTE_NONNULL from the prototype, and
      checks ifname inside the function, logging an error if it's NULL (once
      we've determined that the user really is trying to set a bandwidth).
      153b06c6
    • L
      network: only clear bandwidth if it has been set · 118b2408
      Laine Stump 提交于
      libvirt was unconditionally calling virNetDevBandwidthClear() for
      every interface (and network bridge) of a type that supported
      bandwidth, whether it actually had anything set or not. This doesn't
      hurt anything (unless ifname == NULL!), but is wasteful.
      
      This patch makes sure that all calls to virNetDevBandwidthClear() are
      qualified by checking that the interface really had some bandwidth
      setup done, and checks for a null ifname inside
      virNetDevBandwidthClear(), silently returning success if it is null
      (as well as removing the ATTRIBUTE_NONNULL from that function's
      prototype, since we can't guarantee that it is never null,
      e.g. sometimes a type='ethernet' interface has no ifname as it is
      provided on the fly by qemu).
      118b2408
    • P
      schema: Allow interleaving the /domain/os/type element · 18f9f69b
      Peter Krempa 提交于
      The element wasn't declared under the interleave thus it was required
      always to be first. This made it inconvenient when pasting new stuff to
      the XML manually in the "wrong" place.
      18f9f69b
  11. 25 2月, 2015 7 次提交