<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Eugen,<div class="">thanks for your help</div><div class="">We have 3 servers (s1, s2 , s3) and an iscsi bay attached on s3.</div><div class=""><font color="#e32400" class="">Multinode: </font></div><div class=""><div class=""><font color="#e32400" class="">[control]</font></div><div class=""><font color="#e32400" class="">s1</font></div><div class=""><font color="#e32400" class="">s2</font></div><div class=""><font color="#e32400" class=""><br class=""></font></div><div class=""><div class=""><font color="#e32400" class="">[compute]</font></div><div class=""><font color="#e32400" class="">s1</font></div></div><div class=""><font color="#e32400" class="">s2</font></div><div class=""><font color="#e32400" class="">s3</font></div><div class=""><font color="#e32400" class=""><br class=""></font></div><div class=""><div class=""><font color="#e32400" class="">[storage]</font></div><div class=""><font color="#e32400" class="">s3</font></div></div><div class=""><br class=""></div><div class="">on s1: more /etc/kolla/globals.yml</div><div class="">...</div><div class=""><div class=""><font color="#4d22b3" class="">enable_cinder: "yes"</font></div><div class=""><font color="#4d22b3" class="">enable_cinder_backend_iscsi: "yes"</font></div><div class=""><font color="#4d22b3" class="">enable_cinder_backend_lvm: « yes"</font></div></div><div class=""><font color="#4d22b3" class="">enable_iscsid: « yes"</font></div><div class=""><font color="#4d22b3" class="">cinder_volume_group: "cinder-volumes »</font></div><div class=""><font color="#4d22b3" class="">...</font></div><div class=""><div class=""><font color="#4d22b3" class="">enable_glance_image_cache: "yes"</font></div><div class=""><font color="#4d22b3" class="">glance_cache_max_size: "21474836480"</font></div><div class=""><font color="#4d22b3" class="">glance_file_datadir_volume: « /images/<span style="caret-color: rgb(77, 34, 179);" class="">« </span></font></div></div><div class=""><font color="#4d22b3" class="">...</font></div><div class=""><br class=""></div><div class="">on s3:  /images is on the iscsi bay </div><div class=""><font color="#ff4013" class="">mount |grep images</font></div><div class="">/dev/mapper/VG--IMAGES-LV--IMAGES on <b class="">/images</b> type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,sunit=1024,swidth=1024,noquota)</div><div class=""><br class=""></div><div class=""><font color="#e32400" class="">lsblk</font></div><div class=""><div class="">sdf                                                                             8:80   0   500G  0 disk</div><div class="">└─mpathc                                                                      253:3    0   500G  0 mpath</div><div class="">  └─mpathc1                                                                   253:4    0   500G  0 part</div><div class="">    └─VG--IMAGES-LV--IMAGES                                                   253:5    0   500G  0 lvm   /images</div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><font color="#e32400" class="">ls -l /images:</font></div><div class=""><div class="">drwxr-x---. 5 42415 42415 4096  6 févr. 18:40 image-cache</div><div class="">drwxr-x---. 2 42415 42415 4096  4 févr. 15:16 images</div><div class="">drwxr-x---. 2 42415 42415    6 22 nov.  12:03 staging</div><div class="">drwxr-x---. 2 42415 42415    6 22 nov.  12:03 tasks_work_dir</div></div><div class=""><br class=""></div><div class=""><font color="#e32400" class="">ls -l /images/image-cache</font></div><div class=""><div class="">total 71646760</div><div class="">-rw-r-----. 1 42415 42415   360841216  2 déc.  11:52 3e3aada8-7610-4c55-b116-a12db68f8ea4</div><div class="">-rw-r-----. 1 42415 42415   237436928 28 nov.  16:56 6419642b-fcbd-4e5d-9c77-46a48d2af93f</div><div class="">-rw-r-----. 1 42415 42415 10975379456 26 nov.  14:59 7490e914-8001-4d56-baea-fabf80f425e1</div><div class="">-rw-r-----. 1 42415 42415 21474836480 22 nov.  16:46 7fc7f9a6-ab0e-45cf-9c29-7e59f6aa68a5</div><div class="">-rw-r-----. 1 42415 42415  2694512640 15 déc.  18:07 890fd2e8-2fac-42c6-956b-6b10f2253a56</div><div class="">-rw-r-----. 1 42415 42415 12048400384  1 déc.  17:04 9a235763-ff0c-40fd-9a8d-7cdca3d3e9ce</div><div class="">-rw-r-----. 1 42415 42415  5949227008 15 déc.  20:41 9cbba37b-1de1-482a-87f2-631d2143cd46</div><div class="">-rw-r-----. 1 42415 42415   566994944  6 déc.  12:32 b6e29dd9-a66d-4569-a222-6fc0bd9b1b11</div><div class="">-rw-r-----. 1 42415 42415   578748416  2 déc.  11:24 c40953ee-4b39-43a5-8f6c-b48a046c38e9</div><div class="">-rw-r-----. 1 42415 42415    16300544 27 janv. 12:19 c88630c7-a7c6-44ff-bfa0-e5af4b1720e3</div><div class="">-rw-r-----. 1 42415 42415       12288  6 févr. 18:40 cache.db</div><div class="">-rw-r-----. 1 42415 42415 12324503552  1 déc.  07:50 e0d4fddd-5aa7-4177-a1d6-e6b4c56f12e8</div><div class="">-rw-r-----. 1 42415 42415  6139084800 22 nov.  15:05 eda93204-9846-4216-a6e8-c29977fdcf2f</div><div class="">-rw-r-----. 1 42415 42415           0 22 nov.  12:03 image_cache_db_init</div><div class="">drwxr-x---. 2 42415 42415           6 27 janv. 12:19 incomplete</div><div class="">drwxr-x---. 2 42415 42415           6 22 nov.  12:03 invalid</div><div class="">drwxr-x---. 2 42415 42415           6 22 nov.  12:03 queue</div></div><div class=""><br class=""></div><div class="">on s1</div><div class=""><font color="#e32400" class="">openstack image list</font></div><div class=""><div class="">+--------------------------------------+-----------------------------+--------+</div><div class="">| ID                                   | Name                        | Status |</div><div class="">+--------------------------------------+-----------------------------+--------+</div><div class="">…..</div><div class="">| 7fc7f9a6-ab0e-45cf-9c29-7e59f6aa68a5 | rocky8.4                    | active |</div><div class="">….</div><div class="">| 7490e914-8001-4d56-baea-fabf80f425e1 | win10_2104                  | active |</div><div class="">….</div><div class="">+———————————————————+-----------------------------+————+</div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">openstack image show 7fc7f9a6-ab0e-45cf-9c29-7e59f6aa68a5</div><div class="">disk_format      | raw</div><div class=""><br class=""></div><div class="">when I try to add an instance from this image (2G RAM, 40G HDD): </div><div class="">[Error : Build of instance baa06bef-9628-407f-8bae-500ef7bce065 aborted:
 Volume be0f28eb-1045-4687-8bdb-5a6d385be6fa did not finish being 
