1. 17 5月, 2017 1 次提交
  2. 16 5月, 2017 4 次提交
  3. 15 5月, 2017 4 次提交
  4. 11 5月, 2017 1 次提交
  5. 10 5月, 2017 2 次提交
  6. 09 5月, 2017 1 次提交
  7. 03 5月, 2017 6 次提交
    • M
      qemuDomainDetachDeviceUnlink: Don't unlink files we haven't created · 2f0b3b10
      Michal Privoznik 提交于
      Even though there are several checks before calling this function
      and for some scenarios we don't call it at all (e.g. on disk hot
      unplug), it may be possible to sneak in some weird files (e.g. if
      domain would have RNG with /dev/shm/some_file as its backend). No
      matter how improbable, we shouldn't unlink it as we would be
      unlinking a file from the host which we haven't created in the
      first place.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NCedric Bosdonnat <cbosdonnat@suse.com>
      2f0b3b10
    • M
      qemuDomainAttachDeviceMknodRecursive: Don't try to create devices under preserved mount points · b3418f36
      Michal Privoznik 提交于
      Just like in previous commit, this fixes the same issue for
      hotplug.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NCedric Bosdonnat <cbosdonnat@suse.com>
      b3418f36
    • M
      qemuDomainCreateDeviceRecursive: Don't try to create devices under preserved mount points · e30dbf35
      Michal Privoznik 提交于
      While the code allows devices to already be there (by some
      miracle), we shouldn't try to create devices that don't belong to
      us. For instance, we shouldn't try to create /dev/shm/file
      because /dev/shm is a mount point that is preserved. Therefore if
      a file is created there from an outside (e.g. by mgmt application
      or some other daemon running on the system like vhostmd), it
      exists in the qemu namespace too as the mount point is the same.
      It's only /dev and /dev only that is different. The same
      reasoning applies to all other preserved mount points.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NCedric Bosdonnat <cbosdonnat@suse.com>
      e30dbf35
    • M
      qemuDomainCreateDeviceRecursive: pass a structure instead of bare path · 26c14be8
      Michal Privoznik 提交于
      Currently, all we need to do in qemuDomainCreateDeviceRecursive() is to
      take given @device, get all kinds of info on it (major & minor numbers,
      owner, seclabels) and create its copy at a temporary location @path
      (usually /var/run/libvirt/qemu/$domName.dev), if @device live under
      /dev. This is, however, very loose condition, as it also means
      /dev/shm/* is created too. Therefor, we will need to pass more arguments
      into the function for better decision making (e.g. list of mount points
      under /dev). Instead of adding more arguments to all the functions (not
      easily reachable because some functions are callback with strictly
      defined type), lets just turn this one 'const char *' into a 'struct *'.
      New "arguments" can be then added at no cost.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NCedric Bosdonnat <cbosdonnat@suse.com>
      26c14be8
    • M
      qemuDomainBuildNamespace: Move /dev/* mountpoints later · a7cc039d
      Michal Privoznik 提交于
      When setting up mount namespace for a qemu domain the following
      steps are executed:
      
      1) get list of mountpoints under /dev/
      2) move them to /var/run/libvirt/qemu/$domName.ext
      3) start constructing new device tree under /var/run/libvirt/qemu/$domName.dev
      4) move the mountpoint of the new device tree to /dev
      5) restore original mountpoints from step 2)
      
      Note the problem with this approach is that if some device in step
      3) requires access to a mountpoint from step 2) it will fail as
      the mountpoint is not there anymore. For instance consider the
      following domain disk configuration:
      
          <disk type='file' device='disk'>
            <driver name='qemu' type='raw'/>
            <source file='/dev/shm/vhostmd0'/>
            <target dev='vdb' bus='virtio'/>
            <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/>
          </disk>
      
      In this case operation fails as we are unable to create vhostmd0
      in the new device tree because after step 2) there is no /dev/shm
      anymore. Leave aside fact that we shouldn't try to create devices
      living in other mountpoints. That's a separate bug that will be
      addressed later.
      
      Currently, the order described above is rearranged to:
      
      1) get list of mountpoints under /dev/
      2) start constructing new device tree under /var/run/libvirt/qemu/$domName.dev
      3) move them to /var/run/libvirt/qemu/$domName.ext
      4) move the mountpoint of the new device tree to /dev
      5) restore original mountpoints from step 3)
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NCedric Bosdonnat <cbosdonnat@suse.com>
      a7cc039d
    • J
      qemu: Fix persistent migration of transient domains · 59307fad
      Jiri Denemark 提交于
      While fixing a bug with incorrectly freed memory in commit
      v3.1.0-399-g5498aa29, I accidentally broke persistent migration of
      transient domains. Before adding qemuDomainDefCopy in the path, the code
      just took NULL from vm->newDef and used it as the persistent def, which
      resulted in no persistent XML being sent in the migration cookie. This
      scenario is perfectly valid and the destination correctly handles it by
      using the incoming live definition and storing it as the persistent one.
      
      After the mentioned commit libvirtd would just segfault in the described
      scenario.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1446205Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      59307fad
  8. 02 5月, 2017 1 次提交
  9. 28 4月, 2017 13 次提交
  10. 27 4月, 2017 7 次提交