Re: [PATCH] qemu: add macvlan delete to qemuDomainAttachNetDevice cleanup

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 07/02/2013 07:15 PM, Matthew Rosato wrote:
On 07/01/2013 06:42 PM, Laine Stump wrote:
On 07/01/2013 11:04 AM, Viktor Mihajlovski wrote:
From: Matthew Rosato <mjrosato@xxxxxxxxxxxxxxxxxx>

This is a good catch, but incomplete. If you search for other
occurrences of virDomainConfNWFilterTeardown() and
qemuPhysIfaceConnect(), you will find the same problem exists in two
other places in the code:

    qemuBuildInterfaceCommandLine (during error cleanup, needs to be
called
                                   for the one interface that was
partially
                                   created)
    qemuBuildCommandLine          (during error cleanup, needs to be
called
                                   for all interfaces that were
completely
                                   created (up to last_good_net))

We really should fix them all in one patch, since they are all the same
problem.

Thank you for your comments.  I tested the two cases that you mentioned
by forcing errors; in both, the macvtap will be released by code in
qemuProcessStop(), which releases any macvtap in the domain's nets list.
  Is this sufficient, or did you still want something changed?

True ... the only other driver function that invokes qemBuildCommandLine
is connectDomainXMLToNative and here some premonition has prevented
the allocation of macvtap devices :)

(Ideally, *all* guest interface setup for each interface should be
handled in a single function, and that function should be in the network
driver (networkReleaseActualDevice() seems properly situated). That way
it could be put behind an RPC, and the non-privileged libvirtd could
call it too (with proper credentials). That is a larger problem, though.)

I agree, to both parts (proper structure and magnitude of effort).

Laine,
given that the patch solves the problem at hand and the other cases
are handled properly: are you OK with the current, simple approach?

The issue for us is that the dangling macvtap device prevents the reuse
of the interface's MAC address on s390 and there's no libvirt means
to delete the macvtap interface.

--

Mit freundlichen Grüßen/Kind Regards
   Viktor Mihajlovski

IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Köderitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]