[
https://issues.apache.org/jira/browse/CLOUDSTACK-10081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16833266#comment-16833266
]
ASF subversion and git services commented on CLOUDSTACK-10081:
--------------------------------------------------------------
Commit 3729511c376ae1d3c2b9bb22e3e2988998e993a2 in cloudstack's branch
refs/heads/master from ustcweizhou
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=3729511 ]
kvm: Fix three issues with Ubuntu 16.04 hosts (#3227)
* ubuntu16: fix unable to add host if cloudbrX is not configured
while add a ubuntu16.04 host with native eth0 (cloudbrX is not configured),
the operation failed and I got the following error in
/var/log/cloudstack/agent/setup.log
```
DEBUG:root:execute:ifconfig eth0
DEBUG:root:[Errno 2] No such file or directory
File "/usr/lib/python2.7/dist-packages/cloudutils/serviceConfig.py", line 38,
in configration
result = self.config()
File "/usr/lib/python2.7/dist-packages/cloudutils/serviceConfig.py", line
211, in config
super(networkConfigUbuntu, self).cfgNetwork()
File "/usr/lib/python2.7/dist-packages/cloudutils/serviceConfig.py", line
108, in cfgNetwork
device = self.netcfg.getDefaultNetwork()
File "/usr/lib/python2.7/dist-packages/cloudutils/networkConfig.py", line 53,
in getDefaultNetwork
pdi = networkConfig.getDevInfo(dev)
File "/usr/lib/python2.7/dist-packages/cloudutils/networkConfig.py", line
157, in getDevInfo
elif networkConfig.isBridge(dev) or networkConfig.isOvsBridge(dev):
```
The issue is caused by commit 9c7cd8c2485412bc847b2c2473b962fa01435b24
2017-09-19 16:45 Sigert Goeminne ● CLOUDSTACK-10081: CloudUtils getDevInfo
function will now return "bridge" instead o
* ubuntu16: Stop service libvirt-bin.socket while add a host
service libvirt-bin.socket will be started when add a ubuntu 16.04 host
DEBUG:root:execute:sudo /usr/sbin/service libvirt-bin start
However, libvirt-bin service will be broken by it after restarting
Stopping service libvirt-bin.socket will fix the issue.
An example is given as below.
```
root@node32:~# /etc/init.d/libvirt-bin restart
[ ok ] Restarting libvirt-bin (via systemctl): libvirt-bin.service.
root@node32:~# virsh list
error: failed to connect to the hypervisor
error: no valid connection
error: Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such
file or directory
root@node32:~# systemctl stop libvirt-bin.socket
root@node32:~# /etc/init.d/libvirt-bin restart
[ ok ] Restarting libvirt-bin (via systemctl): libvirt-bin.service.
root@node32:~# virsh list
Id Name State
----------------------------------------------------
```
* ubuntu16: Diable libvirt default network
By default, libvirt will create default network virbr0 on kvm hypervisors.
If vm uses the same ip range 192.168.122.0/24, there will be some issues.
In some cases, if we run tcpdump inside vm, we will see the ip of kvm
hypervisor as source ip.
> CloudUtils getDevInfo function only checks for KVM bridgePort and not OVS
> -------------------------------------------------------------------------
>
> Key: CLOUDSTACK-10081
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10081
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: cloudstack-agent
> Affects Versions: 4.11.0.0
> Reporter: Sigert Goeminne
> Assignee: Sigert Goeminne
> Priority: Major
> Fix For: 4.11.0.0
>
>
> CloudUtils getDevInfo function only checks for KVM bridgePort and not OVS. In
> case you provide an ovsbridge, getDevInfo(dev) will say it's a device instead
> of a bridge.
> h2. Scenario
> h3. Expected behaviour
> *Given* a KVM Host with openvswitch networking
> *and* kvmnetworklabel of the guest traffic type specifying the name of an
> existing OVS bridge.
> *When* cloudstack-setup-agent is run on the host
> *Then* the existing openvswitch bridge is used.
> h3. Actual (incorrect) behaviour
> A new bridge cloudbr0 is created in openvswitch.
> and the networking scripts define the new bridge as OVS_BRIDGE in the ifcfg
> of the existing bridge.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
