1. 02 4月, 2015 17 次提交
  2. 01 4月, 2015 2 次提交
  3. 31 3月, 2015 3 次提交
    • P
      qemu: blockjob: Synchronously update backing chain in XML on ABORT/PIVOT · 630ee5ac
      Peter Krempa 提交于
      When the synchronous pivot option is selected, libvirt would not update
      the backing chain until the job was exitted. Some applications then
      received invalid data as their job serialized first.
      
      This patch removes polling to wait for the ABORT/PIVOT job completion
      and replaces it with a condition. If a synchronous operation is
      requested the update of the XML is executed in the job of the caller of
      the synchronous request. Otherwise the monitor event callback uses a
      separate worker to update the backing chain with a new job.
      
      This is a regression since 1a92c719
      
      When the ABORT job is finished synchronously you get the following call
      stack:
       #0  qemuBlockJobEventProcess
       #1  qemuDomainBlockJobImpl
       #2  qemuDomainBlockJobAbort
       #3  virDomainBlockJobAbort
      
      While previously or while using the _ASYNC flag you'd get:
       #0  qemuBlockJobEventProcess
       #1  processBlockJobEvent
       #2  qemuProcessEventHandler
       #3  virThreadPoolWorker
      630ee5ac
    • P
      qemu: Extract internals of processBlockJobEvent into a helper · 0c4474df
      Peter Krempa 提交于
      Later on I'll be adding a condition that will allow to synchronise a
      SYNC block job abort. The approach will require this code to be called
      from two different places so it has to be extracted into a helper.
      0c4474df
    • P
      qemu: processBlockJob: Don't unlock @vm twice · 6b6c4ab8
      Peter Krempa 提交于
      Commit 1a92c719 moved code to handle block job events to a different
      function that is executed in a separate thread. The caller of
      processBlockJob handles locking and unlocking of @vm, so the we should
      not do it in the function itself.
      6b6c4ab8
  4. 30 3月, 2015 6 次提交
  5. 29 3月, 2015 1 次提交
    • E
      build: avoid variable named 'interface', for mingw · 75d56f51
      Eric Blake 提交于
      Commit 2f36e694 (re-)introduced a use of an identifier 'interface',
      which causes this build failure on mingw:
      
      ../../tools/virsh-domain-monitor.c: In function 'cmdDomIfAddr':
      ../../tools/virsh-domain-monitor.c:2233:17: error: expected identifier or '(' before 'struct'
           const char *interface = NULL;
                            ^
      
      See also commit 6512c8b4.  Sadly, I'm not quite sure how to write a
      syntax check that can poison the use of this identifier.
      
      * tools/virsh-domain-monitor.c (cmdDomIfAddr): Use ifacestr instead.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      75d56f51
  6. 28 3月, 2015 2 次提交
  7. 27 3月, 2015 9 次提交
    • P
      tests: introduce qemucaps2xmlmock · eb05cb0d
      Pavel Hrdina 提交于
      We need to mock virFileExists to return true for "/dev/kvm" because the
      test should not depend on host system.
      Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
      eb05cb0d
    • P
      Revert "qemucaps2xmltest: fix test to successfully run without kvm support" · a894d61b
      Pavel Hrdina 提交于
      This reverts commit 49bf09d1.  That
      commit is wrong and doesn't fix the issue.
      Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
      a894d61b
    • P
      virnetlink: fix build error · 0614976b
      Pavel Hrdina 提交于
      Commint 0473b45c introduced new function virNetlinkDelLink, but in
      it's counterpart for non-linux platform there should be ATTRIBUTE_UNUSED
      instead of ATTRIBUTE_UNSUPPORTED.
      Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
      0614976b
    • S
      qemu: end the job when try to blockcopy to non-file destination · c5fbad66
      Shanzhi Yu 提交于
      Blockcopy to non-file destination is not supported according the code,
      but a 'goto endjob' is missed after checking the destination.
      
      This leads to calling drive-mirror with wrong parameters.
      
      Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1206406Signed-off-by: NShanzhi Yu <shyu@redhat.com>
      Signed-off-by: NJán Tomko <jtomko@redhat.com>
      c5fbad66
    • W
      nodeinfo: Increase the num of CPU thread siblings to a larger value · c13de016
      Wei Huang 提交于
      Current libvirt can only handle up to 1023 bytes when it
      reads Linux sysfs topology/thread_siblings. This isn't enough for
      Linux distributions that support a large value. This patch fixes
      the problem by using VIR_ALLOC()/VIR_FREE(), instead of using a
      fixed-size (1024) local char array. In the meanwhile
      SYSFS_THREAD_SIBLINGS_LIST_LENGTH_MAX is increased to 8192 which
      should be large enough for a foreseeable future.
      Signed-off-by: NWei Huang <wei@redhat.com>
      c13de016
    • E
      relaxng: allow : in /dev/disk/by-path names · dfc70875
      Eric Blake 提交于
      On IRC, Hydrar pointed a problem where 'virsh edit' failed on
      his domain created through an ISCSI pool managed by virt-manager,
      all because the XML included a block device with colons in the
      name.
      
      * docs/schemas/basictypes.rng (absFilePath): Add colon as safe.
      * tests/qemuxml2argvdata/qemuxml2argv-disk-iscsi.xml: New file.
      * tests/qemuxml2argvdata/qemuxml2argv-disk-iscsi.args: Likewise.
      * tests/qemuxml2argvtest.c (mymain): Test it.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      dfc70875
    • K
      libxl: Fix memory leak if pthread_create fails. · 95003cd5
      Konrad Rzeszutek Wilk 提交于
      If we fail to create the thread we leak the shutdown_info
      structure.
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      95003cd5
    • L
      util: use netlink to create bridge devices · fc7b23db
      Laine Stump 提交于
      Just as it is possible to delete a bridge device with the netlink
      RTM_DELLINK message, one can be created with the RTM_NEWLINK
      message. Because of differences in the format of the message, it's not
      as straightforward as with virNetlinkDelLink() to create a single
      utility function that can be used to create any type of interface, so
      the new netlink version of virNetDevBridgeCreate() does its own
      construction of the netlink message and calls virNetlinkCommand()
      itself.
      
      This doesn't provide any extra functionality, just provides symmetry
      with the previous commit.
      
      NB: We *could* alter the API of virNetDevBridgeCreate() to take a MAC
      address, and directly program that mac address into the bridge (by
      adding an IFLA_ADDRESS attribute, as is done in
      virNetDevMacVLanCreate()) rather than separately creating the "dummy
      tap" (e.g. virbr0-nic) to maintain a fixed mac address on the bridge,
      but the commit history of virnetdevbridge.c shows that the presence of
      this dummy tap is essential in some older versions of the kernel
      (between 2.6.39 and 3.1 or 3.2, possibly?) to proper operation of IPv6
      DAD, and I don't want to take the chance of breaking something that I
      don't have the time/setup to test (my RHEL6 box is at kernel
      2.6.32-544, and the next lowest kernel I have is 3.17)
      fc7b23db
    • L
      util: use netlink to delete bridge devices · 09778e09
      Laine Stump 提交于
      https://bugzilla.redhat.com/show_bug.cgi?id=1125755
      
      reported that a stray bridge device was left on the system when a
      libvirt network failed to start due to an illegal iptables rule caused
      by bad config. Apparently the reason this was happening was that
      NetworkManager was noticing immediately when the bridge device was
      created and automatically setting it IFF_UP. libvirt would then try to
      setup the iptables rules, get an error back, and since libvirt had
      never IFF_UPed the bridge, it didn't expect that it needed to set it
      ~IFF_UP before deleting it during the cleanup process. But the
      ioctl(SIOCBRDELBR) ioctl will fail to delete a bridge if it is IFF_UP.
      
      Since that bug was reported, NetworkManager has gotten a bit more
      polite in this respect, but just in case something similar happens in
      the future, this patch switches to using the netlink RTM_DELLINK
      message to delete the bridge - unlike SIOCBRDELBR, it will delete the
      requested bridge no matter what the setting of IFF_UP.
      09778e09