open VZ container has trouble reaching the internet

phobiemos

New Member
Feb 13, 2011
3
0
1
Hello everyone,

I installed proxmox VE and created an openVZ container and installed ubuntu 8.04 standard. Everything appeared to have gone fine.

I setup a bridged ethernet connection
eth0 vmbr0

I opened the VNC console for my virtual machine and tried go get some updates by running aptitude update. I received the message:


Err http://archive.ubuntu.com hardy release.gpg
Could not resolve 'archive.ubuntu.com'
Err http://archive.ubuntu.com hardy-updates release.gpg
Could not resolve 'archive.ubuntu.com'
Err http://archive.ubuntu.com hardy-security release.gpg
Could not resolve 'archive.ubuntu.com'

I suspected that I could not reach out to the internet so I tried to ping google and recieved this message:

connect: network is unreachable.

I'm looking for some help getting my machine to reach out to the internet.

thanks :)
 
You need to configure the /etc/network/interfaces file manually
sudo nano /etc/network/interfaces

if you want to get a dynamic IP from your DHCP server - the file should look like this:

Code:
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp
if you want a static IP (which is always better for a server) it should be like this:
Code:
auto lo
iface lo inet loopback

auto eth0
address 192.168.1.2
netmask 255.255.255.0
gateway 192.168.1.1
where the address/mask/gateway should be changed according to your network topology.

After saving the changes (Ctrl+X, Y, Enter) restart the network
/etc/init.d/networking restart

after that you should be able to ping your gateway. If google still doesn't ping - edit /etc/resolv.conf and add your DNS server (although I think you can set the DNS servers in proxmox during VM creation)
 
Thank you for you help but sadly it wasn't that simple,

after following your instructions when I reset the network I get the error message:

Code:
/etc/network/interfaces:12: misplaced option
ifdown: couldn't read interfaces file "/etc/network/interfaces"
/etc/network/interfaces:12: misplaced option
ifup: couldn't read interfaces file "/etc/network/interfaces"
Inside the /ect/network/interfaces file there is a comment block that reads:
Code:
# This configuration is auto-generated.
# WARNING: do not edit this file, your changes will be lost.
# Please create/edit /etc/network/interfaces.head and /etc/network/interfaces.tail instead
# their contents will be inserted at the beginning and at the end
# of this file respectively
The /etc/network/interfaces file contained this by default:
Code:
auto lo
iface lo inet loopback
So I created the file /etc/network/interfaces.tail
and added this to the file's contents:
Code:
auto eth0
address 192.168.1.2
netmask 255.255.255.0
gateway 192.168.1.1
I figured that this would get added to end of the /etc/network/interfaces file just like the comment block said and then it would look like your example.

when I reset the network I did not get the error message again. Good sign!
I then tried to ping 74.125.244.18 (google) and got the response:

Code:
connect: Network is unreachable
I then tried changing the /etc/network/interfaces.tail file's contents to:

Code:
auto lo
iface lo inet loopback
I thought, "Why not try the dynamic IP version. Maybe that will work."
To my dismay, after resetting the network I got the same response:

Code:
connect: Network is unreachable
any suggestions?
 
Last edited:
Ah I had this :)

If you run : /etc/init.d/networking restart

You will get an error about /var/run/network/ifstate being unavailable or something similar (from memory)

What is wrong is the /var/run/network directory is not being created on boot up for some reason so simply :
mkdir /var/run/network
and then just create an empty ifstate file
touch /var/run/network/ifstate
then restart networking
/etc/init.d/networking restart
and voila :)
 
Thank you for the suggestion Tig, but that is not the problem I am having.

my var/run/network/ifstate file exists

When I run /etc/init.d/networking restart
the network does restart properly. It gives me the [ok], and doesn't wine about any files being missing.

when I attempt to ping a website, say google, I get the response:
Code:
connect: Network is unreachable
Please read the first, second, and third posts carefully. I beleive my issue and the extent of my troubleshooting process is fairly well explained through out them
 