created even after we waited 187 seconds or 61 attempts. And its status 
is downloading.</div><div class=""><br class=""></div><div class="">it’s impossible. I need to add the volume from image first, and after add instance from volume.</div><div class=""><br class=""></div><div class="">Is it normal ? </div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">
<meta charset="UTF-8" class=""><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div><span style="color: rgb(31, 73, 125); font-family: Arial, sans-serif; font-size: 10pt; orphans: 2; widows: 2;" class="">Franck </span></div><div><span style="color: rgb(31, 73, 125); font-family: Arial, sans-serif; font-size: 10pt; orphans: 2; widows: 2;" class=""><br class=""></span></div></div></div></div></div></div><div><blockquote type="cite" class=""><div class="">Le 7 févr. 2022 à 10:55, Eugen Block <<a href="mailto:eblock@nde.ag" class="">eblock@nde.ag</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi Franck,<br class=""><br class="">although it's a different topic than your original question I wanted to comment on the volume creation time (maybe a new thread would make sense). What is your storage back end? If it is ceph, are your images in raw format? Otherwise cinder has to download the image from glance (to /var/lib/cinder/conversion) and convert it, then upload it back to ceph. It's similar with nova, nova stores base images in /var/lib/nova/instances/_base to prevent the compute nodes from downloading it every time. This may save some time for the download, but the upload has to happen anyway. And if you don't use shared storage for nova (e.g. for live-migration) you may encounter that some compute nodes are quicker creating an instance because they only have to upload, others will first have to download, convert and then upload it.<br class=""><br class="">You would see the conversion in the logs of cinder:<br class=""><br class="">INFO cinder.image.image_utils [req-f2062570-4006-464b-a1f5-d0d5ac34670d d71f59600f1c40c394022738d4864915 31b9b4900a4d4bdaabaf263d0b4021be - - -] Converted 2252.00 MB image at 757.52 MB/s<br class=""><br class="">Hope this helps.<br class=""><br class="">Eugen<br class=""><br class=""><br class="">Zitat von Franck VEDEL <<a href="mailto:franck.vedel@univ-grenoble-alpes.fr" class="">franck.vedel@univ-grenoble-alpes.fr</a>>:<br class=""><br class=""><blockquote type="cite" class="">Sunday morning: my openstack works…. OUF.<br class="">the "kolla-ansible -i multimode mariadb_recovery"  command (which is magic anyway) fixed the problem and then the mariadb and nova containers started.<br class="">Once solved the problems between my serv3 and the iscsi bay, restart the container glance, everything seems to work.<br class=""><br class=""><blockquote type="cite" class="">4 minutes to create a 20GB empty volume seems too long to me. For an actual 20GB image, it's going to depend on the speed of the backing storage tech.<br class=""></blockquote>4 minutes is for a volume from an image. I will see this problem next summer , I will retry to change the MTU value.<br class=""><br class="">Thanks a lot, really<br class=""><br class=""><br class="">Franck<br class=""><br class=""><blockquote type="cite" class="">Le 5 févr. 2022 à 17:08, Laurent Dumont <<a href="mailto:laurentfdumont@gmail.com" class="">laurentfdumont@gmail.com</a>> a écrit :<br class=""><br class="">Any chance to revert back switches + server? That would indicate that MTU was the issue.<br class="">Dont ping the iscsi bay, ping between the controllers in Openstack, they are the ones running mariadb/galera.<br class="">Since the icmp packets are small, it might not trigger the MTU issues. Can you try something like "ping -s 8972 -M do -c 4 $mariadb_host_2" from $ mariadb_host_1?<br class="">What is your network setup on the servers? Two ports in a bond? Did you change both physical interface MTU + bond interface itself?<br class=""><br class="">4 minutes to create a 20GB empty volume seems too long to me. For an actual 20GB image, it's going to depend on the speed of the backing storage tech.<br class=""><br class="">On Sat, Feb 5, 2022 at 1:51 AM Franck VEDEL <<a href="mailto:franck.vedel@univ-grenoble-alpes.fr" class="">franck.vedel@univ-grenoble-alpes.fr</a> <<a href="mailto:franck.vedel@univ-grenoble-alpes.fr" class="">mailto:franck.vedel@univ-grenoble-alpes.fr</a>>> wrote:<br class="">Thanks for your help.<br class=""><br class=""><br class=""><blockquote type="cite" class="">What was the starting value for MTU?<br class=""></blockquote>1500<br class=""><blockquote type="cite" class="">What was the starting value changed to for MTU?<br class=""></blockquote>9000<br class=""><blockquote type="cite" class="">Can ping between all your controllers?<br class=""></blockquote>yes, all container starts except nova-conductor, nova-scheduler, maraidb<br class=""><br class=""><br class=""><blockquote type="cite" class="">Do you just have two controllers running mariadb?<br class=""></blockquote>yes<br class=""><blockquote type="cite" class="">How did you change MTU?<br class=""></blockquote><br class="">On the 3 servers:<br class="">nmcli connection modify team0-port1 802-3-ethernet.mtu 9000<br class="">nmcli connection modify team1-port2 802-3-ethernet.mtu 9000<br class="">nmcli connection modify type team0 team.runner lack ethernet.mtu 9000<br class="">nmcli con down team0<br class="">nmcli con down team1<br class=""><br class=""><br class=""><blockquote type="cite" class="">Was the change reverted at the network level as well (switches need to be configured higher or at the same MTU value then the servers)<br class=""></blockquote>I didn’t change Mtu on network (switches) , but ping -s 10.0.5.117 (iscsi bay) was working from serv3.<br class=""><br class="">I changed the value of the mtu because the creation of the volumes takes a lot of time I find (4 minutes for 20G, which is too long for what I want to do, the patience of the students decreases with the years)<br class=""><br class="">Franck<br class=""><br class=""><blockquote type="cite" class="">Le 4 févr. 2022 à 23:12, Laurent Dumont <<a href="mailto:laurentfdumont@gmail.com" class="">laurentfdumont@gmail.com</a> <<a href="mailto:laurentfdumont@gmail.com" class="">mailto:laurentfdumont@gmail.com</a>>> a écrit :<br class=""><br class="">What was the starting value for MTU?<br class="">What was the starting value changed to for MTU?<br class="">Can ping between all your controllers?<br class="">Do you just have two controllers running mariadb?<br class="">How did you change MTU?<br class="">Was the change reverted at the network level as well (switches need to be configured higher or at the same MTU value then the servers)<br class="">4567 seems to be the port for galera (clustering for mariadb) <><br class="">On Fri, Feb 4, 2022 at 11:52 AM Franck VEDEL <<a href="mailto:franck.vedel@univ-grenoble-alpes.fr" class="">franck.vedel@univ-grenoble-alpes.fr</a> <<a href="mailto:franck.vedel@univ-grenoble-alpes.fr" class="">mailto:franck.vedel@univ-grenoble-alpes.fr</a>>> wrote:<br class="">Hello,<br class="">I am in an emergency situation, quite catastrophic situation because I do not know what to do.<br class=""><br class="">I have an Openstack cluster with 3 servers (serv1, serv2, serv3). He was doing so well…<br class=""><br class=""><br class="">A network admin came to me and told me to change an MTU on the cards. I knew it shouldn't be done...I shouldn't have done it.<br class="">I did it.<br class="">Of course, it didn't work as expected. I went back to my starting configuration and there I have a big problem with mariadb which is set up on serv1 and serv2.<br class=""><br class="">Here are my errors:<br class=""><br class=""><br class="">2022-02-04 17:40:36 0 [ERROR] WSREP: failed to open gcomm backend connection: 110: failed to reach primary view: 110 (Connection timed out)<br class=""><span class="Apple-tab-span" style="white-space:pre">    </span> at gcomm/src/pc.cpp:connect():160<br class="">2022-02-04 17:40:36 0 [ERROR] WSREP: gcs/src/gcs_core.cpp:gcs_core_open():209: Failed to open backend connection: -110 (Connection timed out)<br class="">2022-02-04 17:40:36 0 [ERROR] WSREP: gcs/src/gcs.cpp:gcs_open():1475: Failed to open channel 'openstack' at '<a href="gcomm://10.0.5.109:4567,10.0.5.110:4567':" class="">gcomm://10.0.5.109:4567,10.0.5.110:4567':</a> <> -110 (Connection timed out)<br class="">2022-02-04 17:40:36 0 [ERROR] WSREP: gcs connect failed: Connection timed out<br class="">2022-02-04 17:40:36 0 [ERROR] WSREP: wsrep::connect(<a href="gcomm://10.0.5.109:4567,10.0.5.110:4567" class="">gcomm://10.0.5.109:4567,10.0.5.110:4567</a> <>) failed: 7<br class="">2022-02-04 17:40:36 0 [ERROR] Aborting<br class=""><br class=""><br class=""><br class=""><br class="">I do not know what to do. My installation is done with kolla-ansible, mariadb docker restarts every 30 seconds.<br class=""><br class="">Can the "kolla-ansible reconfigure mariadb" command be a solution?<br class="">Could the command "kolla-ansible mariadb recovery" be a solution?<br class=""><br class="">Thanks in advance if you can help me.<br class=""><br class=""><br class=""><br class="">Franck<br class=""><br class=""><br class=""></blockquote><br class=""></blockquote></blockquote><br class=""><br class=""><br class=""><br class=""></div></div></blockquote></div><br class=""></div></body></html>