I couldn't find anything in the documentation so asking here, is there a way to setup bridge networking for a set of VMs to get them public IPs? Thanks, Eric
On 8 March 2016 at 15:13, Eric Helms <ehelms@redhat.com> wrote:
I couldn't find anything in the documentation so asking here, is there a way to setup bridge networking for a set of VMs to get them public IPs?
You can setup an unmanaged network, and then use brctl after 'lago init' to attach a public interface to the bridge it creates. But if you need that you are not using Lago the way it was meant to be used, network isolation was baked in on purpose. Why do you need this? -- Barak Korren bkorren@redhat.com RHEV-CI Team
I am thinking about how to make this more useful to the masses on the team. The question I am asking myself is "can it replace vagrant for some scenarios". For example, being able to spin up a Satellite + Capsule(s) with DHCP, DNS etc. but allow outside access to the server via a web browser. Since often the setup requires a beefy box that is running on a beaker machine or server under a desk and developers use their laptops to access. Eric On Tue, Mar 8, 2016 at 9:42 AM, Barak Korren <bkorren@redhat.com> wrote:
On 8 March 2016 at 18:25, Eric Helms <ehelms@redhat.com> wrote:
Faced with the same dilemma when running oVirt on Lago on my MiniDell, I've simply setup Apache on it to proxy HTTP traffic into the VM network. With a browser proxy plugin such as foxy proxy configured to make the browser also resolve DNS for domains with certain suffixes over the proxy, I've got a pretty seamless user experience without giving up on the environment isolation. If you want this to be self-contained in a script you give developers, you can perhaps use the Ruby or Python built-in HTTP servers to do the proxying. -- Barak Korren bkorren@redhat.com RHEV-CI Team
On 03/08 18:53, Barak Korren wrote:
I think that a better solution might be exposing ports or similar, though I agree that having the possibility to setup external nets is a nice to have. btw. you can use ssh's -D option to setup a socks proxy server too, simpler imo.
-- David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Tel.: +420 532 294 605 Email: dcaro@redhat.com IRC: dcaro|dcaroest@{freenode|oftc|redhat} Web: www.redhat.com RHT Global #: 82-62605
On Tue, Mar 8, 2016 at 11:57 AM, David Caro <dcaro@redhat.com> wrote:
Can you help me visualize what this would look like from a code or user perspective? Right now I have it reduced to "run this script" and environment gets setup and installation steps occur. Ideally, that same script would setup or configure whatever is needed so a developer just hits the IP in their browser and is off and running. Eric
On 03/08 12:05, Eric Helms wrote:
For the ports, just adding an option to the nets specifying with ports to forward to which ips/vms For the ssh tunnel, you have to start it from your laptop to the machine that is running lago, something like: ssh -D 8888 -Nf lago_machine # the -N is for not running any command, -f is to go to background That will start a socks proxy at 127.0.0.1:8888 (in your laptop) that you can setup in your browser as proxy, and will forward any traffic through it, so pointing your browser to the internal vm ip/name should work.
-- David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Tel.: +420 532 294 605 Email: dcaro@redhat.com IRC: dcaro|dcaroest@{freenode|oftc|redhat} Web: www.redhat.com RHT Global #: 82-62605
If you bridge the VMs directly to the external network, you would need to to apply external network IP configuration for the VMs, which may or may not be simple depending on how the external network is configured. (If this is what vagrant does, then the fact that it worked for many developers so far is just sheer luck) Any names or IPs the external network would assign to the VMs can be completely random, the external DHCP may also just refuse to assign anything, the developer may even run his setup on a network without DHCP, that would force him to somehow manually assign an external IP to the VM running Satellite. Since Satellite is running on a VM it knows nothing about the hostname and IP of the underlying host, if we want the developer to eventually enter the host address in his browser, we could perhaps, use NAT or HTTP reverse proxy to expose ports from the VM on the host, but fully-qualified URLs in links or redirects sent from the app will not function properly since they will point to the VM hostname which is unknown on the external network. You can vision the situation like this - the dev laptop is attached to the "internet" while the Lago network is a closed separate network sitting behind a firewall. Host names and addresses on the Lago network are not and cannot be exposed to "the internet". To allow the dev laptop to work against the VMs you need something that essentially behaves like a VPN, so its hard to avoid any setup on the dev laptop.
This solution may work but I think there will be an issue with name resolution because the SSHD running on the host AFAIK does not know to resolve names against the Lago internal DNS. Also I'm not sure browsers know how to resolve hostnames via socks proxies in the same manner they know to resolve via HTTP froward proxies. I now remembr that the way it worked for me was that I had configure MDNS on all the VMs and the host so that multicast name resolution was working through the Lago bridges, this solution is not applicable to the general case. What we need is a proxy process, running on the host, that is attached to the external network on one end and to the Lago internal one on the other, and is configured to resolve names against the internal Lago DNS. There are a few challenges here especially if you don't want to modify the outside-visible configuration of the host (for example '/ets/resolv.conf' on the host may be DHCP-managed so you cannot change it). With some scripting, the end-user experience could come down to: 1. Run our script on the beefy host 2. Go to we page on the beefy host that would setup the VPM/proxy seeting for you. I think there may be an interesting Lago feature we could have here - Have a 'lago proxy' or 'lago vpn' command to expose a Lago network via a proxy or a vpn. -- Barak Korren bkorren@redhat.com RHEV-CI Team
participants (3)
-
Barak Korren -
David Caro -
Eric Helms