I would like to join as well. I am experiencing the exact same situation. In my case, I am using a node with multiple fail-over IP's. Right now, whenever I create a new OpenVZ or KVM, I am not able to make the VPS connect to internet. The main reason is the fact that I can not add a gateway to the configuration. However, I am having few VPS with Windows which are easy to configure. I have no problems there.

The strangest thing is the fact that I had Proxmox server installed by default on my server and it was old version (1,4). At the very first time, before updating the system, I were able easily to create OpenVZ or KVM container and it was working like a charm. I have this problem since I have upgraded to 1,7 version of Proxmox.

I am looking forward to find a way to fix this issue.
 
I would also like to chime in, with the slight variation that I'm experiencing the problem with CentOS in a KVM container. I just downloaded and installed Proxmox 1.7, then created a KVM VM and successfully installed a Centos distribution.

The Proxmox VE inserted itself into the local area network successfully. I was able to reach repositories, download the usual updates, and use it normally.

The KVM VM with CentOS can access the LAN gateway device at 192.168.1.1:

# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=150 time=2.23 ms
When I attempted to do the usual post-install updates inside the CentOS VM, I saw errors when the update application was trying to reach the repositories. It became clear that the CentOS VM could not contact addresses outside the LAN:

# ping 66.102.7.104
PING 66.102.7.104 (66.102.7.104) 56(84) bytes of data.
From 192.168.0.99 icmp_seq=2 Destination Host Unreachable
The target IP (66.102.7.104) is google.com, which was shown to be accessible at the same time from other machines on the LAN.

I'm continuing to investigate, but I hope an easy answer appears here by forum magic.

Notes
  • Proxmox version: 1.7 (installed from proxmox-ve_1.7-5323-5.iso)
  • CentOS version: Orange JeOS Core release 1.8.7-11
 
I would also like to chime in, with the slight variation that I'm experiencing the problem with CentOS in a KVM container. I just downloaded and installed Proxmox 1.7, then created a KVM VM and successfully installed a Centos distribution.

The Proxmox VE inserted itself into the local area network successfully. I was able to reach repositories, download the usual updates, and use it normally.

The KVM VM with CentOS can access the LAN gateway device at 192.168.1.1:
# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=150 time=2.23 ms
When I attempted to do the usual post-install updates inside the CentOS VM, I saw errors when the update application was trying to reach the repositories. It became clear that the CentOS VM could not contact addresses outside the LAN:
# ping 66.102.7.104
PING 66.102.7.104 (66.102.7.104) 56(84) bytes of data.
From 192.168.0.99 icmp_seq=2 Destination Host Unreachable
The target IP (66.102.7.104) is google.com, which was shown to be accessible at the same time from other machines on the LAN.

I'm continuing to investigate, but I hope an easy answer appears here by forum magic.

Notes
  • Proxmox version: 1.7 (installed from proxmox-ve_1.7-5323-5.iso)
  • CentOS version: Orange JeOS Core release 1.8.7-11
Hi,
i'm right that your VM which can ping inside the Lan and not outside is an kvm-vm? Only to be sure, because you append the posting on an openvz-network thread!

Your discription looks like "no gateway entry"
if you look with
Code:
ip route
you must have an entry like:
default via 192.168.1.1 dev eth0

Udo
 
Hi,
i'm right that your VM which can ping inside the Lan and not outside is an kvm-vm? Only to be sure, because you append the posting on an openvz-network thread!

Your discription looks like "no gateway entry"
if you look with
Code:
ip route
you must have an entry like:
default via 192.168.1.1 dev eth0

Udo

Thank you for your comment, Udo.

I'm sorry for being unclear, but I will confirm that the VM I wrote about previously, from which I can ping throughout the LAN, is indeed a KVM-VM. Its (perhaps questionable) appearance under the thread "open VZ container has trouble reaching the internet" reflects my concern that this may be an issue in the "1.7" release of Proxmox itself, not related to the nature of the VM (OpenVZ or KVM).

