- Users - oVirt List Archives

vlan-tagging on non-tagged network
by Felix Pepinghege 19 Aug '15

19 Aug '15

Hi everybody! I am experiencing a behaviour of ovirt, of which I don't know whether it is expected or not. My setup is as follows: A virtual machine has a logical network attached to it, which is configured without vlan-tagging and listens to the name 'trunk'. The VM is running an openvpn server. It is a patched openvpn version, including vlan-tagging. That is, openvpn clients get a vlan tag. This should not really be an issue but should satisfy the "why do you want to do it in the first place"-questions. Anyhow, effectively, the VM simply puts vlan-tagged ethernet-frames on the virtual network. These frames, however, never make it to the host's network bridge, which represents the logical network. My observations are: According to tcpdump, the vlan-tagged packages arrive at the "eth1"-interface inside the VM (which *is* the correct interface). Again, according to tcpdump, these packages never arrive at the corresponding network-bridge (i.e., the interface 'trunk') on the host. I know that the setup itself is feasible with KVM---I have it working on a proxmox-machine. Therefore, my conclusion is, that ovirt doesn't like vlan-tagged ethernet-frames on non-tagged logical networks, and somehow filters them out, though I don't really see on what "level" that would happen (Handling the ethernet frames should be a concern of KVM/QEMU/Linux only, once ovirt has started the VM). So this problem could be a CentOS issue, but I really don't see why CentOS should act differently than debian does (proxmox is debian-based). Is this a known/wanted/expected behaviour of ovirt, and can I somehow prevent or elude it? Any help is much appreciated! Of course I am happy to provide more information if that helps helping me :) Regards, Felix

3 8

Benefits of Cluster separation
by Groten, Ryan 18 Aug '15

18 Aug '15

--_000_c8b4ff80e80a44648b7fc68991990e74CD1001M21corpads_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We're running into some performance problems stemming from having too many = Hosts/VMs/Disks running from the same Datacenter/Cluster. Because of that = I'm looking into splitting the DC into multiple separate ones with differen= t Hosts/Storage. But I'm a little confused what the benefit of separating hosts into cluster= s achieves. Can someone please explain what the common use cases are? Sin= ce all the clusters in a DC seem to need to see the same storage, I don't t= hink it would help my situation anyway. Thanks, Ryan --_000_c8b4ff80e80a44648b7fc68991990e74CD1001M21corpads_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Ce= ntury Gothic","sans-serif"">We’re running into some pe= rformance problems stemming from having too many Hosts/VMs/Disks running fr= om the same Datacenter/Cluster.  Because of that I’m looking int= o splitting the DC into multiple separate ones with different Hosts/Storage.= <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Ce= ntury Gothic","sans-serif"">But I’m a little confused = what the benefit of separating hosts into clusters achieves.  Can some= one please explain what the common use cases are?  Since all the clust= ers in a DC seem to need to see the same storage, I don’t think it would= help my situation anyway.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Ce= ntury Gothic","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Ce= ntury Gothic","sans-serif"">Thanks,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Ce= ntury Gothic","sans-serif"">Ryan <o:p></o:p></span></p> </div> </body> </html> --_000_c8b4ff80e80a44648b7fc68991990e74CD1001M21corpads_--

3 4

error messages filling disk
by Chris Liebman 18 Aug '15

18 Aug '15

