gnome-boxes pulls libvirt-daemon-config-network into the F21 workstation livecd. This is problematic when running the livecd inside a VM that is using the libvirt 'default' virtual network with the same address range, the end result is that the VM has no network access to the outside world. We've tried to mitigate this at the libvirt level, but it doesn't fix the livecd case. For context, see https://bugzilla.redhat.com/show_bug.cgi?id=1146232 I suggest we drop the gnome-boxes hard dependency for F21 GA. It can then be reintroduced with a gnome-boxes update after F21 is out the door, since installing libvirt-daemon-config-network on a per VM basis should be safe, it's just an issue having the same address range hardcoded for every F21 install from livecd.
Proposing as an F21 final blocker, since no network connectivity inside a livecd VM likely violates some install criteria.
Just noticed now that the libvirt bug, bug 1146232, is marked as a final release blocker. boxes guys, thoughts on this? will boxes gracefully revert back to using usermode networking if the default network isn't around? any volunteers to make this change and test it?
I think it should yeah, Zeeshan, can you confirm?
Discussed in 2014-11-19 blocker review meeting. "This bug tries to solve the same issue as bug 1146232 which is already blocker."
(In reply to Mike Ruckman from comment #4) > Discussed in 2014-11-19 blocker review meeting. "This bug tries to solve the > same issue as bug 1146232 which is already blocker." Yeah but... this is where the fix is going to be, and it isn't going to fully 'fix' bug 1146232. If a gnome-boxes update is pushed referencing the libvirt bug, is the QA process going to let it through even though the components are mismatched?
Sorry for incomplete info. We don't need to solve the root problem completely, we just need to satisfy the criteria, therefore networking must work in VMs, regardless of circumstances (in a reasonable extent). We assumed this is just one avenue how to fix it, therefore we didn't want to block on it. It's true that it would require us to watch it more carefully to see which package update is supposed to fix the bug (adding a comment in the approved blocker bug would help us). Alternatively, we can transfer the blocker status here, if boxes maintainers are OK with the change and nobody else sees any other option how to fix it in the nearest future (~two weeks).
(In reply to Christophe Fergeau from comment #3) > I think it should yeah, Zeeshan, can you confirm? Sorry, I totally missed a few comments out. Yes, the code in Boxes reverts back to old usermode networking if virbr0 is not up. However, this is only done for new machines. while Boxes updates existing machines to use virbr0 when/if it is available, it doesn't do the opposite. i-e existing machines using virbr0 will continue to do so.
(In reply to Zeeshan Ali from comment #7) > (In reply to Christophe Fergeau from comment #3) > > I think it should yeah, Zeeshan, can you confirm? > > Sorry, I totally missed a few comments out. Yes, the code in Boxes reverts > back to old usermode networking if virbr0 is not up. However, this is only > done for new machines. while Boxes updates existing machines to use virbr0 > when/if it is available, it doesn't do the opposite. i-e existing machines > using virbr0 will continue to do so. I don't think that should be a problem, the only thing we care about is what packages get baked into the livecd. After GA is out, we can push a boxes update with the dependency restored, and in practice I don't think anyone will be affected.
gnome-boxes-3.14.2-2.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/gnome-boxes-3.14.2-2.fc21
Package gnome-boxes-3.14.2-2.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing gnome-boxes-3.14.2-2.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-15596/gnome-boxes-3.14.2-2.fc21 then log in and leave karma (feedback).
Also fixes https://bugzilla.redhat.com/show_bug.cgi?id=1146232
I think it's clearer to transfer the blocker status here from #1146232 , now I think about it, as this doesn't exactly 'fix' that bug but works around a specific case of it for the F21 release. We don't want to close that bug when this update goes out, I don't think, so it's not appropriate to rely on that bug's dependency on this one, it makes it clearer to have this as the blocker directly. So, marking as an AcceptedBlocker.
gnome-boxes-3.14.2-2.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to Cole Robinson from comment #8) > (In reply to Zeeshan Ali from comment #7) > > (In reply to Christophe Fergeau from comment #3) > > > I think it should yeah, Zeeshan, can you confirm? > > > > Sorry, I totally missed a few comments out. Yes, the code in Boxes reverts > > back to old usermode networking if virbr0 is not up. However, this is only > > done for new machines. while Boxes updates existing machines to use virbr0 > > when/if it is available, it doesn't do the opposite. i-e existing machines > > using virbr0 will continue to do so. > > I don't think that should be a problem, the only thing we care about is what > packages get baked into the livecd. After GA is out, we can push a boxes > update with the dependency restored, and in practice I don't think anyone > will be affected. Time to add it back Cole?
Yes it should be fine to push an update now
This is going to break my current remix process (see bug 1146232) but I'm not a big fan of GNOME Boxes when Virtual Machine Manager is available, so I can just delete GNOME Boxes during the ISO creation and give the user the option of putting it back. ;-)
(In reply to M. Edward (Ed) Borasky from comment #16) > This is going to break my current remix process (see bug 1146232) but I'm > not a big fan of GNOME Boxes when Virtual Machine Manager is available, so I > can just delete GNOME Boxes during the ISO creation and give the user the > option of putting it back. ;-) I hope the decision is not up to you? Virt-manager is targetted as a super user tool that is mostly just a nicer interface to edit libvirt's xml configuration while Boxes is designed for ordinary users who want simply run different operating systems in a safe/contained environment or connect to remove machines using a slick UI. All I see in bug#1146232 is you repeating your naive opinions w/o any arguments and now simply restating them, once again without any compelling argument. Please tell me that you have no power to make any such decisions?
(In reply to M. Edward (Ed) Borasky from comment #16) > This is going to break my current remix process (see bug 1146232) but I'm > not a big fan of GNOME Boxes when Virtual Machine Manager is available, so I > can just delete GNOME Boxes during the ISO creation and give the user the > option of putting it back. ;-) I was just informed that you have been talking about your own remixes rather than official Fedora ISOs. If that is the case, kindly keep your naive opinions to yourself in future and do as you please with your remixes.
gnome-boxes-3.14.2-3.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/gnome-boxes-3.14.2-3.fc21
Zeeshan: I really don't think that tone was necessary. It's perfectly legitimate to point out that the approach of changing the libvirt configuration when Fedora isn't building official images doesn't work well for people doing respins; we do have, for instance, the sort of quarter-official respins done by southern_gentleman / jbwilliams - http://jbwillia.wordpress.com/ - which live on a Fedora server, at https://alt.fedoraproject.org/pub/alt/live-respins/ .
(In reply to Adam Williamson (Red Hat) from comment #20) > Zeeshan: I really don't think that tone was necessary. It's perfectly > legitimate to point out that the approach of changing the libvirt > configuration when Fedora isn't building official images doesn't work well > for people doing respins; Sure but thats not what this dude did. He simply expressed his lack of knowledge and pressented a conclusion based on that. Moreover, I see no connection of his comments (which are essentially the same) to either of the bugs he posted them on. > we do have, for instance, the sort of > quarter-official respins done by southern_gentleman / jbwilliams - > http://jbwillia.wordpress.com/ - which live on a Fedora server, at > https://alt.fedoraproject.org/pub/alt/live-respins/ . Thanks for the info. As long as some random person is not allowed to remove my software from main/official ISOs of Fedora without any compelling reasons, I really don't care of what people do with re-spins etc. Now lets stop this irrelevant discussion here.
er, it seemed pretty clear to me that he was talking about deleting Boxes during "during the ISO creation" of "[his] current remix process", nothing to do with 'deleting' it from Fedora (which isn't a thing you can do anyway).
gnome-boxes-3.14.3.1-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/gnome-boxes-3.14.3.1-1.fc21
gnome-boxes-3.14.3.1-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
Reopening, since this is hitting us again with F22 live media. Laine is going to look at extending libvirt with his suggestion at https://bugzilla.redhat.com/show_bug.cgi?id=1146232#c17 But until that's done we should probably re-drop the network dep so beta media doesn't suffer from the 'no network access' problem
Proposed as a Blocker for 22-beta by Fedora user crobinso using the blocker tracking app because: With this dep in place, the live media running in a VM can have broken network access. It may only affect live media in a VM running on a host that was _also_ installed via live media, but regardless the failure scenario sucks here so we should avoid it for beta.
Adjusting whiteboard for F22 blocker proposal.
Discussed at 2015-04-06 blocker review meeting: https://meetbot.fedoraproject.org/fedora-blocker-review/2015-04-06/f22-blocker-review.2015-04-06-16.00.log.txt . Accepted as a blocker as in F21 cycle, until someone comes up with a better approach for this, we'll have to keep doing the same dodge. Boxes folks, please do a build with the dep dropped for now...
gnome-boxes-3.16.0-2.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/gnome-boxes-3.16.0-2.fc22
Package gnome-boxes-3.16.0-2.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing gnome-boxes-3.16.0-2.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-5751/gnome-boxes-3.16.0-2.fc22 then log in and leave karma (feedback).
This looks right in RC1, the package is not on the Workstation live.
also with RC2.
gnome-boxes-3.16.0-2.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
Can we bring the dependency back now? Do we have to go through this each release?
gnome-boxes-3.16.2-3.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/gnome-boxes-3.16.2-3.fc22
(In reply to Zeeshan Ali from comment #34) > Can we bring the dependency back now? Do we have to go through this each > release? The bug report in comment #0 has all the details about the current state of this... it still isn't fully fixed at the libvirt level so as of now this will break again come f23. ideas and patches welcome
(In reply to Cole Robinson from comment #36) > (In reply to Zeeshan Ali from comment #34) > > Can we bring the dependency back now? Do we have to go through this each > > release? > > The bug report in comment #0 has all the details about the current state of > this... it still isn't fully fixed at the libvirt level so as of now this > will break again come f23. ideas and patches welcome Ideas I've got plenty of - patches not so much. ;-) The intended use case for the Workstation Live media is a. Try out Fedora Workstation on real hardware, and b. Install Fedora Workstation to said hardware if you like it and want to use it. It is *not* a specialty spin or a rescue CD or something you'd use as part of your day-to-day workflow in most cases. Even with a USB 3.0 device it's frustratingly slow on significant operations. And it is not intended as a way to build a Fedora virtual machine running in any virtual host. LiveMedia Creator and a kickstart file does that very well. ;-) IIRC I was the one that first ran into this and filed the original bug during F21 alpha or beta. I don't recall exactly why I was running an alpha or beta live ISO in a virtual machine but it's not something I'd do in production. I use 'netinstall' on a USB stick for rescue and to do installs; getting the updated RPMs more than compensates for the longer install from the downloads. So my idea is simply to create Workstation media with the disclaimer that you may not have networking in a VM, or add a desktop icon that enables networking. See https://bugzilla.redhat.com/show_bug.cgi?id=1146232#c5 for the command-line operation to get networking up (at least it worked on F21).
gnome-boxes-3.16.2-3.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
Reopening, this is a problem with F24 again. See the continuing discussion in libvirt bug 1146232 Maybe there's some more stable workaround we can make with livecd kickstart/livesys startup scripts or whatnot, but I don't really have the time to investigate that in the near future. The simplest fix again seems to be to revert the boxes dep until after GA, and kick the can down the road some more until libvirt grows some magic config option to avoid this situation
This was accepted before, I guess we should propose either this or bug 1146232 as F24 blocker.
Discussed during the 2016-05-09 blocker review meeting: [1] Originally accepted as a blocker in F21 release, until this is resolved (or a solution is developed), this will remain a blocker. Suggestion is to create a build with the dependency removed. [1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2016-05-09/f24-blocker-review.2016-05-09-16.00.txt
We need to stop doing this. I understand this is needed to get F24 out the door, but I ask that bug #1146232 be prioritized for F25. It looks like some action is occurring there, which is great.
(In reply to Michael Catanzaro from comment #42) > We need to stop doing this. I understand this is needed to get F24 out the > door, but I ask that bug #1146232 be prioritized for F25. It looks like some > action is occurring there, which is great. Then someone needs to volunteer to champion it and propose patches. Just speaking for myself, I'm not all that excited about adding potentially invasive code in libvirt, that may be triggered by all usage of the default network, all to accomodate the specific case of - how fedora composes its livecd - the fact that gnome-boxes is on the livecd by default - the fact that gnome-boxes Requires: libvirt-daemon-config-network even though the functionality isn't strictly required But maybe there's another simple solution we can come up with on the distribution side. Ideas welcome
bug 1146232#c50 seems non-invasive, simple, designed for this use case, is tested, and if it somehow failed to fix the problem or inhibits libvirtd to start it'd be a considerable systemd bug. Is there a use case for libvirtd to ever run in a VM?
(In reply to Chris Murphy from comment #44) > Is there a use case for libvirtd to ever run in a VM? Yes, for developing virt related packages (for example, openstack) it's quite common. Same with QA testing say Fedora releases in a VM, you want to be able to test the virt stack is working.
sure, but I'd say the cases for running libvirtd in a *live session* in a VM are rather smaller, and for the few cases where you'd want to do that you still can by overriding the unit file or just starting it directly.
(In reply to Adam Williamson from comment #46) > sure, but I'd say the cases for running libvirtd in a *live session* in a VM > are rather smaller, and for the few cases where you'd want to do that you > still can by overriding the unit file or just starting it directly. agreed, but following that logic I'd rather remove gnome-boxes from the livecd than try to convince libvirt to not run in the live environment. or rework gnome-boxes deps to do what virt-manager has always done and not have a hard requirement on libvirt-daemon-config-network (or even libvirt-daemon... isn't gnome boxes also supposed to be the official VNC/SPICE client? it doesn't strictly need virt either AFAIK)
"agreed, but following that logic I'd rather remove gnome-boxes from the livecd than try to convince libvirt to not run in the live environment" I don't think that would fly. Boxes is explicitly part of Workstation. If we remove it from the live, that also means that when you install from the live, you don't get it - and installing from the live is the primary deployment method for Workstation. Fiddling with boxes' deps is more likely to fly.
(In reply to Adam Williamson from comment #48) > I don't think that would fly. Yup. It's indeed for remote desktop access as well as virtualization, and it's a core component of GNOME and Workstation. > Fiddling with boxes' deps is more likely to fly. If need be, a F25-timeframe compromise would be for Boxes to install its dependencies via PackageKit when they're not available. But bug 1146232#c50 seems like a better solution TBH. Overriding a unit file is the sort of thing we can expect users who want to run VMs inside VMs to know how to do.
gnome-boxes-3.20.2-2.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-dfe706e35e
gnome-boxes-3.20.2-2.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-dfe706e35e
gnome-boxes-3.20.2-2.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.
I tested this with Fedora-Workstation-Live-x86_64-24-20160529.n.0.iso containing gnome-boxes-3.20.2-2.fc24. I installed a default install to a bare metal machine, then ran the same image as a VM guest in gnome-boxes and virt-manager. Network access worked out of the box in guest VM. So tldr works OK.
Re-opening for F27, and re-proposing as a blocker; we still didn't come up with a permanent fix for 1146232, so we're going to need this workaround again.
Discussed during blocker review [1]: #1146232 - RejectedBlocker (Final), #1164492 - AcceptedBlocker (Final) - we think the problem here constitutes a blocker, but as with previous releases, we will make #1164492 the blocker as we may fix it with a short-term workaround rather than a real fix (again) [1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2017-09-11/
Change hasn't been made yet. FWIW I'm happy to handle this dep hacking for all fedora dev releases until we come up with a libvirt feature that handles this convoluted case. If someone from gnome-boxes/desktop side just wants to give me the go ahead. Will probably save everyone a lot of cycles... (Easiest way I think is to keep the network dep disabled in rawhide, and only enable it in a zero day update once GA is out)
gnome-boxes-3.26.1-4.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-fc8a65f619
gnome-boxes-3.26.1-4.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-fc8a65f619
Confirmed that spin-kickstarts-0.27.1-1.fc27 is in the RC-1.2 compose, does not have the dependency, and indeed libvirt-daemon-config-network is not included in the Workstation live image.
of course I meant gnome-boxes-3.26.1-4.fc27 , sigh.
gnome-boxes-3.26.1-4.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.
Update was pushed stable, closing for F27 (we can re-open and do this dance again for F28 if we don't figure out a better fix in the meantime).
Welp, time to dance again.
Also proposing as Beta FE, we have a few days to get this into Beta too if we want.
(In reply to Michael Catanzaro from comment #42) > We need to stop doing this. I understand this is needed to get F24 out the > door, but I ask that bug #1146232 be prioritized for F25. It looks like some > action is occurring there, which is great. That was two years ago... something has to change here. We can't keep doing this.
Well, the problem is that no-one can actually figure out what the 'real' fix for this ought to be. It's a very difficult problem to solve, really.
Latest idea: Maybe weak deps can help. Have gnome-boxes add Recommends: libvirt-daemon-config-network. As part of the workstation kickstart, remove the package, and manually delete /etc/libvirt/network/default.xml and /etc/libvirt/network/autostart/default.xml That way the conflicting network doesn't end up on the livecd, but after VM install and the first 'yum update' the Recommends: will be pulled in, the install logic in libvirt-daemon-config-network can check against the runtime VM network and install with a non-conflicting IP address range
Discussed during the 2018-03-26 blocker review meeting: [1] The decision to classify this bug as an AcceptedFreezeException was made as we want to avoid networking on Workstation live boots being broken by this, and we still haven't figured out a permanent fix. [1] https://meetbot.fedoraproject.org/fedora-blocker-review/2018-03-26/f28-blocker-review.2018-03-26-16.01.txt
Discussed during the 2018-03-26 blocker review meeting: [1] The decision to classify this bug as an AcceptedBlocker was made as it violates all blocker criteria related to networking, in the case of libvirt guests booting/installing from the Workstation live image. [1] https://meetbot.fedoraproject.org/fedora-blocker-review/2018-03-26/f28-blocker-review.2018-03-26-16.01.txt
gnome-boxes-3.27.92-2.fc28.1 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-45c3d50109
(In reply to Cole Robinson from comment #56) > FWIW I'm happy to handle this dep hacking for all fedora dev releases until > we come up with a libvirt feature that handles this convoluted case. If > someone from gnome-boxes/desktop side just wants to give me the go ahead. > Will probably save everyone a lot of cycles... > > (Easiest way I think is to keep the network dep disabled in rawhide, and > only enable it in a zero day update once GA is out) Since this never received a yes or no, I'm going ahead with this plan to save everyone the recurring hassle until we find a long term solution. Here's the comment I will be adding to rawhide and f28 gnome-boxes: # Pulls in the libvirtd NAT 'default' network # Original request: https://bugzilla.redhat.com/show_bug.cgi?id=1081762 # # However, the 'default' network does not mix well with the Fedora livecd # when it is run inside a VM. The whole saga is documented here: # # boxes: https://bugzilla.redhat.com/show_bug.cgi?id=1164492 # libvirt: https://bugzilla.redhat.com/show_bug.cgi?id=1146232 # # Until a workable solution has been determined and implemented, this # dependency should stay disabled in rawhide and fedora development # branches so it does not end up on the livecd. Once a Fedora GA is # released, a gnome-boxes update can be pushed with this dependency # re-enabled. crobinso will handle this process, see: # <link to this bz comment> #Requires:>.libvirt-daemon-config-network When F28 and all future Fedora are frozen for GA, I will queue an update to re-enable the dep
I already did the change for F28 (see above), but I'm certainly fine with you taking it on for the future, Cole! Note I did the build with the bump after the dist ('.fc28.1') to ensure it's behind Rawhide's build (and so that we don't wind up with two different -3s, one in F28 with the dependency off, one in Rawhide with it on).
gnome-boxes-3.27.92-2.fc28.1 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-45c3d50109
gnome-boxes-3.27.92-2.fc28.1 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.