You have given a diagnostic technique (thank you!), which I applied:
Code:
[FONT=Courier New]# ip route[/FONT]
[FONT=Courier New]192.168.1.0/24 dev vmbr0  proto kernel  scope link  src 192.168.1.220[/FONT]
[FONT=Courier New]default via 192.168.1.1 dev vmbr0[/FONT]
There is a small difference from your desired results, which is the appearance of the device vmbr0, rather than eth0 as you suggested. Device vmbr0 is the name of the default Proxmox virtual network bridge. Is this a significant difference? If so, I wonder what may have caused it. And, of course, how it can be cured, if it is the source of our problem.

I should clarify my interest, which brought me to this forum. We are evaluating Proxmox as a possible tool for our application development team, because it makes many of the tasks of VM creation, operation, and maintenance faster and easier. In principle, junior infrastructure staff and platform-blind developers can use Proxmox successfully, fewer mistakes are possible when using the web-based interface, and so on. We had been considering building our own web-based front end to VM operation and Proxmox just seemed like a leap forward to save time and effort.

For Proxmox to be useful in this application, though, it has to do the simple tasks correctly (like being installed with all its defaults untouched, as in this case) without requiring diagnosis and repair by a senior resource. I believe Proxmox has done an excellent job meeting that standard in recent months.

Referring to your question, Udo, it might be a problem within Proxmox that has caused possible network misrouting, since we have not made any changes to our Proxmox installation except for the performing the recommended package update step right after installing the OS. We would expect that simple installation of a VM should work "out of the box", including VM access to the Internet as needed for post-creation package updates.

In regards to the "trouble reaching the Internet" problem we have been discussing, I hope that the current problem with accessing the routable Internet from a VM is simple to fix. I also hope that, if the problem arises from a flaw in the current release of Proxmox, that the Proxmox team makes a correction at the source so that it affects no one else. I am willing to try out any reasonable amount of diagnosis if it will help anyone here in identifying the problem and / or suggesting a solution.
 
Hi,
sorry - eth0 is may fault (i copied it from a non-pve machine). vmbr0 is right.
Your routing looks good - the kvm-vm use bridge-mode? Then you should see your pings (and if ok also the answers) with tcpdump on the host:
Code:
tcpdump -i eth0 host 192.168.1.1
(or use as hostaddress the ip of you VM). I guess the problem ist on your router?! Perhaps the router don't like multiple IPs from one mac-address?

Udo
 
Udo;

Thanks once more for your expertise and ideas.

1) I tried your "tcpdump" suggestion and can verify successful round-trip traffic from the Proxmox VE host to the gateway and back (some interline spacing added for clarity):
Code:
#  tcpdump -i eth0 -n host 192.168.1.1
 
tcpdump: WARNING: eth0: no IPv4 address assigned
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
 
11:47:15.282657 IP 192.168.1.230 > 192.168.1.1: ICMP echo request, id 63497, seq 1, length 6
11:47:15.282972 IP 192.168.1.1 > 192.168.1.230: ICMP echo reply, id 63497, seq 1, length 64
 
11:47:16.281649 IP 192.168.1.230 > 192.168.1.1: ICMP echo request, id 63497, seq 2, length 64
11:47:16.281960 IP 192.168.1.1 > 192.168.1.230: ICMP echo reply, id 63497, seq 2, length 64
2) Your second contribution is a hypothesis that our gateway or other elements of our network may be causing the problem.

That is always a possibility. In the original troubleshooting, we discounted it somewhat since so many other operating systems and hosts, items of network software, network security applications, and so on work properly "out of the box" on the network in its current configuration. Nothing in the network infrastructure has changed for at least 8 months, so there is no recent "network changed" event that would give us a handle on where to start looking.

But before we proceed further, we should test the hypothesis of LAN error, whether in configuration or in operation. I may benefit from some help in setting out additional tests, but here's a start:

Problem
CentOS client VM under Proxmox Virtual Environment 1.7 cannot reach the Internet with network traffic (see previous postings in this thread for additional details).