This has happened twice now, these messages start spewing into the both /var/log/messages and /var/log/vdsm/vdsm.log with slightly different formats but the same information. Restarting vdsmd fixes this but I'l like to find why it gets into this state. CentOS 6.7 oVirt 3.5. Any ideas? Aug 18 16:06:36 ovirt-node250 vdsm vds.MultiProtocolAcceptor ERROR > Unhandled exception#012Traceback (most recent call last):#012 File > "/usr/share/vdsm/protocoldetector.py", line 86, in serve_forever#012 > self._process_events()#012 File "/usr/share/vdsm/protocoldetector.py", > line 105, in _process_events#012 self._handle_connection_read(fd)#012 > File "/usr/share/vdsm/protocoldetector.py", line 225, in > _handle_connection_read#012 data = > client_socket.recv(self._required_size, socket.MSG_PEEK)#012 File > "/usr/lib/python2.6/site-packages/vdsm/sslutils.py", line 58, in read#012 > self._data = self.connection.read(size)#012 File > "/usr/lib64/python2.6/site-packages/M2Crypto/SSL/Connection.py", line 229, > in read#012 return self._read_nbio(size)#012 File > "/usr/lib64/python2.6/site-packages/M2Crypto/SSL/Connection.py", line 218, > in _read_nbio#012 return m2.ssl_read_nbio(self.ssl, size)#012SSLError: > unexpected eof > > Aug 18 16:06:36 ovirt-node250 vdsm vds.MultiProtocolAcceptor ERROR > Unhandled exception#012Traceback (most recent call last):#012 File > "/usr/share/vdsm/protocoldetector.py", line 86, in serve_forever#012 > self._process_events()#012 File "/usr/share/vdsm/protocoldetector.py", > line 105, in _process_events#012 self._handle_connection_read(fd)#012 > File "/usr/share/vdsm/protocoldetector.py", line 225, in > _handle_connection_read#012 data = > client_socket.recv(self._required_size, socket.MSG_PEEK)#012 File > "/usr/lib/python2.6/site-packages/vdsm/sslutils.py", line 58, in read#012 > self._data = self.connection.read(size)#012 File > "/usr/lib64/python2.6/site-packages/M2Crypto/SSL/Connection.py", line 229, > in read#012 return self._read_nbio(size)#012 File > "/usr/lib64/python2.6/site-packages/M2Crypto/SSL/Connection.py", line 218, > in _read_nbio#012 return m2.ssl_read_nbio(self.ssl, size)#012SSLError: > unexpected eof > > Aug 18 16:06:36 ovirt-node250 vdsm vds.MultiProtocolAcceptor ERROR > Unhandled exception#012Traceback (most recent call last):#012 File > "/usr/share/vdsm/protocoldetector.py", line 86, in serve_forever#012 > self._process_events()#012 File "/usr/share/vdsm/protocoldetector.py", > line 105, in _process_events#012 self._handle_connection_read(fd)#012 > File "/usr/share/vdsm/protocoldetector.py", line 225, in > _handle_connection_read#012 data = > client_socket.recv(self._required_size, socket.MSG_PEEK)#012 File > "/usr/lib/python2.6/site-packages/vdsm/sslutils.py", line 58, in read#012 > self._data = self.connection.read(size)#012 File > "/usr/lib64/python2.6/site-packages/M2Crypto/SSL/Connection.py", line 229, > in read#012 return self._read_nbio(size)#012 File > "/usr/lib64/python2.6/site-packages/M2Crypto/SSL/Connection.py", line 218, > in _read_nbio#012 return m2.ssl_read_nbio(self.ssl, size)#012SSLError: > unexpected eof > > Aug 18 16:06:36 ovirt-node250 vdsm vds.MultiProtocolAcceptor ERROR > Unhandled exception#012Traceback (most recent call last):#012 File > "/usr/share/vdsm/protocoldetector.py", line 86, in serve_forever#012 > self._process_events()#012 File "/usr/share/vdsm/protocoldetector.py", > line 105, in _process_events#012 self._handle_connection_read(fd)#012 > File "/usr/share/vdsm/protocoldetector.py", line 225, in > _handle_connection_read#012 data = > client_socket.recv(self._required_size, socket.MSG_PEEK)#012 File > "/usr/lib/python2.6/site-packages/vdsm/sslutils.py", line 58, in read#012 > self._data = self.connection.read(size)#012 File > "/usr/lib64/python2.6/site-packages/M2Crypto/SSL/Connection.py", line 229, > in read#012 return self._read_nbio(size)#012 File > "/usr/lib64/python2.6/site-packages/M2Crypto/SSL/Connection.py", line 218, > in _read_nbio#012 return m2.ssl_read_nbio(self.ssl, size)#012SSLError: > unexpected eof > > Aug 18 16:06:36 ovirt-node250 vdsm vds.MultiProtocolAcceptor ERROR > Unhandled exception#012Traceback (most recent call last):#012 File > "/usr/share/vdsm/protocoldetector.py", line 86, in serve_forever#012 > self._process_events()#012 File "/usr/share/vdsm/protocoldetector.py", > line 105, in _process_events#012 self._handle_connection_read(fd)#012 > File "/usr/share/vdsm/protocoldetector.py", line 225, in > _handle_connection_read#012 data = > client_socket.recv(self._required_size, socket.MSG_PEEK)#012 File > "/usr/lib/python2.6/site-packages/vdsm/sslutils.py", line 58, in read#012 > self._data = self.connection.read(size)#012 File > "/usr/lib64/python2.6/site-packages/M2Crypto/SSL/Connection.py", line 229, > in read#012 return self._read_nbio(size)#012 File > "/usr/lib64/python2.6/site-packages/M2Crypto/SSL/Connection.py", line 218, > in _read_nbio#012 return m2.ssl_read_nbio(self.ssl, size)#012SSLError: > unexpected eof > > Aug 18 16:06:36 ovirt-node250 vdsm vds.MultiProtocolAcceptor ERROR > Unhandled exception#012Traceback (most recent call last):#012 File > "/usr/share/vdsm/protocoldetector.py", line 86, in serve_forever#012 > self._process_events()#012 File "/usr/share/vdsm/protocoldetector.py", > line 105, in _process_events#012 self._handle_connection_read(fd)#012 > File "/usr/share/vdsm/protocoldetector.py", line 225, in > _handle_connection_read#012 data = > client_socket.recv(self._required_size, socket.MSG_PEEK)#012 File > "/usr/lib/python2.6/site-packages/vdsm/sslutils.py", line 58, in read#012 > self._data = self.connection.read(size)#012 File > "/usr/lib64/python2.6/site-packages/M2Crypto/SSL/Connection.py", line 229, > in read#012 return self._read_nbio(size)#012 File > "/usr/lib64/python2.6/site-packages/M2Crypto/SSL/Connection.py", line 218, > in _read_nbio#012 return m2.ssl_read_nbio(self.ssl, size)#012SSLError: > unexpected eof > > Aug 18 16:06:36 ovirt-node250 rsyslogd-2177: imuxsock begins to drop > messages from pid 19808 due to rate-limiting >

2 1

live migration
by Demeter Tibor 18 Aug '15

18 Aug '15

Hi, I reinstalled one of my nodes (node1) because I have to replace my hdds. I installed centos 6.6 minimal, but on node re-adding procecure it installed newer qemu-kvm-rhev packages. Since reinstall I can run VMs on this node and I can do live migrate from this node to other, but not backwards. I remember, maybe one years ago it was required to install redhat's version of qemu-kvm-rhve package for this feature. Is it necessary yet? my versions: node0 KVM: 0.12.1.2 - 2.415.el6_5.14, LIBVIRT: libvirt-0.10.2-46.el6_6.1 node1 KVM: 0.12.1.2 - 2.448.el6_6.4, LIBVIRT: libvirt-0.10.2-54.el6 node2 KVM: 0.12.1.2 - 2.448.el6_6.4, LIBVIRT: libvirt-0.10.2-46.el6_6.1 Can I upgrade manual these hosts? I haven't restart my hosts because node0 and node2 is gluster replicate. Thanks in advance, Tibor

