1. 23 9月, 2014 1 次提交
  2. 22 9月, 2014 9 次提交
  3. 19 9月, 2014 8 次提交
    • J
      libxl: Drop driver lock in libxlDomainDefineXML · c7892373
      Jim Fehlig 提交于
      There is no need to acquire the driver-wide lock in
      libxlDomainDefineXML.  When switching to jobs in the libxl
      driver, most driver-wide locks were removed.  The locking here
      was preserved since I mistakenly thought virDomainObjListAdd
      needed protection.  This is not the case, so remove the
      unnecessary locking.
      c7892373
    • J
      qemu: Process the hostdev "rawio" setting · 74eaa091
      John Ferlan 提交于
      Mimic the "Disk" processing for 'rawio', but for a scsi_host hostdev
      lun device.
      74eaa091
    • J
      hostdev: Add "rawio" attribute to _virDomainHostdevSubsysSCSI · 58abf1bb
      John Ferlan 提交于
      Add the 'rawio' attribute to match _virDomainDiskDef and process the
      hostdev XML similarly to the disk XML for a lun which supports/requires rawio
      58abf1bb
    • J
      domain_conf: Change virDomainDiskDef 'rawio' to use virTristateBool · 320825b4
      John Ferlan 提交于
      Adjust disk definition for 'rawio' to use the TristateBool logic
      320825b4
    • J
      qemu: Add missing goto on rawio · 8921d488
      John Ferlan 提交于
      Commit id '9a2f36ec' added a build conditional of CAP_SYS_RAWIO
      in order to determine whether or not a disk definition using rawio
      should be allowed on platforms without CAP_SYS_RAWIO. If one was
      found, virReportError was used but the code didn't goto cleanup.
      
      This patch adds the goto.
      8921d488
    • C
      LXC: add HOME environment variable docs · a3bcd863
      Chen Hanxiao 提交于
      commit
      3020594a
      add HOME environment variable.
      Add a doc for this.
      Signed-off-by: NChen Hanxiao <chenhanxiao@cn.fujitsu.com>
      a3bcd863
    • P
      Move the FIPS detection from capabilities · da7799d8
      Pavel Hrdina 提交于
      We are not detecting the presence of FIPS from QEMU, but from procfs and
      that means it's not QEMU capability. It was decided that we will pass
      this flag to QEMU even if it's not supported by old QEMU binaries.
      
      This patch also reverts changes done by commit a21cfb0f to
      qemucapabilitestest and implements a new test case in qemuxml2argvtest.
      
      Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1135431Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
      da7799d8
    • M
      virSecuritySELinuxSetTapFDLabel: Temporarily revert to old behavior · ba7468db
      Michal Privoznik 提交于
      https://bugzilla.redhat.com/show_bug.cgi?id=1141879
      
      A long time ago I've implemented support for so called multiqueue
      net.  The idea was to let guest network traffic be processed by
      multiple host CPUs and thus increasing performance. However, this
      behavior is enabled by QEMU via special ioctl() iterated over the
      all tap FDs passed in by libvirt. Unfortunately, SELinux comes in
      and disallows the ioctl() call because the /dev/net/tun has label
      system_u:object_r:tun_tap_device_t:s0 and 'attach_queue' ioctl()
      is not allowed on tun_tap_device_t type. So after discussion with
      a SELinux developer we've decided that the FDs passed to the QEMU
      should be labelled with svirt_t type and SELinux policy will
      allow the ioctl(). Therefore I've made a patch
      (cf976d9d) that does exactly this. The patch
      was fixed then by a4431931 and
      b635b7a1. However, things are not
      that easy - even though the API to label FD is called
      (fsetfilecon_raw) the underlying file is labelled too! So
      effectively we are mangling /dev/net/tun label. Yes, that broke
      dozen of other application from openvpn, or boxes, to qemu
      running other domains.
      
      The best solution would be if SELinux provides a way to label an
      FD only, which could be then labeled when passed to the qemu.
      However that's a long path to go and we should fix this
      regression AQAP. So I went to talk to the SELinux developer again
      and we agreed on temporary solution that:
      
      1) All the three patches are reverted
      2) SELinux temporarily allows 'attach_queue' on the
      tun_tap_device_t
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      ba7468db
  4. 18 9月, 2014 22 次提交