GNOME Bugzilla – Bug 747444
Add "network configuration"
Last modified: 2018-01-11 10:15:29 UTC
Bug 730789 is about disabling network in VMs. We should also have the ability to make the VM reachable to and from the host, to other machines on the host's network, and, possibly, amongst VMs on the same machine.
(In reply to Bastien Nocera from comment #0) > Bug 730789 is about disabling network in VMs. We should also have the > ability to make the VM reachable to and from the host, That is already in place. If its not working for you, its likely some bug. > to other machines on > the host's network, Well, we can probably setup our own bridge network in Boxes for making that possible but we probably won't be able to avoid the annoying polkit dialog. > and, possibly, amongst VMs on the same machine. That is also already in place.
(In reply to Zeeshan Ali (Khattak) from comment #1) > (In reply to Bastien Nocera from comment #0) > > > > to other machines on > > the host's network, > > Well, we can probably setup our own bridge network in Boxes for making that > possible but we probably won't be able to avoid the annoying polkit dialog. And I'd really hate to launch polkit dialogs so I must ask for compelling rationale for this: Is this (to connect from VM to another host) a common enough need? Is this going to be mostly/only needed by uber-geeks? If so, surely they should be able to setup some iptables rules to make this work?
(In reply to Zeeshan Ali (Khattak) from comment #2) > (In reply to Zeeshan Ali (Khattak) from comment #1) > > (In reply to Bastien Nocera from comment #0) > > > > > > to other machines on > > > the host's network, > > > > Well, we can probably setup our own bridge network in Boxes for making that > > possible but we probably won't be able to avoid the annoying polkit dialog. > > And I'd really hate to launch polkit dialogs so I must ask for compelling > rationale for this: Is this (to connect from VM to another host) a common > enough need? Is this going to be mostly/only needed by uber-geeks? If so, > surely they should be able to setup some iptables rules to make this work? No, this is not just for uber-geeks. I regularly face the problem "now how do I ssh into this vm again ?". And I can't figure it out. Please, don't dismiss this. The right fix for 'annoying polkit dialogs' is to adapt the policy to our needs.
(In reply to Matthias Clasen from comment #3) > (In reply to Zeeshan Ali (Khattak) from comment #2) > > (In reply to Zeeshan Ali (Khattak) from comment #1) > > > (In reply to Bastien Nocera from comment #0) > > > > > > > > to other machines on > > > > the host's network, > > > > > > Well, we can probably setup our own bridge network in Boxes for making that > > > possible but we probably won't be able to avoid the annoying polkit dialog. > > > > And I'd really hate to launch polkit dialogs so I must ask for compelling > > rationale for this: Is this (to connect from VM to another host) a common > > enough need? Is this going to be mostly/only needed by uber-geeks? If so, > > surely they should be able to setup some iptables rules to make this work? > > No, this is not just for uber-geeks. I regularly face the problem "now how > do I ssh into this vm again ?". From the host, right? Or do you regularly want to ssh into a VM from another host?
(In reply to Zeeshan Ali (Khattak) from comment #4) > (In reply to Matthias Clasen from comment #3) > > (In reply to Zeeshan Ali (Khattak) from comment #2) > > > (In reply to Zeeshan Ali (Khattak) from comment #1) > > > > (In reply to Bastien Nocera from comment #0) > > > > > > > > > > to other machines on > > > > > the host's network, > > > > > > > > Well, we can probably setup our own bridge network in Boxes for making that > > > > possible but we probably won't be able to avoid the annoying polkit dialog. > > > > > > And I'd really hate to launch polkit dialogs so I must ask for compelling > > > rationale for this: Is this (to connect from VM to another host) a common > > > enough need? Is this going to be mostly/only needed by uber-geeks? If so, > > > surely they should be able to setup some iptables rules to make this work? > > > > No, this is not just for uber-geeks. I regularly face the problem "now how > > do I ssh into this vm again ?". > > From the host, right? Or do you regularly want to ssh into a VM from another > host? I'd guess it's the former and for that we'll at least add support for showing the IP of the guest (bug#744004) that should make things much easier already. We might also think about adding an ssh shell right in the Boxes or add a button to launch one but we'll see about that..
Right, the ip address in the properties is nice. I would still like to have a "SSH login" menuitem somewhere, Probably in the context menu in the overview. The ip address is a bit too deeply hidden in the properties.
Removing from target list
(In reply to Matthias Clasen from comment #6) > Right, the ip address in the properties is nice. I would still like to have > a "SSH login" menuitem somewhere, Probably in the context menu in the > overview. The ip address is a bit too deeply hidden in the properties. I guess but we'll need to ensure that there is an SSH server running in the guest (should be easy to check if we assume port 20).
(In reply to Zeeshan Ali (Khattak) from comment #8) > (In reply to Matthias Clasen from comment #6) > > Right, the ip address in the properties is nice. I would still like to have > > a "SSH login" menuitem somewhere, Probably in the context menu in the > > overview. The ip address is a bit too deeply hidden in the properties. > > I guess but we'll need to ensure that there is an SSH server running in the > guest (should be easy to check if we assume port 20). SSH is port 22, 20 is FTP.
(In reply to Matthias Clasen from comment #3) > (In reply to Zeeshan Ali (Khattak) from comment #2) > > And I'd really hate to launch polkit dialogs so I must ask for compelling > > rationale for this: Is this (to connect from VM to another host) a common > > enough need? Is this going to be mostly/only needed by uber-geeks? If so, > > surely they should be able to setup some iptables rules to make this work? One case I found this useful is when running a WordPress instance on a local VM and develop a responsive site. In order to test it on an actual cellphone I need to reach it over the network somehow.
(In reply to Andreas Nilsson from comment #10) > (In reply to Matthias Clasen from comment #3) > > (In reply to Zeeshan Ali (Khattak) from comment #2) > > > > And I'd really hate to launch polkit dialogs so I must ask for compelling > > > rationale for this: Is this (to connect from VM to another host) a common > > > enough need? Is this going to be mostly/only needed by uber-geeks? If so, > > > surely they should be able to setup some iptables rules to make this work? > > One case I found this useful is when running a WordPress instance on a local > VM and develop a responsive site. In order to test it on an actual cellphone > I need to reach it over the network somehow. Thanks Andreas. I'm sure there are cases where this will be useful. I just want to know if they are common enough to care in Boxes itself. Also if it's needed by non-geeks who wouldn't know anything of how to setup iptables rules.
Adding some example use cases: (In reply to Bastien Nocera from comment #0) <snip> > We should also have the > ability to make the VM reachable to and from the host This would be used to, for example, pull screenshots, test results and logs from the VM, or copy configuration files, or compiled sources from the host to the VM. >, to other machines on > the host's network, Making those available on the local network would allow testing a network service from other machines, such as a Windows laptop, or mobile phones. > and, possibly, amongst VMs on the same machine. This could be used to allow the server or client to run on a separate VM, under a separate version of the OS, for example, running a server on CentOS but the client on Fedora. The first use case is very common, and as you mentioned, should already be implemented, the latter is common enough that it is mentioned in the Fedora documentation: https://docs.fedoraproject.org/en-US/Fedora/13/html/Virtualization_Guide/sect-Virtualization-Network_Configuration-Bridged_networking_with_libvirt.html
Here is some previous art from VMWare Workstation https://www.vmware.com/support/ws4/doc/network_configure_ws.html
(In reply to Bastien Nocera from comment #12) > Adding some example use cases: > > (In reply to Bastien Nocera from comment #0) > <snip> > > We should also have the > > ability to make the VM reachable to and from the host > > This would be used to, for example, pull screenshots, test results and logs > from the VM, or copy configuration files, or compiled sources from the host > to the VM. As I explained in comment#1, this is already in place so you're wasting your time/energy in explaining the usecase. :) > >, to other machines on > > the host's network, > > Making those available on the local network would allow testing a network > service from other machines, such as a Windows laptop, or mobile phones. > > > and, possibly, amongst VMs on the same machine. > > This could be used to allow the server or client to run on a separate VM, > under a separate version of the OS, for example, running a server on CentOS > but the client on Fedora. This one too. > The first use case is very common, and as you mentioned, should already be > implemented, Not "should", but is already in place for years now. > the latter is common enough that it is mentioned in the Fedora > documentation: > https://docs.fedoraproject.org/en-US/Fedora/13/html/Virtualization_Guide/ > sect-Virtualization-Network_Configuration-Bridged_networking_with_libvirt. > html Did you notice the steps? Do you want Boxes to be stopping NetworkManager on you or fiddling with firewalls? This is clearly not Boxes domain.
(In reply to Zeeshan Ali (Khattak) from comment #14) > (In reply to Bastien Nocera from comment #12) > > Adding some example use cases: > > > > (In reply to Bastien Nocera from comment #0) > > <snip> > > > We should also have the > > > ability to make the VM reachable to and from the host > > > > This would be used to, for example, pull screenshots, test results and logs > > from the VM, or copy configuration files, or compiled sources from the host > > to the VM. > > As I explained in comment#1, this is already in place so you're wasting your > time/energy in explaining the usecase. :) There's no configuration for this, eg. something showing the VM's IP address in the properties, no way to switch between that mode and another one. See Matthias' comment 3. > > >, to other machines on > > > the host's network, > > > > Making those available on the local network would allow testing a network > > service from other machines, such as a Windows laptop, or mobile phones. > > > > > and, possibly, amongst VMs on the same machine. > > > > This could be used to allow the server or client to run on a separate VM, > > under a separate version of the OS, for example, running a server on CentOS > > but the client on Fedora. > > This one too. I'm guessing it's enabled by default as well, because there's no configuration for it. > > The first use case is very common, and as you mentioned, should already be > > implemented, > > Not "should", but is already in place for years now. > > > the latter is common enough that it is mentioned in the Fedora > > documentation: > > https://docs.fedoraproject.org/en-US/Fedora/13/html/Virtualization_Guide/ > > sect-Virtualization-Network_Configuration-Bridged_networking_with_libvirt. > > html > > Did you notice the steps? Andreas wasn't showing the steps, he was showing the 4 toggle buttons for switching between the different modes of operation for the network. > Do you want Boxes to be stopping NetworkManager on > you or fiddling with firewalls? This is clearly not Boxes domain. Maybe it shouldn't poke at the firewall or whatever directly, but rely on something else to do it on its behalf. That point is moot though, if something needs to be implemented in the lower levels, then so be it, it wouldn't change the fact that the feature is necessary at the top-level, and what the UI would be once implemented.
(In reply to Bastien Nocera from comment #15) > (In reply to Zeeshan Ali (Khattak) from comment #14) > > (In reply to Bastien Nocera from comment #12) > > > Adding some example use cases: > > > > > > (In reply to Bastien Nocera from comment #0) > > > <snip> > > > > We should also have the > > > > ability to make the VM reachable to and from the host > > > > > > This would be used to, for example, pull screenshots, test results and logs > > > from the VM, or copy configuration files, or compiled sources from the host > > > to the VM. > > > > As I explained in comment#1, this is already in place so you're wasting your > > time/energy in explaining the usecase. :) > > There's no configuration for this, eg. something showing the VM's IP address > in the properties, There is. We show VM's IP in properties. Unforunately it's not very reliable though and I've been thinking about ways to improve that but that's another bug. > no way to switch between that mode and another one. See > Matthias' comment 3. That comment does not say anything about any other modes AFAICT. > > > >, to other machines on > > > > the host's network, > > > > > > Making those available on the local network would allow testing a network > > > service from other machines, such as a Windows laptop, or mobile phones. > > > > > > > and, possibly, amongst VMs on the same machine. > > > > > > This could be used to allow the server or client to run on a separate VM, > > > under a separate version of the OS, for example, running a server on CentOS > > > but the client on Fedora. > > > > This one too. > > I'm guessing it's enabled by default as well, because there's no > configuration for it. Why do you need configuration for accessing a VM from another? > > > The first use case is very common, and as you mentioned, should already be > > > implemented, > > > > Not "should", but is already in place for years now. > > > > > the latter is common enough that it is mentioned in the Fedora > > > documentation: > > > https://docs.fedoraproject.org/en-US/Fedora/13/html/Virtualization_Guide/ > > > sect-Virtualization-Network_Configuration-Bridged_networking_with_libvirt. > > > html > > > > Did you notice the steps? > > Andreas wasn't showing the steps, That link was provided by you, not him. :) > > Do you want Boxes to be stopping NetworkManager on > > you or fiddling with firewalls? This is clearly not Boxes domain. > > Maybe it shouldn't poke at the firewall or whatever directly, but rely on > something else to do it on its behalf. That point is moot though, if > something needs to be implemented in the lower levels, then so be it, it > wouldn't change the fact that the feature is necessary at the top-level, and > what the UI would be once implemented. Daniel pointed out that we might be able to use the new NetworkManager API to create a bridge for a specific VM. I can look into that at some point..
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-boxes/issues/47.