4 6

upgrade issues
by Demeter Tibor 18 Aug '15

18 Aug '15

Hi All, I have to upgrade ovirt 3.5.0 to 3.5.3. We have a 3 node system and we have a gluster replica beetwen 2 node of these 3 servers. I had gluster volume beetwen node0 and node2 But I wanted to do a new volume beetwen node1 and node2. It didn't work, it complety kill my node1, because glusterd does not stated.I always have to got always error: gluster peer rejected (related to node1). I followed this article http://www.gluster.org/community/documentation/index.php/Resolving_Peer_Rej… and it was good, my gluster service already worked, but ovirt got these errors Detected deletion of volume g2sata on cluster r710cluster1, and deleted it from engine DB. Detected deletion of volume g4sata on cluster r710cluster1, and deleted it from engine DB. And ovirt does not see my gluster volumes anymore. I've checked with gluster volume status and gluster volume heal g2sata info, it seems to be working, my VMs are ok. How can I reimport my lost volumes to ovirt? Thanks in advance, Tibor

2 5

error adding node.
by Kruijf, Erik-Jan de 18 Aug '15

18 Aug '15

--_000_E9CE402C12757B4FA2BF9817E73F750D0108481B3ESEEX020groupi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I am trying to add the first node to an self hosted engine. When i click ok= i immidiatly get the error that he cannot connect to host. But if i try to= ssh to the host from the engine it works. Can someone please point me to a= n solution? If any logs are needed please let me know. Kind regards, Erik-jan de Kruijf --_000_E9CE402C12757B4FA2BF9817E73F750D0108481B3ESEEX020groupi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html dir=3D"ltr"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <style type=3D"text/css" id=3D"owaParaStyle"></style><style type=3D"text/cs= s"></style> </head> <body fpstyle=3D"1" ocsi=3D"0"> <div style=3D"direction: ltr;font-family: Tahoma;color: #000000;font-size: = 10pt;">Hi, <div><br> </div> <div>I am trying to add the first node to an self hosted engine. When i cli= ck ok i immidiatly get the error that he cannot connect to host. But if i t= ry to ssh to the host from the engine it works. Can someone please point me= to an solution? If any logs are needed please let me know.</div> <div><br> </div> <div>Kind regards,</div> <div><br> </div> <div>Erik-jan de Kruijf</div> </div> </body> </html> --_000_E9CE402C12757B4FA2BF9817E73F750D0108481B3ESEEX020groupi_--

3 10

R: vlan-tagging on non-tagged network
by NUNIN Roberto 17 Aug '15

17 Aug '15

