1. 21 2月, 2015 8 次提交
  2. 19 2月, 2015 1 次提交
    • J
      Search for schemas and cpu_map.xml in source tree · bc6e2063
      Jiri Denemark 提交于
      Not all files we want to find using virFileFindResource{,Full} are
      generated when libvirt is built, some of them (such as RNG schemas) are
      distributed with sources. The current API was not able to find source
      files if libvirt was built in VPATH.
      
      Both RNG schemas and cpu_map.xml are distributed in source tarball.
      Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      bc6e2063
  3. 13 2月, 2015 1 次提交
  4. 12 2月, 2015 4 次提交
    • M
      docs, schema, conf: Add support for setting scheduler parameters of guest threads · 8680ea97
      Martin Kletzander 提交于
      In order for QEMU vCPU (and other) threads to run with RT scheduler,
      libvirt needs to take care of that so QEMU doesn't have to run privileged.
      
      Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1178986Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
      8680ea97
    • L
      domain: include portgroup in interface status xml · 89d26890
      Laine Stump 提交于
      Prior to commit 7d5bf484 (first appearing in libvirt 1.2.2), the
      status XML of a domain's interface was missing a lot of important
      information; mainly it just output the config of the interface, plus
      the name of the tap device and qemu device alias. Commit 7d5bf484
      changed the status XML to include many important bits of information
      that were required to make network "hook" scripts useful - bandwidth
      information, vlan tag, the name of the bridge (or physical device in
      the case of macvtap) that the tap/macvtap device was attached to - the
      commit log for 7d5bf484 has a very detailed explanation of the
      change. For quick reference - in the example given there, prior to the
      change, status XML looked like figure [C]:
      
            <interface type='network'>
              <source network='testnet' portgroup='admin'/>
              <target dev='macvtap0'/>
              <alias name='net0'/>
              <address type='pci' domain='0x0000' bus='0x00'
                       slot='0x03' function='0x0'/>
            </interface>
      
      and after the change, it looked like figure [E]:
      
            <interface type='direct'>
              <source dev='p4p1_0' mode='bridge'/>
              <bandwidth>
                  <inbound average='1000' peak='5000' burst='1024'/>
                  <outbound average='128' peak='256' burst='256'/>
              </bandwidth>
              <target dev='macvtap0'/>
              <alias name='net0'/>
              <address type='pci' domain='0x0000' bus='0x00'
                       slot='0x03' function='0x0'/>
            </interface>
      
      You'll notice that bandwidth info, physdev, and macvtap mode have been
      added, but the network and portgroup names are now missing - I didn't
      think that this information was of any use once the needed
      bandwidth/vlan/etc config had been pulled from the network/portgroup.
      
      I was wrong.
      
      A few months after that change a user on IRC asked what happened to
      portgroup in the status XML and described how he used it (more or less
      as a tag to decide what external information to use in a hook script
      that was run at startup/migration time - see
      http://wiki.libvirt.org/page/OVS_and_PVLANS ). At that time I planned
      to make a patch to re-add portgroup, but life intervened as that was
      just prior to a transatlantic move involving several weeks of
      "vacation". During this time I somehow forgot to make the patch, and
      also mistakenly remembered that I *had* made it.
      
      Subsequent to this, as a part of mprivozn's work to add support for
      network-specific hooks, I did re-add the output of the network name in
      status XML, but once again completely forgot about portgroup. This was
      in commit a3609121 (first appearing in libvirt 1.2.11). This made the
      status XML from the above example look like this:
      
            <interface type='direct'>
              <source network='testnet' dev='p4p1_0' mode='bridge'/>
              <bandwidth>
                  <inbound average='1000' peak='5000' burst='1024'/>
                  <outbound average='128' peak='256' burst='256'/>
              </bandwidth>
              <target dev='macvtap0'/>
              <alias name='net0'/>
              <address type='pci' domain='0x0000' bus='0x00'
                       slot='0x03' function='0x0'/>
            </interface>
      
      *This* patch just adds the portgroup back to the status XML, so the
       same example interface will look like this:
      
            <interface type='direct'>
              <source network='testnet' portgroup='admin'
                      dev='p4p1_0' mode='bridge'/>
              <bandwidth>
                  <inbound average='1000' peak='5000' burst='1024'/>
                  <outbound average='128' peak='256' burst='256'/>
              </bandwidth>
              <target dev='macvtap0'/>
              <alias name='net0'/>
              <address type='pci' domain='0x0000' bus='0x00'
                       slot='0x03' function='0x0'/>
            </interface>
      
      The result is that the status XML now contains all information about
      how the interface is setup (bandwidth, physical device, tap device,
      etc), in addition to pointers to its origin (the network and
      portgroup).
      89d26890
    • L
      domain: avoid potential memory leak in virDomainGraphicsListenSet*() · 6d1194ff
      Laine Stump 提交于
      virDomainGraphicsListenSetAddress() and
      virDomainGraphicsListenSetNetwork() both set their respective char* to
      NULL directly when asked to set it to NULL, which is okay as long as
      it's already set to NULL. If these functions are ever called to clear
      a listen object that has a valid string in address or network, it will
      end up leaking the old value. Currently that doesn't happen, so this
      is just a preemptive strike.
      6d1194ff
    • L
      domain: backfill listen address to parent <graphics> listen attribute · 69929941
      Laine Stump 提交于
      Prior to 0.9.4, libvirt only supported a single listen, and it had to
      be an IP address:
      
         <graphics listen='1.2.3.4' ..../>
      
      Starting with 0.9.4, a graphics element could have a <listen>
      subelement (actually the grammar supports multiples, but all of the
      drivers only support a single <listen> per <graphics>), and that
      listen element can be of type='address' or type='network'. For
      type='address', <listen> also has an attribute called 'address' which
      contains the IP address for listening:
      
          <graphics ....>
            <listen type='address' address='1.2.3.4' .../>
          </graphics>
      
      type can also be "network", and in that case listen will have a
      "network" attribute which will contain the name of a libvirt
      network:
      
          <graphics ....>
            <listen type='network' network='testnet' .../>
          </graphics>
      
      At domain start (or migrate) time, libvirt will attempt to
      find an IP address associated with that network (e.g. the IP address
      of the bridge device used by the network, or the physical device
      listed in <forward dev='physdev'/>) and fill in that address in the
      status XML:
      
          <graphics ....>
            <listen type='network' network='testnet' address='1.2.3.4' .../>
          </graphics>
      
      In the case that a <graphics> element has a <listen> subelement of
      type='address', that listen subelement's "address" attribute is
      backfilled into the parent graphics element's "listen" *attribute* for
      backward compatibility (so that a management application unaware of
      the separate <listen> element can still learn the listen
      address). This backfill should be done with the IP learned from
      type='network' as well, and that's what this patch does:
      
          <graphics listen='1.2.3.4' ....>
            <listen type='network' network='testnet' address='1.2.3.4' .../>
          </graphics>
      
      This is a continuation of the fix for:
      
         https://bugzilla.redhat.com/show_bug.cgi?id=1191016
      69929941
  5. 11 2月, 2015 2 次提交
    • Z
      conf: Fix libvirtd crash and memory leak caused by virDomainVcpuPinDel() · 2d27dcb0
      Zhang Bo 提交于
      The function virDomainVcpuPinDel() used vcpupin_list to stand for
      def->cputune.vcpupin, which made the codes more readable.
      However, in this function, it will realloc vcpupin_list later.
      As the definition of realloc(), it may free vcpupin_list and then
      points it to a new-realloced address, but def->cputune.vcpupin doesn't
      point to the new address(it's freed however).
      Thus,
      1) When we refer to the def->cputune.vcpupin afterwards, which was freed
      by realloc(), an INVALID READ occurs, and libvirtd may crash.
      2) As no one will use vcpupin_list any more, and no one frees it(it's just
      alloced by realloc()), memory leak occurs.
      
      Part of the valgrind logs are shown as below:
      ==1837== Thread 15:
      ==1837== Invalid read of size 8
      ==1837==    at 0x5367337: virDomainDefFormatInternal (domain_conf.c:18392)
              which is : virBufferAsprintf(buf, "<vcpupin vcpu='%u' ",
                                def->cputune.vcpupin[i]->vcpuid);
      ==1837==    by 0x536966C: virDomainObjFormat (domain_conf.c:18970)
      ==1837==    by 0x5369743: virDomainSaveStatus (domain_conf.c:19166)
      ==1837==    by 0x117B26DC: qemuDomainPinVcpuFlags (qemu_driver.c:4586)
      ==1837==    by 0x53EA313: virDomainPinVcpuFlags (libvirt.c:9803)
      ==1837==    by 0x14CB7D: remoteDispatchDomainPinVcpuFlags (remote_dispatch.h:6762)
      ==1837==    by 0x14CC81: remoteDispatchDomainPinVcpuFlagsHelper (remote_dispatch.h:6740)
      ==1837==    by 0x5464C30: virNetServerProgramDispatchCall (virnetserverprogram.c:437)
      ==1837==    by 0x546507A: virNetServerProgramDispatch (virnetserverprogram.c:307)
      ==1837==    by 0x171B83: virNetServerProcessMsg (virnetserver.c:172)
      ==1837==    by 0x171E6E: virNetServerHandleJob (virnetserver.c:193)
      ==1837==    by 0x5318E78: virThreadPoolWorker (virthreadpool.c:145)
      ==1837==  Address 0x12ea2870 is 0 bytes inside a block of size 16 free'd
      ==1837==    at 0x4C291AC: realloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
      ==1837==    by 0x52A3D14: virReallocN (viralloc.c:245)
      ==1837==    by 0x52A3DFB: virShrinkN (viralloc.c:372)
      ==1837==    by 0x52A3F57: virDeleteElementsN (viralloc.c:503)
      ==1837==    by 0x533939E: virDomainVcpuPinDel (domain_conf.c:15405)  //doReset为true时才会进到。
      ==1837==    by 0x117B2642: qemuDomainPinVcpuFlags (qemu_driver.c:4573)
      ==1837==    by 0x53EA313: virDomainPinVcpuFlags (libvirt.c:9803)
      ==1837==    by 0x14CB7D: remoteDispatchDomainPinVcpuFlags (remote_dispatch.h:6762)
      ==1837==    by 0x14CC81: remoteDispatchDomainPinVcpuFlagsHelper (remote_dispatch.h:6740)
      ==1837==    by 0x5464C30: virNetServerProgramDispatchCall (virnetserverprogram.c:437)
      ==1837==    by 0x546507A: virNetServerProgramDispatch (virnetserverprogram.c:307)
      ==1837==    by 0x171B83: virNetServerProcessMsg (virnetserver.c:172)
      
      Steps to reproduce the problem:
      1) use virDomainPinVcpuFlags() to pin a guest's vcpu to all the pcpus
      of the host.
      
      This patch uses def->cputune.vcpupin instead of vcpupin_list to do the
      realloc() job, to avoid invalid read or memory leaking.
      Signed-off-by: NZhang Bo <oscar.zhangbo@huawei.com>
      Signed-off-by: Yue Wenyuan <yuewenyuan@huawei.com@huawei.com>
      2d27dcb0
    • E
      conf: forbid seclabel duplicates for domain devices · 357f0072
      Erik Skultety 提交于
      Parser checks for per-domain seclabel duplicates, so it would be nice if
      it checked for per-device seclabel duplicates the same way
      
      Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1165485
      357f0072
  6. 10 2月, 2015 3 次提交
  7. 09 2月, 2015 1 次提交
  8. 06 2月, 2015 1 次提交
  9. 04 2月, 2015 2 次提交
  10. 30 1月, 2015 1 次提交
    • M
      conf: Don't mangle vcpu placement randomly · bbd3eb50
      Michal Privoznik 提交于
      https://bugzilla.redhat.com/show_bug.cgi?id=1170492
      
      In one of our previous commits (dc8b7ce7) we've done a functional
      change even though it was intended as pure refactor. The problem is,
      that the following XML:
      
       <vcpu placement='static' current='2'>6</vcpu>
       <cputune>
         <emulatorpin cpuset='1-3'/>
       </cputune>
       <numatune>
         <memory mode='strict' placement='auto'/>
       </numatune>
      
      gets translated into this one:
      
       <vcpu placement='auto' current='2'>6</vcpu>
       <cputune>
         <emulatorpin cpuset='1-3'/>
       </cputune>
       <numatune>
         <memory mode='strict' placement='auto'/>
       </numatune>
      
      We should not change the vcpu placement mode. Moreover, we're doing
      something similar in case of emulatorpin and iothreadpin. If they were
      set, but vcpu placement was auto, we've mistakenly removed them from
      the domain XML even though we are able to set them independently on
      vcpus.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      bbd3eb50
  11. 29 1月, 2015 1 次提交
  12. 28 1月, 2015 1 次提交
    • J
      Split qemuDomainChrInsert into two parts · daf51be5
      Ján Tomko 提交于
      Do the allocation first, then add the actual device.
      The second part should never fail. This is good
      for live hotplug where we don't want to remove the device
      on OOM after the monitor command succeeded.
      
      The only change in behavior is that on failure, the
      vmdef->consoles array is freed, not just the first console.
      daf51be5
  13. 27 1月, 2015 1 次提交
    • D
      lxc: only write XML once for lxc controller · 0a8addc1
      Daniel P. Berrange 提交于
      Currently when launching the LXC controller we first write out
      the plain, inactive XML configuration, then launch the controller,
      then replace the file with the live status XML configuration.
      By good fortune this hasn't caused any problems other than some
      misleading error messages during failure scenarios.
      
      This simplifies the code so it only writes out the XML once and
      always writes the live status XML. To do this we need to handshake
      with the child process, to make execution pause just before exec()
      so we can write the XML status with the child PID present.
      0a8addc1
  14. 23 1月, 2015 1 次提交
    • E
      conf: virDomainDefMaybeAddController tweak return code · 852cea52
      Erik Skultety 提交于
      Previously the function returned either -1 in case of an error or 0 on
      success. However, we should also distinguish between a case we
      successfully added a controller and a case there wasn't a need to add any
      controller
      852cea52
  15. 16 1月, 2015 6 次提交
  16. 14 1月, 2015 3 次提交
    • M
      conf: Increase virNetDevBandwidthParse intelligence · a605025c
      Michal Privoznik 提交于
      There's this function virNetDevBandwidthParse which parses the
      bandwidth XML snippet. But it's not clever much. For the
      following XML it allocates the virNetDevBandwidth structure even
      though it's completely empty:
      
          <bandwidth>
          </bandwidth>
      
      Later in the code there are some places where we check if
      bandwidth was set or not. And since we obtained pointer from the
      parsing function we think that it is when in fact it isn't.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      a605025c
    • D
      Give virDomainDef parser & formatter their own flags · 0ecd6851
      Daniel P. Berrange 提交于
      The virDomainDefParse* and virDomainDefFormat* methods both
      accept the VIR_DOMAIN_XML_* flags defined in the public API,
      along with a set of other VIR_DOMAIN_XML_INTERNAL_* flags
      defined in domain_conf.c.
      
      This is seriously confusing & error prone for a number of
      reasons:
      
       - VIR_DOMAIN_XML_SECURE, VIR_DOMAIN_XML_MIGRATABLE and
         VIR_DOMAIN_XML_UPDATE_CPU are only relevant for the
         formatting operation
       - Some of the VIR_DOMAIN_XML_INTERNAL_* flags only apply
         to parse or to format, but not both.
      
      This patch cleanly separates out the flags. There are two
      distint VIR_DOMAIN_DEF_PARSE_* and VIR_DOMAIN_DEF_FORMAT_*
      flags that are used by the corresponding methods. The
      VIR_DOMAIN_XML_* flags received via public API calls must
      be converted to the VIR_DOMAIN_DEF_FORMAT_* flags where
      needed.
      
      The various calls to virDomainDefParse which hardcoded the
      use of the VIR_DOMAIN_XML_INACTIVE flag change to use the
      VIR_DOMAIN_DEF_PARSE_INACTIVE flag.
      0ecd6851
    • D
      Decouple CPU XML formatting from domain XML public API flags · e34473c1
      Daniel P. Berrange 提交于
      The virCPUDefFormat* methods were relying on the VIR_DOMAIN_XML_*
      flag definitions. It is not desirable for low level internal
      functions to be coupled to flags for the public API, since they
      may need to be called from several different contexts where the
      flags would not be appropriate.
      e34473c1
  17. 13 1月, 2015 1 次提交
  18. 09 1月, 2015 1 次提交
    • L
      conf: Correctly format controller's driver · 97fac17c
      Luyao Huang 提交于
      https://bugzilla.redhat.com/show_bug.cgi?id=1179684
      
      The way that we currently generate the <driver/> for <controller/> is
      just madness:
      
          <controller type='scsi' index='0' model='virtio-scsi'>
            <driver queues='12'/>
            <driver cmd_per_lun='123'/>
            <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
          </controller>
      
      It's obvious that we should be aiming at the following:
      
          <controller type='scsi' index='0' model='virtio-scsi'>
            <driver queues='12' cmd_per_lun='123'/>
            <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
          </controller>
      Signed-off-by: NLuyao Huang <lhuang@redhat.com>
      97fac17c
  19. 07 1月, 2015 1 次提交