1. 27 9月, 2019 1 次提交
    • L
      conf: utility function to update entry in def->nets array · 7e490cda
      Laine Stump 提交于
      A virDomainNetDef object in a domain's nets array might contain a
      virDomainHostdevDef, and when this is the case, the domain's hostdevs
      array will also have a pointer to this embedded hostdev (this is done
      so that internal functions that need to perform some operation on all
      hostdevs won't leave out the type='hostdev' network interfaces).
      
      When a network device was updated with virDomainUpdateDeviceFlags(),
      we were replacing the entry in the nets array (and free'ing the
      original) but forgetting about the pointer in the hostdevs array
      (which would then point to the now-free'd hostdev contained in the old
      net object.) This often resulted in a libvirtd crash.
      
      The solution is to add a function, virDomainNetUpdate(), called by
      qemuDomainUpdateDeviceConfig(), that updates the hostdevs array
      appropriately along with the nets array.
      
      Resolves: https://bugzilla.redhat.com/1558934Signed-off-by: NLaine Stump <laine@redhat.com>
      Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
      7e490cda
  2. 25 9月, 2019 5 次提交
  3. 19 9月, 2019 1 次提交
  4. 16 9月, 2019 1 次提交
  5. 11 9月, 2019 1 次提交
  6. 10 9月, 2019 1 次提交
    • L
      conf: new "managed" attribute for target dev of <interface type='ethernet'> · 77f72a86
      Laine Stump 提交于
      Although <interface type='ethernet'> has always been able to use an
      existing tap device, this is just a coincidence due to the fact that
      the same ioctl is used to create a new tap device or get a handle to
      an existing device.
      
      Even then, once we have the handle to the device, we still insist on
      doing extra setup to it (setting the MAC address and IFF_UP).  That
      *might* be okay if libvirtd is running as a privileged process, but if
      libvirtd is running as an unprivileged user, those attempted
      modifications to the tap device will fail (yes, even if the tap is set
      to be owned by the user running libvirtd). We could avoid this if we
      knew that the device already existed, but as stated above, an existing
      device and new device are both accessed in the same manner, and
      anyway, we need to preserve existing behavior for those who are
      already using pre-existing devices with privileged libvirtd (and
      allowing/expecting libvirt to configure the pre-existing device).
      
      In order to cleanly support the idea of using a pre-existing and
      pre-configured tap device, this patch introduces a new optional
      attribute "managed" for the interface <target> element. This
      attribute is only valid for <interface type='ethernet'> (since all
      other interface types have mandatory config that doesn't apply in the
      case where we expect the tap device to be setup before we
      get it). The syntax would look something like this:
      
         <interface type='ethernet'>
            <target dev='mytap0' managed='no'/>
            ...
         </interface>
      
      This patch just adds managed to the grammar and parser for <target>,
      but has no functionality behind it.
      
      (NB: when managed='no' (the default when not specified is 'yes'), the
      target dev is always a name explicitly provided, so we don't
      auto-remove it from the config just because it starts with "vnet"
      (VIR_NET_GENERATED_TAP_PREFIX); this makes it possible to use the
      same pattern of names that libvirt itself uses when it automatically
      creates the tap devices.)
      Signed-off-by: NLaine Stump <laine@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      77f72a86
  7. 06 9月, 2019 1 次提交
  8. 21 8月, 2019 1 次提交
  9. 19 8月, 2019 1 次提交
  10. 12 8月, 2019 1 次提交
  11. 09 8月, 2019 3 次提交
  12. 06 8月, 2019 1 次提交
  13. 27 7月, 2019 2 次提交
  14. 26 7月, 2019 2 次提交
  15. 25 7月, 2019 2 次提交
  16. 18 7月, 2019 2 次提交
  17. 15 7月, 2019 1 次提交
  18. 21 6月, 2019 1 次提交
  19. 17 6月, 2019 4 次提交
  20. 13 6月, 2019 1 次提交
  21. 03 6月, 2019 1 次提交
  22. 07 5月, 2019 1 次提交
    • E
      conf: Add parameter to virDomainDiskSourceFormat · 1ec3e397
      Eric Blake 提交于
      Commits 4bc42986 and 218c81ea removed virDomainStorageSourceFormat on
      the grounds that there were no external callers; however, the upcoming
      backup code wants to output a <target> (push mode) or <scratch> (pull
      mode) element that is in all other respects identical to a domain's
      <source> element, where the previous virDomainStorageSourceFormat fit
      the bill nicely. But rather than reverting the commits, it's easier to
      just add an additional parameter for the element name to use, and
      update all callers.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      1ec3e397
  23. 18 4月, 2019 2 次提交
  24. 17 4月, 2019 3 次提交