--_000_06wqhiuiyku9vk7vukt2dtor1439845594308emailandroidcom_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Sorry for jumping into the discussion, but I'm currently experiencing exac= tly the opposite behaviour. DHCP offer is reached until the host bridge interface, but it is not propa= gated to the vnet device. I'm using VLAN tagging. Packets incoming are correctly managed until vnet d= evice and seems to have impact only into DHCP packets. Static IP assigned to the vm =E5eave VM active and reachable. Just my cent to a topic that I suppose could be related to mine issue. Roberto -------- Messaggio originale -------- Da: Felix Pepinghege <pepinghege(a)ira.uka.de> Data: 17/08/2015 13:36 (GMT+01:00) A: Users(a)ovirt.org Oggetto: Re: [ovirt-users] vlan-tagging on non-tagged network Hi Ido, hi everybody, sorry that I kept you waiting for two months, I only just found the time to go back to this problem. You were completely right with your guess. The ethernet frames do appear on the vnet-interface, but not on the bridge. The dropped-counter seems to be independent from these losses, though. However, while this tells me *where* the problem is, I still don't know *what* the problem is. I've done some research, but couldn't find anything particularly helpful. An interesting point may be that this problem is mono-directional. That is, the bridge happily passes vlan-tagged frames from the ethernet device to the vnet, but not the other way around. Untagged ethernet frames make their way through the brigde, no matter where they come from. The vlan module is loaded, as to the versioning questions: # cat /etc/centos-release ; uname -s -v -r CentOS Linux release 7.1.1503 (Core) Linux 3.10.0-229.7.2.el7.x86_64 #1 SMP Tue Jun 23 22:06:11 UTC 2015 The guest OS is an up-to-date Debian Jessie, which should not matter, though, as the frames get lost on the doorstep of the bridge on the host. Again, any suggestions are much appreciated! Regards, Felix Am 16.06.2015 um 08:27 schrieb Ido Barkan: > Hey Felix. > > IIUC your frames are dropped by the bridge. Ovirt uses Linux Bridges > To connect virtual machines to 'networks'. The guest connects to the brid= ge > using a tap device which usually is called 'vnet<number>'. > > So, just to verify, can you please tcpdump both on the bridge device and = on the tap device? > The bridge can be quite noisy so I suggest filtering traffic using the gu= est's MAC > address. So I am not sure what protocol you use for tunneling but applyin= g > a filter similar to this one should do the job: > tcpdump -n -i vnet0 -vvv -s 1500 'udp[38:4]=3D0x001a4aaeec8e' > > My guess is that you will observe traffic on the tap device, but not on t= he bridge. > You didn't specify which centOS version you use but I do remember seeing = people > complaining about Linux bridges discarding their tagged frames. > You can -maybe- also observe the 'dropped' counter increases on the bridg= e by running: > 'ip -s link show dev trunk' > > There were a few bugs on rhel6/7 about this, specifically I remember > https://bugzilla.redhat.com/show_bug.cgi?id=3D1174291 > and > https://bugzilla.redhat.com/show_bug.cgi?id=3D1200275#c20 > > Also, is the vlan module loaded on your host? > 'lsmod |grep 8021q' > > Thanks, > Ido > > ----- Original Message ----- > From: "Felix Pepinghege" <pepinghege(a)ira.uka.de> > To: Users(a)ovirt.org > Sent: Monday, June 15, 2015 11:33:39 AM > Subject: [ovirt-users] vlan-tagging on non-tagged network > > Hi everybody! > > I am experiencing a behaviour of ovirt, of which I don't know whether it > is expected or not. My setup is as follows: > A virtual machine has a logical network attached to it, which is > configured without vlan-tagging and listens to the name 'trunk'. > The VM is running an openvpn server. It is a patched openvpn version, > including vlan-tagging. That is, openvpn clients get a vlan tag. This > should not really be an issue but should satisfy the "why do you want to > do it in the first place"-questions. > Anyhow, effectively, the VM simply puts vlan-tagged ethernet-frames on > the virtual network. These frames, however, never make it to the host's > network bridge, which represents the logical network. > My observations are: According to tcpdump, the vlan-tagged packages > arrive at the "eth1"-interface inside the VM (which *is* the correct > interface). Again, according to tcpdump, these packages never arrive at > the corresponding network-bridge (i.e., the interface 'trunk') on the hos= t. > I know that the setup itself is feasible with KVM---I have it working on > a proxmox-machine. Therefore, my conclusion is, that ovirt doesn't like > vlan-tagged ethernet-frames on non-tagged logical networks, and somehow > filters them out, though I don't really see on what "level" that would > happen (Handling the ethernet frames should be a concern of > KVM/QEMU/Linux only, once ovirt has started the VM). > So this problem could be a CentOS issue, but I really don't see why > CentOS should act differently than debian does (proxmox is debian-based). > Is this a known/wanted/expected behaviour of ovirt, and can I somehow > prevent or elude it? > > Any help is much appreciated! Of course I am happy to provide more > information if that helps helping me :) > > Regards, > Felix > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users ________________________________ Questo messaggio e' indirizzato esclusivamente al destinatario indicato e p= otrebbe contenere informazioni confidenziali, riservate o proprietarie. Qua= lora la presente venisse ricevuta per errore, si prega di segnalarlo immedi= atamente al mittente, cancellando l'originale e ogni sua copia e distruggen= do eventuali copie cartacee. Ogni altro uso e' strettamente proibito e potr= ebbe essere fonte di violazione di legge. This message is for the designated recipient only and may contain privilege= d, proprietary, or otherwise private information. If you have received it i= n error, please notify the sender immediately, deleting the original and al= l copies and destroying any hard copies. Any other use is strictly prohibit= ed and may be unlawful. --_000_06wqhiuiyku9vk7vukt2dtor1439845594308emailandroidcom_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 2"> <meta name=3D"Generator" content=3D"Microsoft Exchange Server"> <style></style> </head> <body> Sorry for jumping into the discussion,  but I'm currently experiencing= exactly the opposite behaviour. <div>DHCP offer is reached  until the host bridge interface, but it is= not propagated to the vnet device.</div> <div>I'm using VLAN tagging. Packets incoming are correctly managed until v= net device and seems to have impact only into DHCP packets.</div> <div><br> </div> <div>Static IP assigned to the vm =E5eave VM active and reachable.</div> <div><br> </div> <div>Just my cent to a topic that I suppose could be related to mine issue.= </div> <div><br> </div> <div>Roberto</div> <br> <br> -------- Messaggio originale --------<br> Da: Felix Pepinghege <pepinghege(a)ira.uka.de> <br> Data: 17/08/2015 13:36 (GMT+01:00) <br> A: Users(a)ovirt.org <br> Oggetto: Re: [ovirt-users] vlan-tagging on non-tagged network <br> <br> <font size=3D"2"> <div class=3D"PlainText">Hi Ido, hi everybody,<br> <br> sorry that I kept you waiting for two months, I only just found the time <b= r> to go back to this problem.<br> <br> You were completely right with your guess. The ethernet frames do appear <b= r> on the vnet-interface, but not on the bridge. The dropped-counter seems <br= > to be independent from these losses, though.<br> <br> However, while this tells me *where* the problem is, I still don't know <br= > *what* the problem is. I've done some research, but couldn't find <br> anything particularly helpful.<br> An interesting point may be that this problem is mono-directional. That <br= > is, the bridge happily passes vlan-tagged frames from the ethernet <br> device to the vnet, but not the other way around. Untagged ethernet <br> frames make their way through the brigde, no matter where they come from.<b= r> <br> The vlan module is loaded, as to the versioning questions:<br> # cat /etc/centos-release ; uname -s -v -r<br> CentOS Linux release 7.1.1503 (Core)<br> Linux 3.10.0-229.7.2.el7.x86_64 #1 SMP Tue Jun 23 22:06:11 UTC 2015<br> <br> The guest OS is an up-to-date Debian Jessie, which should not matter, <br> though, as the frames get lost on the doorstep of the bridge on the host.<b= r> <br> Again, any suggestions are much appreciated!<br> <br> Regards,<br> Felix<br> <br> <br> Am 16.06.2015 um 08:27 schrieb Ido Barkan:<br> > Hey Felix.<br> ><br> > IIUC your frames are dropped by the bridge. Ovirt uses Linux Bridges<b= r> > To connect virtual machines to 'networks'. The guest connects to the b= ridge<br> > using a tap device which usually is called 'vnet<number>'.<br> ><br> > So, just to verify, can you please tcpdump both on the bridge device a= nd on the tap device?<br> > The bridge can be quite noisy so I suggest filtering traffic using the= guest's MAC<br> > address. So I am not sure what protocol you use for tunneling but appl= ying<br> > a filter similar to this one should do the job:<br> >           tcpdump -n= -i vnet0 -vvv -s 1500 'udp[38:4]=3D0x001a4aaeec8e'<br> ><br> > My guess is that you will observe traffic on the tap device, but not o= n the bridge.<br> > You didn't specify which centOS version you use but I do remember seei= ng people<br> > complaining about Linux bridges discarding their tagged frames.<br> > You can -maybe- also observe the 'dropped' counter increases on the br= idge by running:<br> >           'ip -s lin= k show dev trunk'<br> ><br> > There were a few bugs on rhel6/7 about this, specifically I remember<b= r> > <a href=3D"https://bugzilla.redhat.com/show_bug.cgi?id=3D1174291">http= s://bugzilla.redhat.com/show_bug.cgi?id=3D1174291</a><br> > and<br> > <a href=3D"https://bugzilla.redhat.com/show_bug.cgi?id=3D1200275#c20">= https://bugzilla.redhat.com/show_bug.cgi?id=3D1200275#c20</a><br> ><br> > Also, is the vlan module loaded on your host?<br> > 'lsmod |grep 8021q'<br> ><br> > Thanks,<br> > Ido<br> ><br> > ----- Original Message -----<br> > From: "Felix Pepinghege" <pepinghege(a)ira.uka.de><br> > To: Users(a)ovirt.org<br> > Sent: Monday, June 15, 2015 11:33:39 AM<br> > Subject: [ovirt-users] vlan-tagging on non-tagged network<br> ><br> > Hi everybody!<br> ><br> > I am experiencing a behaviour of ovirt, of which I don't know whether = it<br> > is expected or not. My setup is as follows:<br> > A virtual machine has a logical network attached to it, which is<br> > configured without vlan-tagging and listens to the name 'trunk'.<br> > The VM is running an openvpn server. It is a patched openvpn version,<= br> > including vlan-tagging. That is, openvpn clients get a vlan tag. This<= br> > should not really be an issue but should satisfy the "why do you = want to<br> > do it in the first place"-questions.<br> > Anyhow, effectively, the VM simply puts vlan-tagged ethernet-frames on= <br> > the virtual network. These frames, however, never make it to the host'= s<br> > network bridge, which represents the logical network.<br> > My observations are: According to tcpdump, the vlan-tagged packages<br= > > arrive at the "eth1"-interface inside the VM (which *is* the= correct<br> > interface). Again, according to tcpdump, these packages never arrive a= t<br> > the corresponding network-bridge (i.e., the interface 'trunk') on the = host.<br> > I know that the setup itself is feasible with KVM---I have it working = on<br> > a proxmox-machine. Therefore, my conclusion is, that ovirt doesn't lik= e<br> > vlan-tagged ethernet-frames on non-tagged logical networks, and someho= w<br> > filters them out, though I don't really see on what "level" = that would<br> > happen (Handling the ethernet frames should be a concern of<br> > KVM/QEMU/Linux only, once ovirt has started the VM).<br> > So this problem could be a CentOS issue, but I really don't see why<br= > > CentOS should act differently than debian does (proxmox is debian-base= d).<br> > Is this a known/wanted/expected behaviour of ovirt, and can I somehow<= br> > prevent or elude it?<br> ><br> > Any help is much appreciated! Of course I am happy to provide more<br> > information if that helps helping me :)<br> ><br> > Regards,<br> > Felix<br> > _______________________________________________<br> > Users mailing list<br> > Users(a)ovirt.org<br> > <a href=3D"http://lists.ovirt.org/mailman/listinfo/users">http://lists= .ovirt.org/mailman/listinfo/users</a><br> ><br> <br> _______________________________________________<br> Users mailing list<br> Users(a)ovirt.org<br> <a href=3D"http://lists.ovirt.org/mailman/listinfo/users">http://lists.ovir= t.org/mailman/listinfo/users</a><br> </div> </font><br> <hr> <font face=3D"Courier New" color=3D"Black" size=3D"2">Questo messaggio e' i= ndirizzato esclusivamente al destinatario indicato e potrebbe contenere inf= ormazioni confidenziali, riservate o proprietarie. Qualora la presente veni= sse ricevuta per errore, si prega di segnalarlo immediatamente al mittente, cancellando l'originale e ogni sua copia e dis= truggendo eventuali copie cartacee. Ogni altro uso e' strettamente proibito= e potrebbe essere fonte di violazione di legge.<br> <br> This message is for the designated recipient only and may contain privilege= d, proprietary, or otherwise private information. If you have received it i= n error, please notify the sender immediately, deleting the original and al= l copies and destroying any hard copies. Any other use is strictly prohibited and may be unlawful.<br> </font> </body> </html> --_000_06wqhiuiyku9vk7vukt2dtor1439845594308emailandroidcom_--

