Skip to content

L
libvirt

openeuler / libvirt

通知 3
Star 0
Fork 0
L
libvirt

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 09 12月, 2019 1 次提交
  3. 06 12月, 2019 1 次提交
  5. 03 12月, 2019 1 次提交
  7. 27 11月, 2019 1 次提交
  9. 26 11月, 2019 3 次提交
    • L
      conf: add hypervisor agnostic, domain start-time, validation function for NetDef · b03d9e95
      由 Laine Stump 提交于 
      <interface> devices (virDomainNetDef) are a bit different from other
types of devices in that their actual type may come from a network (in
the form of a port connection), and that doesn't happen until the
domain is started. This means that any validation of an <interface> at
parse time needs to be a bit liberal in what it accepts - when
type='network', you could think that something is/isn't allowed, but
once the domain is started and a port is created by the configured
network, the opposite might be true.

To solve this problem hypervisor drivers need to do an extra
validation step when the domain is being started. I recently (commit
3cff23f7, libvirt 5.7.0) added a function to peform such validation
for all interfaces to the QEMU driver -
qemuDomainValidateActualNetDef() - but while that function is a good
single point to call for the multiple places that need to "start" an
interface (domain startup, device hotplug, device update), it can't be
called by the other hypervisor drivers, since 1) it's in the QEMU
driver, and 2) it contains some checks specific to QEMU. For
validation that applies to network devices on *all* hypervisors, we
need yet another interface validation function that can be called by
any hypervisor driver (not just QEMU) right after its network port has
been created during domain startup or hotplug. This patch adds that
function - virDomainActualNetDefValidate(), in the conf directory,
and calls it in appropriate places in the QEMU, lxc, and libxl
drivers.

This new function is the place to put all network device validation
that 1) is hypervisor agnostic, and 2) can't be done until we know the
"actual type" of an interface.

There is no framework for validation at domain startup as there is for
post-parse validation, but I don't want to create a whole elaborate
system that will only be used by one type of device. For that reason,
I just made a single function that should be called directly from the
hypervisors, when they are initializing interfaces to start a domain,
right after conditionally allocating the network port (and regardless
of whether or not that was actually needed). In the case of the QEMU
driver, qemuDomainValidateActualNetDef() is already called in all the
appropriate places, so we can just call the new function from
there. In the case of the other hypervisors, we search for
virDomainNetAllocateActualDevice() (which is the hypervisor-agnostic
function that calls virNetworkPortCreateXML()), and add the call to our
new function right after that.

The new function itself could be plunked down into many places in the
code, but we already have 3 validation functions for network devices
in 2 different places (not counting any basic validation done in
virDomainNetDefParseXML() itself):

1) post-parse hypervisor-agnostic
   (virDomainNetDefValidate() - domain_conf.c:6145)
2) post-parse hypervisor-specific
   (qemuDomainDeviceDefValidateNetwork() - qemu_domain.c:5498)
3) domain-start hypervisor-specific
   (qemuDomainValidateActualNetDef() - qemu_domain.c:5390)

I placed (3) right next to (2) when I added it, specifically to avoid
spreading validation all over the code. For the same reason, I decided
to put this new function right next to (1) - this way if someone needs
to add validation specific to qemu, they go to one location, and if
they need to add validation applying to everyone, they go to the
other. It looks a bit strange to have a public function in between a
bunch of statics, but I think it's better than the alternative of
further fragmentation. (I'm open to other ideas though, of course.)
Signed-off-by: NLaine Stump <laine@redhat.com>
Reviewed-by: NCole Robinson <crobinso@redhat.com>
      b03d9e95
    • L
      conf: return a const from virDomainNetGetActualVirtPortProfile · fdcd273b
      由 Laine Stump 提交于 
      This also isn't required (due to the vportprofile being stored in the
NetDef as a pointer rather than being directly contained), but it
seemed dishonest to not mark it as const (and thus permit users to
modify its contents)
Signed-off-by: NLaine Stump <laine@redhat.com>
Reviewed-by: NCole Robinson <crobinso@redhat.com>
      fdcd273b
    • L
      qemu: add mac address to error messages in qemuDomainValidateActualNetDef · 1b029a92
      由 Laine Stump 提交于 
      This makes it easier to understand which interface's config caused the
error.
Signed-off-by: NLaine Stump <laine@redhat.com>
Reviewed-by: NCole Robinson <crobinso@redhat.com>
      1b029a92
  11. 25 11月, 2019 3 次提交
  13. 22 11月, 2019 3 次提交
  15. 21 11月, 2019 3 次提交
  17. 20 11月, 2019 1 次提交
    • M
      qemu: Forcibly mknod() even if it exists · cdd8a669
      由 Michal Privoznik 提交于 
      Another weird bug appeared concerning qemu namespaces. Basically
the problem is as follows:

1) Issue an API that causes libvirt to create a node in domain's
   namespace, say /dev/nvme0n1 with 8:0 as major:minor (the API can
   be attach-disk for instance). Or simply create the node from a
   console by hand.

2) Detach the disk from qemu.

3) Do something that makes /dev/nvme0n1 change it's minor number.

4) Try to attach the disk again.

The problem is, in a few cases - like disk-detach - we don't
remove the corresponding /dev node from the mount namespace
(because it may be used by some other disk's backing chain). But
this creates a problem, because if the node changes its MAJ:MIN
numbers we don't propagate the change into the domain's
namespace. We do plain mknod() and ignore EEXIST which obviously
is not enough because it doesn't guarantee that the node has
updated MAJ:MIN pair.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1752978Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      cdd8a669
  19. 19 11月, 2019 1 次提交
  21. 18 11月, 2019 1 次提交
  23. 15 11月, 2019 6 次提交
  25. 14 11月, 2019 2 次提交
  27. 13 11月, 2019 2 次提交
  29. 12 11月, 2019 2 次提交
  31. 08 11月, 2019 1 次提交
  33. 07 11月, 2019 1 次提交
  35. 25 10月, 2019 2 次提交
  37. 23 10月, 2019 1 次提交
  39. 21 10月, 2019 4 次提交