Hypotheses and Tests
Note: our general hypothesis is that the local area network (LAN) is causing the problem, based on your previous post.

H1 - The LAN gateway is preventing any traffic from reaching the Internet.

Test A - Test using "ping" command from local hosts to Internet hosts

- ping from non-Proxmox host to an Internet host by IP address - SUCCESS
- ping from non-Proxmox host to an Internet host by domain name - SUCCESS
- ping from Proxmox host to an Internet host by IP address - SUCCESS
- ping from Proxmox host to an Internet host by domain name - SUCCESS
- ping from CentOS guest (under Proxmox host) to an Internet host by IP address - FAIL (see previous post for details)



- ping from CentOS guest (under Proxmox host) to an Internet host by domain name - FAIL (see previous post for details)
  • H1 - not true (normally I would say "not supported", but this may be a little more clear): all hosts and devices except the CentOS guest are successfully pinging external Internet addresses
H2 - Our local changes to the CentOS VM network setup have made it unable to reach the Internet


Test A - Test by building a new Proxmox host and installing a fresh copy of the CentOS guest VM making NO changes to the default install. Then run the network tests that failed in H1 above.
- to be completed


H3 - The LAN configuration is incompatible with the networking created by a default Proxmox install of the CentOS KVM virtual guest.

Note: this is the hypothesis I believe you were suggesting in your most recent posting. It's a pretty large area to cover, but we can narrow it down knowing that almost everything works as expected, except for "ping" and other network requests from the CentOS guest OS.


H3.1 - The local sub-LAN or the LAN gateway does not support multiple IPs from one MAC address.

I would imagine that the Proxmox VE host always generates multiple IP addresses from a single hardware device. If that was the problem, there should be signs of it in all network traffic, whether external (Internet) or local.

Test A - Scan for network traffic from the CentOS VM - it should not be routed if it is incompatible with the LAN switches / hubs / gateway.

- passively scan at network switch for traffic involving CentOS guest (under Proxmox host) - SUCCEED
- ping from CentOS guest (under Proxmox host) to a local host by IP address - SUCCEED

H3.1 - not true: the CentOS guest is successfully pinging (local) LAN addresses


H3.2 - The local sub-LAN or the LAN gateway do not support Internet access for the 192.168.0.nnn address space.

This hypothesis appears because I notice that no internal traffic in our LAN uses the 192.168.0.nnn (255/255/255/0) space except the CentOS guest. (I am looking at our passive network security scanner alerts.) Why does the CentOS guest use that address space? I don't know - it was assigned automagically by Proxmox during installation of the CentOS virtual client.

Test A - Set the CentOS virtual client to use a subnetwork address space that is already working properly in this part of our LAN, then re-run the ping tests from above.

Test B - Set a known-good network host to operate using a 192.168.0.nnn address (different from the one assigned to the CentOS guest) and re-run the ping tests from above.
OK - that's as far as I have gotten today. I will work on H2 - Test A now: building a duplicate Proxmox server, then doing a duplicate CentOS guest installation. All steps will be recorded this time. If the resulting build has the same problem as the one we have been discussing, then I'd like to tackle H3.2 next.



I have a couple of quick questions:
  • What is the Proxmox-approved way to change the subnetwork space used by client VMs?
  • If these tests don't identify the problem, can you suggest other hypotheses to test?
 
...
Test B - Set a known-good network host to operate using a 192.168.0.nnn address (different from the one assigned to the CentOS guest) and re-run the ping tests from above.
...
Hi,
ahh - your CentOS use NAT... (not the same network like the host)
Whats about bridged network: use vmbr0 for the CentOS and select an address in this network-range (192.168.1.0/24 - e.g. 192.168.1.199 ). In this case your CentOS has the same connectivity like all other hosts and should be able to ping outside.

BTW. i missed a tcpdump from CentOS to outside in your last post. But try the bridge mode and all should run.

Udo
 
Udo;

First, a brief progress report on the test I set out to do from the last post.
H2 - Our local changes to the CentOS VM network setup have made it unable to reach the Internet


Test A - Test by building a new Proxmox host and installing a fresh copy of the CentOS guest VM making NO changes to the default install. Then run the network tests that failed in H1 above.

H2 - (probably) not true: The new server, new Proxmox VE (host), and new CentOS VM (guest) were configured as closely as possible to the existing one, but the network tests (see previous post) execute the same. The Centos guest VM can ping the gateway, but pinging a host outside the LAN results in "Destination Host Unreachable" messages as with the original server.
We captured our configuration of the Centos guest VM as it was keyed in and I will provide it here for reference:
CentOS VM Configuration

Type: Fully virtualized (KVM)
ISO Storage: local (dir)
Installation Media: OJ-1.8.7-11.iso
Disk Storage: local (dir)
Disk Space (GB): 10 GB
Name: Orange-JEOS-(CentOS)-1.8.7-11-v.10
Memory: 256 MB
VMID: 110 (111 for 2nd host)
Cluster Node: Server 1 - vrt1 (192.168.1.220), Server 2 - vrt2 (192.168.1.230)
Start at boot: false (not checked)
Image Format: raw
Disk type: IDE
Guest type: Linux 2.6
CPU Sockets: 1

Network

Bridge: vmbr0
Network Card: rtl8139 (default)
MAC Address: Server 1 - 42:B3:A4:2D:6D:6F, Server 2 - CA:4F:AD:92:30:87
As you can see, the default values are used wherever possible. We're just testing Proxmox right now and don't want to stray too far from the default setup until we have gotten it working properly.

Hi,
ahh - your CentOS use NAT... (not the same network like the host)
Whats about bridged network: use vmbr0 for the CentOS and select an address in this network-range (192.168.1.0/24 - e.g. 192.168.1.199 ). In this case your CentOS has the same connectivity like all other hosts and should be able to ping outside.

<snip>

Udo

Thank you for your comment, Udo. We did not request the "NAT" option in setting up the CentOS VM client, as the configuration notes above show. The default bridge device "vmbr0" is assigned to the CentOS VM client.

I would like to follow up on your suggestion to "use vmbr0 for the CentOS and select an address in this network-range (192.168.1.0/24 - e.g. 192.168.1.199 )". In essence, this action addresses Hypothesis H3.2 "The local sub-LAN or the LAN gateway do not support Internet access for the 192.168.0.nnn address space." from our previous post. I think your suggestion is "Test A".

I had asked in that post "What is the Proxmox-approved way to change the subnetwork space used by client VMs?" As you have pointed out, it would appear to require changing the configuration of the "vmbr0" bridge. I have not seen a Proxmox user interface component for this task, so would we be stepping outside Proxmox to make those changes? Your advice is very welcome.

<snip>
BTW. i missed a tcpdump from CentOS to outside in your last post. But try the bridge mode and all should run.

I would like to try the subnet addressing changes just discussed first, then if they are ineffective I will capture the tcpdump of pinging to the external Internet. If you can give us a hint or point us to a resource that will support modifying the default "vmbr0" configuration so that the guest VMs appear on a subnetwork of our choosing, I would be very grateful.
 
...
CentOS VM Configuration

Type: Fully virtualized (KVM)
ISO Storage: local (dir)
Installation Media: OJ-1.8.7-11.iso
Disk Storage: local (dir)
Disk Space (GB): 10 GB
Name: Orange-JEOS-(CentOS)-1.8.7-11-v.10
Memory: 256 MB
VMID: 110 (111 for 2nd host)
Cluster Node: Server 1 - vrt1 (192.168.1.220), Server 2 - vrt2 (192.168.1.230)
Start at boot: false (not checked)
Image Format: raw
Disk type: IDE
Guest type: Linux 2.6
CPU Sockets: 1

Network

Bridge: vmbr0
Network Card: rtl8139 (default)
MAC Address: Server 1 - 42:B3:A4:2D:6D:6F, Server 2 - CA:4F:AD:92:30:87

btw. this info can you give easier - simply paste the config file (/etc/qemu-server/VMID.conf)​
As you can see, the default values are used wherever possible. We're just testing Proxmox right now and don't want to stray too far from the default setup until we have gotten it working properly.



Thank you for your comment, Udo. We did not request the "NAT" option in setting up the CentOS VM client, as the configuration notes above show. The default bridge device "vmbr0" is assigned to the CentOS VM client.
It's good if you don't use NAT, but why you don't use the same network?? vmbr0 is an networkbridge, which means, that all devices (virtual and physically) on this brigde are connected together.
If you have an single box with the ip 192.168.0.100 and take the networkcable instead to the proxmoxserver to the single box your networkconnection will also don't work, because you are in the wrong network. With the VM on the proxmox-host is this the same!
Of course can you use with proxmox diffrent networks (vmbr0, vmbr1, vmbr20....) but you must have nics for that (or vlan-tagging) and the network infrastructure, like router.
I would like to follow up on your suggestion to "use vmbr0 for the CentOS and select an address in this network-range (192.168.1.0/24 - e.g. 192.168.1.199 )". In essence, this action addresses Hypothesis H3.2 "The local sub-LAN or the LAN gateway do not support Internet access for the 192.168.0.nnn address space." from our previous post. I think your suggestion is "Test A".
YES
I had asked in that post "What is the Proxmox-approved way to change the subnetwork space used by client VMs?" As you have pointed out, it would appear to require changing the configuration of the "vmbr0" bridge. I have not seen a Proxmox user interface component for this task, so would we be stepping outside Proxmox to make those changes? Your advice is very welcome.
What do you want to change? vmbr0, or the VM-internal IP?
Like wrote before - vmbr0 is simply a network-hub for all NICs on this network. The internal ip must be changed by you (who depends on the client os).


Udo
 
Mischief managed!

After looking at Udo's last response and trying to comprehend the difference between the KVM and the OpenVZ networking approaches, I looked beyond the Proxmox world for similar problems (specifically, the error message "Connect: network is unreachable" under CentOS / Red Hat distributions). I found the solution almost immediately on HowToForge (at http://www.howtoforge.com/forums/showthread.php?t=2098).

Here's a summary of the diagnosis and solution process:
1 - Change CentOS (KVM) VM client instance's IP address.

We had earlier discussed whether it should be moved within the 192.168.1.xxx (/24) address space from 192.168.0.xxx (/24) space where it defaulted initially. Now that I realized Proxmox was not involved setting the VM's IP address, I felt free to change it by moving it to IP 192.168.1.231. From the CentOS VM's terminal session:

Code:
# ifconfig eth0 192.168.1.231 netmask 255.255.255.0 up

Some related diagnostic commands:

Show the current IP address for eth0 (the CentOS virtual VM's default Ethernet device):
Code:
# ifconfig eth0

Ping the local gateway device again to confirm local connectivity:
Code:
# ping 192.168.1.1

Ping the Internet (e.g., google.com) to confirm external connectivity:
Code:
# ping 66.102.7.104
[B]Connect: network is unreachable[/B]

This is the network error message we did not want to see again.


2 - Check CentOS VM's routing to the gateway.

Show the CentOS VM client's routing tables:

Code:
# netstat -nr 
[B]Dest | Gateway | Genmask | Flags | MSS | Window | irtt | Iface[/B]
[B]192.168.1.0 | 0.0.0.0 | 255.255.255.0 | U | 0 | 0 | 0 | eth0 [/B]

Diagnosis (from the HowToForge post): no route to the gateway.


3 - Add a route to the gateway.

First of all, check the "no route to the gateway" hypothesis by quickly adding a route:

Code:
# /sbin/route add -net 0.0.0.0 gw 192.168.1.1

Aha - now pinging the external Internet works! Check the routing tables again:

Code:
# netstat -nr 
[B]Dest | Gateway | Genmask | Flags | MSS | Window | irtt | Iface[/B]
[B]192.168.1.0 | 0.0.0.0 | 255.255.255.0 | U | 0 | 0 | 0 | eth0[/B]
[B]0.0.0.0 | 192.168.1.0 | 0.0.0.0 | UG | 0 | 0 | 0 | eth0 [/B]


4 - Make network changes permanent.

The additional route needs to appear automagically on boot-up of the virtual guest. I assume this will be easy to set up, but I haven't had time to analyze or confirm it yet.
Udo, thank you for your patience and your valuable input.
 
Udo;

I'm sorry I did not see your reply before I posted my (hopefully final) solution for the problem we have been discussing.

btw. this info can you give easier - simply paste the config file (/etc/qemu-server/VMID.conf)
I wish I had known that! No harm done as I keep configuration records and notes manually anyway in documents used for debugging / training / reminding the team regarding these complex configurations and tools.

It's good if you don't use NAT, but why you don't use the same network?? vmbr0 is an networkbridge, which means, that all devices (virtual and physically) on this brigde are connected together.
The answer as usual is "ignorance". Proxmox is new to me, the mix of Proxmox advice often conceals whether it applies to OpenVZ or KVM networking, and I had read quite a few online items that were (explicitly or not) based on OpenVZ networking requirements. These seemed to require tinkering with bridge and other definitions and configurations. After your last post, I realized that my pathetic skills could at least diagnose a straightforward networking problem in CentOS. If I could ignore all the virtual networking confusion, the resolution would be quick and final. As it was.

If you have an single box with the ip 192.168.0.100 and take the networkcable instead to the proxmoxserver to the single box your networkconnection will also don't work, because you are in the wrong network. With the VM on the proxmox-host is this the same!
Of course can you use with proxmox diffrent networks (vmbr0, vmbr1, vmbr20....) but you must have nics for that (or vlan-tagging) and the network infrastructure, like router.

YES

What do you want to change? vmbr0, or the VM-internal IP?
Like wrote before - vmbr0 is simply a network-hub for all NICs on this network. The internal ip must be changed by you (who depends on the client os).


Udo

As my final comment on this thread, I would again like to thank you for your patience and efforts in resolving this problem for us. My colleagues and I are simple-minded software developers who have only a minimal grasp of operating-system fundamentals. Virtual network gateways are far from our training or experience. This situation will not change for us, as we are not rewarded for learning more about the OS: we have to deliver working applications, and everything else is shoved to our spare time, evenings, or weekends.

Most commercial OS products have sufficient documentation or other support for us to get needed things running, and so do many of the open-source OS's, particularly Red Hat and Ubuntu. As a result, their communities include large numbers of the ignorant as well as the expected small concentration of experts. We, the ignorant, can therefore use these products in support of our own specialized work, make a little money, perhaps take a course or buy a book. Over time, the group of ignorant souls converts into experts, at least in part.

Newer or smaller open-source groups, like the Proxmox community, often have difficulties supporting the ignorant, and as a result the groups unfortunately may stay small even as they grow old. I think you showed exceptional patience in helping me understand the nature of our problem and in tracking it to an eventual solution. Without your regular replies this problem would have stopped us from understanding and using Proxmox. We may run across something in Proxmox tomorrow that really stops us from progressing. But we got this far, I learned a little more about the network models behind the scenes, and the traces of our investigation left on the internet through this forum may help someone else. Thank you sincerely for your help and I hope you keep up your support for the Proxmox community.
 
Newer or smaller open-source groups, like the Proxmox community, often have difficulties supporting the ignorant, and as a result the groups unfortunately may stay small even as they grow old.

Proxmox uses Debian, and the Debian community is really large.
 
I configured virtual ethernet in a container with debian 6
Though documentation advices something like this:
auto eth0
iface eth0 inet static
address 10.30.100.6
netmask 255.255.255.255
broadcast 10.30.100.255
gateway 10.30.100.2
up /sbin/ip route add default dev eth0

the last line hasn't worked in my configuration.
I solved it by adding the following almost at the end of /etc/init.d/networking but before exit 0

ip route add default dev eth0

And that really made it!

I hope it helps!
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!