1 0

Hosted Engine and Sanlock
by xJutsu Team 17 Aug '15

17 Aug '15

Hi there, recently there was a network failure in our ovirt infrastructure, causing ovirt engine to become unstable. It will restarted after 10-20minutes. Load average was high. Command issued will hanged. Looking at host logs, there was endless locking errors (/var/log/sanlock.log) below. I tried to re-initialize by stopp HE HA agent/broker in all hosts, by issuing following command in one of the host: # su - vdsm -s /bin/bash $ sanlock direct init -s hosted-engine:0:/rhev/data-center/mnt/192.168.10.10 \\:_engine/a184f8ac-b779-4bf8-81c3-751115e15436/ha_agent/hosted-engine.lockspace:0 and than restart both agent and broker in the same host. However i m still getting the same problem. Any advice on this matter? Installation Infos: ---------------------- ovirt 3.5.3 vdsm-xmlrpc-4.16.24-0.el6.noarch vdsm-python-zombiereaper-4.16.24-0.el6.noarch vdsm-python-4.16.24-0.el6.noarch vdsm-jsonrpc-4.16.24-0.el6.noarch vdsm-4.16.24-0.el6.x86_64 vdsm-cli-4.16.24-0.el6.noarch vdsm-yajsonrpc-4.16.24-0.el6.noarch ovirt-hosted-engine-ha-1.2.6-2.el6.noarch ovirt-hosted-engine-setup-1.2.6-0.0.master.20150812080635.git5295df1.el6.noarch ----- end installation infos ------ /var/log/sanlock.log 2015-08-18 04:20:02+0800 1704 [9385]: s2 delta_renew read rv -202 offset 0 /rhev/data-center/mnt/192.168.10.10: _engine/a184f8ac-b779-4bf8-81c3-751115e15436/dom_md/ids 2015-08-18 04:20:02+0800 1704 [9385]: s2 renewal error -202 delta_length 11 last_success 1662 2015-08-18 04:20:11+0800 1713 [9385]: a184f8ac aio collect 0 0x7fc5040008c0:0x7fc5040008d0:0x7fc50b9f7000 result 1048576:0 other free 2015-08-18 04:20:11+0800 1713 [9833]: hosted-e aio collect 0 0x7fc4f80008c0:0x7fc4f80008d0:0x7fc50baf9000 result 1048576:0 other free 2015-08-18 04:20:11+0800 1713 [9385]: a184f8ac aio collect 0 0x7fc504000910:0x7fc504000920:0x7fc50bbfb000 result 1048576:0 other free 2015-08-18 04:20:11+0800 1713 [9833]: hosted-e aio collect 0 0x7fc4f8000910:0x7fc4f8000920:0x7fc50beff000 result 1048576:0 other free 2015-08-18 04:21:43+0800 1805 [9385]: a184f8ac aio timeout 0 0x7fc5040008c0:0x7fc5040008d0:0x7fc50adf2000 ioto 10 to_count 18 2015-08-18 04:21:43+0800 1805 [9385]: s2 delta_renew read rv -202 offset 0 /rhev/data-center/mnt/192.168.10.10: _engine/a184f8ac-b779-4bf8-81c3-751115e15436/dom_md/ids 2015-08-18 04:21:43+0800 1805 [9385]: s2 renewal error -202 delta_length 10 last_success 1774 2015-08-18 04:21:43+0800 1805 [9833]: hosted-e aio timeout 0 0x7fc4f80008c0:0x7fc4f80008d0:0x7fc50aef4000 ioto 10 to_count 14 2015-08-18 04:21:43+0800 1805 [9833]: s3 delta_renew read rv -202 offset 0 /rhev/data-center/mnt/192.168.10.10: _engine/a184f8ac-b779-4bf8-81c3-751115e15436/images/190f4d2a-77f4-4403-af0d-62853560c653/2be7db4d-f30e-4873-b4ef-cff9e757341c 2015-08-18 04:21:43+0800 1805 [9833]: s3 renewal error -202 delta_length 10 last_success 1774 2015-08-18 04:21:52+0800 1814 [9385]: a184f8ac aio collect 0 0x7fc5040008c0:0x7fc5040008d0:0x7fc50adf2000 result 1048576:0 other free 2015-08-18 04:21:52+0800 1814 [9833]: hosted-e aio collect 0 0x7fc4f80008c0:0x7fc4f80008d0:0x7fc50aef4000 result 1048576:0 other free 2015-08-18 04:23:04+0800 1885 [9833]: hosted-e aio timeout 0 0x7fc4f80008c0:0x7fc4f80008d0:0x7fc50bbfb000 ioto 10 to_count 15 2015-08-18 04:23:04+0800 1885 [9833]: s3 delta_renew read rv -202 offset 0 /rhev/data-center/mnt/192.168.10.10: _engine/a184f8ac-b779-4bf8-81c3-751115e15436/images/190f4d2a-77f4-4403-af0d-62853560c653/2be7db4d-f30e-4873-b4ef-cff9e757341c 2015-08-18 04:23:04+0800 1885 [9833]: s3 renewal error -202 delta_length 10 last_success 1855 2015-08-18 04:23:04+0800 1886 [9385]: a184f8ac aio timeout 0 0x7fc5040008c0:0x7fc5040008d0:0x7fc50beff000 ioto 10 to_count 19 2015-08-18 04:23:04+0800 1886 [9385]: s2 delta_renew read rv -202 offset 0 /rhev/data-center/mnt/192.168.10.10: _engine/a184f8ac-b779-4bf8-81c3-751115e15436/dom_md/ids 2015-08-18 04:23:04+0800 1886 [9385]: s2 renewal error -202 delta_length 10 last_success 1855 2015-08-18 04:23:15+0800 1896 [9833]: hosted-e aio timeout 0 0x7fc4f8000910:0x7fc4f8000920:0x7fc50baf9000 ioto 10 to_count 16 2015-08-18 04:23:15+0800 1896 [9833]: s3 delta_renew read rv -202 offset 0 /rhev/data-center/mnt/192.168.10.10: _engine/a184f8ac-b779-4bf8-81c3-751115e15436/images/190f4d2a-77f4-4403-af0d-62853560c653/2be7db4d-f30e-4873-b4ef-cff9e757341c 2015-08-18 04:23:15+0800 1896 [9833]: s3 renewal error -202 delta_length 10 last_success 1855 2015-08-18 04:23:15+0800 1897 [9385]: a184f8ac aio timeout 0 0x7fc504000910:0x7fc504000920:0x7fc50b9f7000 ioto 10 to_count 20 2015-08-18 04:23:15+0800 1897 [9385]: s2 delta_renew read rv -202 offset 0 /rhev/data-center/mnt/192.168.10.10: _engine/a184f8ac-b779-4bf8-81c3-751115e15436/dom_md/ids 2015-08-18 04:23:15+0800 1897 [9385]: s2 renewal error -202 delta_length 11 last_success 1855 2015-08-18 04:23:26+0800 1907 [9833]: hosted-e aio timeout 0 0x7fc4f8000960:0x7fc4f8000970:0x7fc50aef4000 ioto 10 to_count 17 2015-08-18 04:23:26+0800 1907 [9833]: s3 delta_renew read rv -202 offset 0 /rhev/data-center/mnt/192.168.10.10: _engine/a184f8ac-b779-4bf8-81c3-751115e15436/images/190f4d2a-77f4-4403-af0d-62853560c653/2be7db4d-f30e-4873-b4ef-cff9e757341c 2015-08-18 04:23:26+0800 1907 [9833]: s3 renewal error -202 delta_length 10 last_success 1855 2015-08-18 04:23:26+0800 1908 [9385]: a184f8ac aio timeout 0 0x7fc504000960:0x7fc504000970:0x7fc50adf2000 ioto 10 to_count 21 2015-08-18 04:23:26+0800 1908 [9385]: s2 delta_renew read rv -202 offset 0 /rhev/data-center/mnt/192.168.10.10: _engine/a184f8ac-b779-4bf8-81c3-751115e15436/dom_md/ids 2015-08-18 04:23:26+0800 1908 [9385]: s2 renewal error -202 delta_length 11 last_success 1855 ----- end /var/log/sanlock.log

1 0

stuck hosts - how can I delete them?
by Chris Liebman 17 Aug '15

17 Aug '15

I've just force deleted a DC. I did this because gluster was completely hosed. Multiple nodes with broken disks - don't ask... Anyway - now I see that the Cluster still exists with the hosts. And I cant remove, re-install etc the hosts, nor can I delete the cluster. Help! -- Chris

2 2

problem with iSCSI/multipath.
by Giorgio Bersano 17 Aug '15

17 Aug '15

Hi all. We have an oVirt cluster in production happily running from the beginning of 2014. It started as 3.3 beta and now is Version 3.4.4-1.el6 . Shared storage provided by an HP P2000 G3 iSCSI MSA. The storage server is fully redundant (2 controllers, dual port disks, 4 iscsi connections per controller) and so is the connectivity (two switches, multiple ethernet cards per server). >From now on lets only talk about iSCSI connectivity. The two oldest server have 2 nics each; they have been configured "by hand" setting routes aimed to reach every scsi target from every nic. On the "new" server we installed ovirt 3.5 to have a look at the network configuration provided by oVirt. In Data Center -> iSCSI Multipathing we defined an iSCSI Bond binding together 3 server's nics and the 8 nics of the MSA. The result is a system that has been functioning for months. Recently we had to do an upgrade of the storage firmware. This activity uploads the firmware to one of the MSA controllers then reboots it. Being successful this is repeated on the other controller. There is an impact on the I/O performance but there should be no problems as every "volume" on the MSA remains visible on other paths. Well, that's the theory. On the two "hand configured" hosts we had no significant problems. On the 3.5 host VMs started to migrate due to storage problems then the situation got worse and it took more than an hour to bring again the system to a good operating level. I am inclined to believe that the culprit is the server's routing table. Seems to me that the oVirt generated one is too simplistic and prone to problems in case of connectivity loss (as in our situation or when you have to reboot one of the switches). Anyone on this list with strong experience on similar setup? I have included below some background information. I'm available to provide anything useful to further investigate the case. TIA, Giorgio. ------------------- context information ------------------- oVirt Compatibility Version: 3.4 two FUJITSU PRIMERGY RX300 S5 hosts CPU: Intel(R) Xeon(R) E5504 @ 2.00GHz / Intel Nehalem Family OS Version: RHEL - 6 - 6.el6.centos.12.2 Kernel Version: 2.6.32 - 504.16.2.el6.x86_64 KVM Version: 0.12.1.2 - 2.448.el6_6.2 LIBVIRT Version: libvirt-0.10.2-46.el6_6.6 VDSM Version: vdsm-4.14.17-0.el6 RAM: 40GB mom-0.4.3-1.el6.noarch.rpm ovirt-release34-1.0.3-1.noarch.rpm qemu-img-rhev-0.12.1.2-2.448.el6_6.2.x86_64.rpm qemu-kvm-rhev-0.12.1.2-2.448.el6_6.2.x86_64.rpm qemu-kvm-rhev-tools-0.12.1.2-2.448.el6_6.2.x86_64.rpm vdsm-4.14.17-0.el6.x86_64.rpm vdsm-cli-4.14.17-0.el6.noarch.rpm vdsm-hook-hostusb-4.14.17-0.el6.noarch.rpm vdsm-hook-macspoof-4.14.17-0.el6.noarch.rpm vdsm-python-4.14.17-0.el6.x86_64.rpm vdsm-python-zombiereaper-4.14.17-0.el6.noarch.rpm vdsm-xmlrpc-4.14.17-0.el6.noarch.rpm # ip route list table all |grep 192.168.126. 192.168.126.87 dev eth4 table 4 proto kernel scope link src 192.168.126.65 192.168.126.86 dev eth4 table 4 proto kernel scope link src 192.168.126.65 192.168.126.81 dev eth4 table 4 proto kernel scope link src 192.168.126.65 192.168.126.80 dev eth4 table 4 proto kernel scope link src 192.168.126.65 192.168.126.77 dev eth4 table 4 proto kernel scope link src 192.168.126.65 192.168.126.0/24 dev eth4 table 4 proto kernel scope link src 192.168.126.65 192.168.126.0/24 dev eth3 proto kernel scope link src 192.168.126.64 192.168.126.0/24 dev eth4 proto kernel scope link src 192.168.126.65 192.168.126.85 dev eth3 table 3 proto kernel scope link src 192.168.126.64 192.168.126.84 dev eth3 table 3 proto kernel scope link src 192.168.126.64 192.168.126.83 dev eth3 table 3 proto kernel scope link src 192.168.126.64 192.168.126.82 dev eth3 table 3 proto kernel scope link src 192.168.126.64 192.168.126.76 dev eth3 table 3 proto kernel scope link src 192.168.126.64 192.168.126.0/24 dev eth3 table 3 proto kernel scope link src 192.168.126.64 broadcast 192.168.126.0 dev eth3 table local proto kernel scope link src 192.168.126.64 broadcast 192.168.126.0 dev eth4 table local proto kernel scope link src 192.168.126.65 local 192.168.126.65 dev eth4 table local proto kernel scope host src 192.168.126.65 local 192.168.126.64 dev eth3 table local proto kernel scope host src 192.168.126.64 broadcast 192.168.126.255 dev eth3 table local proto kernel scope link src 192.168.126.64 broadcast 192.168.126.255 dev eth4 table local proto kernel scope link src 192.168.126.65 one HP ProLiant DL560 Gen8 host CPU: Intel(R) Xeon(R) CPU E5-4610 v2 @ 2.30GHz / Intel SandyBridge Family OS Version:RHEL - 6 - 6.el6.centos.12.2 Kernel Version: 2.6.32 - 504.16.2.el6.x86_64 KVM Version: 0.12.1.2 - 2.448.el6_6.2 LIBVIRT Version: libvirt-0.10.2-46.el6_6.6 VDSM Version: vdsm-4.16.14-0.el6 RAM: 256GB mom-0.4.3-1.el6.noarch.rpm ovirt-release35-002-1.noarch.rpm qemu-img-rhev-0.12.1.2-2.448.el6_6.2.x86_64.rpm qemu-kvm-rhev-0.12.1.2-2.448.el6_6.2.x86_64.rpm qemu-kvm-rhev-tools-0.12.1.2-2.448.el6_6.2.x86_64.rpm vdsm-4.16.14-0.el6.x86_64.rpm vdsm-cli-4.16.14-0.el6.noarch.rpm vdsm-hook-hostusb-4.16.14-0.el6.noarch.rpm vdsm-hook-macspoof-4.16.14-0.el6.noarch.rpm vdsm-jsonrpc-4.16.14-0.el6.noarch.rpm vdsm-python-4.16.14-0.el6.noarch.rpm vdsm-python-zombiereaper-4.16.14-0.el6.noarch.rpm vdsm-xmlrpc-4.16.14-0.el6.noarch.rpm vdsm-yajsonrpc-4.16.14-0.el6.noarch.rpm # ip route list table all |grep 192.168.126. 192.168.126.0/24 dev p6p1 proto kernel scope link src 192.168.126.34 192.168.126.0/24 dev p3p1 proto kernel scope link src 192.168.126.33 192.168.126.0/24 dev em3 proto kernel scope link src 192.168.126.32 local 192.168.126.32 dev em3 table local proto kernel scope host src 192.168.126.32 local 192.168.126.33 dev p3p1 table local proto kernel scope host src 192.168.126.33 broadcast 192.168.126.0 dev p6p1 table local proto kernel scope link src 192.168.126.34 broadcast 192.168.126.0 dev p3p1 table local proto kernel scope link src 192.168.126.33 broadcast 192.168.126.0 dev em3 table local proto kernel scope link src 192.168.126.32 local 192.168.126.34 dev p6p1 table local proto kernel scope host src 192.168.126.34 broadcast 192.168.126.255 dev p6p1 table local proto kernel scope link src 192.168.126.34 broadcast 192.168.126.255 dev p3p1 table local proto kernel scope link src 192.168.126.33 broadcast 192.168.126.255 dev em3 table local proto kernel scope link src 192.168.126.32

2 1