Removing multipass leaves mpvirtbr0 bridge behind #327
Comments
|
So we're trying to clean up the bridge on exit (bug part no. 1) and create a new bridge when one exists already on startup (bug part no.2). I wonder if we should just take over the existing one instead? After all there's no good reason for a user to have a |
Closed
bors bot
added a commit
that referenced
this issue
Nov 13, 2018
427: libvirt: Destroy bridge in the LibVirtVirtualMachineFactory dtor r=Saviq a=townsend2010 Revert back to using a non-persistent libvirt network and instead, save the subnet like is done for the Qemu backend. Fixes #327, fixes #413 Co-authored-by: Chris Townsend <[email protected]>
bors bot
added a commit
that referenced
this issue
Nov 13, 2018
427: libvirt: Destroy bridge in the LibVirtVirtualMachineFactory dtor r=Saviq a=townsend2010 Revert back to using a non-persistent libvirt network and instead, save the subnet like is done for the Qemu backend. Fixes #327, fixes #413 Co-authored-by: Chris Townsend <[email protected]>
bors bot
added a commit
that referenced
this issue
Nov 13, 2018
427: libvirt: Destroy bridge in the LibVirtVirtualMachineFactory dtor r=Saviq a=townsend2010 Revert back to using a non-persistent libvirt network and instead, save the subnet like is done for the Qemu backend. Fixes #327, fixes #413 Co-authored-by: Chris Townsend <[email protected]>
Merged
bors bot
added a commit
that referenced
this issue
Dec 20, 2018
551: Release 2018.12.1 r=townsend2010 a=Saviq ### Highlights - On Linux, suspending/resuming the instance to/from disk is now supported. (#374) - Better handling of delayed shutdown including posting `wall` messages to logged in users and allowing log ins to the instance unless 1 minute or less remains until shutdown. (#461, #50) - On Linux, all CPU flags should be passed into the running instance on newly created instances. (#516) - Fixed some races around mount handling. (#514, #520) ### Bugs fixed: - make the recover command idempotent (#528) - explicitly stop mounts when deleting an instance to avoid a race (#520) - be smarter about what group owns the multipass socket (#513, #523) - pass through all CPU flags when launching QEMU or libvirt instances (#516) - use `info` log level for metrics issues (#515) - fix potential race when starting a mount (#514) - use `wall` shutdown messages for users logged into VM when delayed shutdown is initiated (#501) - fix crash if exception during daemon start up (#487) - refactor CLI code (#468) - add default uid/gid mapping (#331) - fix file metadata passthrough - display uid/gid maps in info command (#439) - add support for the suspend command (#374) - shell to machine in delayed stop state (#461) - improve uid/gid validation (#479) - avoid leaking the libvirt bridge (#327, #413) - add a restart command (#217) - upgrade 3rd-party versions (#471) Co-authored-by: bors[bot] <bors[bot]@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I installed the multipass snap (revision 334 from beta channel) and configured it to use the libvirt driver. I created a few containers and then removed the multipass snap from the system. After the snap was removed there was still a
mpvirtbr0network device present. A new installation of the multipass snap caused now ampvirtbr1device to be created which will cause multipass to not find the right network bridge when the system is rebooted. libvirt will fail to start then with:Aug 08 10:06:44 saturn libvirtd[3188]: Cannot get interface MTU on 'mpvirtbr1': No such deviceand multipassd with
Aug 06 09:07:54 saturn multipass.multipassd[5868]: libvirt: XML-RPC error : Failed to connect socket to '/var/snap/multipass/common/run/libvirt/libvirt-sock': Connection refusedOnly way to get out of this is to manually modify the configuration of all present containers to use
mpvirtbr0instead ofmpvirtbr1.The text was updated successfully, but these errors were encountered: