[fedora-virt] vanilla bridging network

Laine Stump laine at laine.org
Fri Sep 19 21:40:23 UTC 2014


On 09/19/2014 11:25 AM, Laine Stump wrote:
> On 09/17/2014 09:49 PM, Robert Strickler wrote:
>> I am trying to define a network tht just bridges the traffic between
>> the virtual machine network and the LAN attached to eth0
>>
>> No dnsmasq/dhcp as it is difficult to impossible to tie dnsmasq to the
>> master ISC servers on the LAN.
>>
>> It should forward/receive packets like a standard hardware bridge
>> The virtual guests should get their addressing from the dhcp server on
>> the LAN and DNS from the server as well.
>>
>> with the following I can not get dhcp discover reply from the LAN
>> server, nor can I manually code the IP/gateway/DNS and ping the hard
>> address (172.30.2.33) can anyone tell me what I am missing? Vhost and
>> vguest are both CENTOS7
>>
>> ======================
>> <networkstatus>
>>   <class_id bitmap='0-2'/>
>>   <floor sum='0'/>
>>   <network>
>>     <name>plain</name>
>>     <uuid>31f78c2c-257d-4c57-82e5-0c53deadbeef</uuid>
>>     <forward mode='bridge'/>
>>     <bridge name='virbr1' />
>>     <mac address='52:54:00:b1:34:77'/>
>>     <domain name='plain'/>
>>     <ip address='172.30.2.1' netmask='255.255.255.0'>
>>         <dhcp relay='yes'/>
>>         <dhcp enable='no' relay='yes'/>
> 1) Editing the file /var/run/libvirt/network/plain.xml does not change
> the configuration of a network. The files in /var/run/libvirt are used
> *only* internally by libvirt to store the current status of the objects
> it manages; even libvirt itself does not store configuration information
> there. Any changes you make to those files will only either be ignored,
> or confuse libvirt.

Hmm, I left out two important pieces of information here: 1) I am
deducing that you're attempting to change the configuration via editing
/var/run/libvirt/network/plain.xml from the fact that your xml begins
with "<networkstatus>, and that file is the only place that is seen, and
2) the proper way to modify the configuration of the network named
"plain" is with "virsh net-edit plain" (changes will take effect the
next time you net-destroy and net-start that network).

>
> 2) The <ip> and <domain> elements are ignored/meaningless in any network
> that isn't forward mode='route|nat' or no forward mode (i.e. an isolated
> network). In particular, for <forward mode='bridge'> it is assumed that
> the host's system network configuration has already setup any necessary
> IP address for the bridge, and domain is irrelevant because libvirt
> doesn't start a dhcp server for such a bridge (again, it's assumed that
> if a dhcp server is needed for that bridge, it was already setup elsewhere)
>
> 3) Even if you did have a suitable forward mode such that the <ip>
> element was recognized/used, the <dhcp> subelement in libvirt as built
> for CentOS (or any other distro, or upstream) does not recognize either
> a "relay" or an "enable" attribute. A set of patches to implement dhcp
> relay functionality was sent upstream back in February of 2013, but due
> to the libvirt project's policy of requiring use of real names (rather
> than a pseudonym) by the author for any patches accepted into upstream,
> they were not pushed and no further work has been done in that area.
>
>
> <!--
>> The relay will not be started if the "enable" property is 'no':
>> -->
>>     </ip>
>>   </network>
>> </networkstatus>
>> ===========================
>>
>> A routed environment would be acceptable, but bridged is better as it
>> should not be required to change my routing on the gateway router 
>>
> As long as the bridge named "virbr1" is present in your system network
> config, is bound to a physical netdev, and there is a dhcp server
> available on the network where the physical device is attached, this
> should "just work" without any of the extra stuff you tried to add.
>
> The bug mentioned by Pavel Lisý in another response should not be an
> issue in this case (it's only a problem when the only host bridges on
> the system are those created by libvirt), but still worth checking just
> to make sure.
> _______________________________________________
> virt mailing list
> virt at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/virt



More information about the virt mailing list