<div dir="ltr">Hi Arne,<div><br></div><div>We've had this EXACT same issue.</div><div><br></div><div>I don't know of a way to force an update as you are basically pulling the rug out from under a running instance. I don't know if it is possible/feasible to update the virsh xml in place and then migrate to get it to actually use that data. (I think we tried that to no avail.) dumpxml=>massage cephmons=>import xml</div><div><br></div><div>If you find a way, let me know, and that's part of the reason I'm replying so that I stay on this thread. NOTE: We did this on icehouse. Haven't tried since upgrading to Juno but I don't note any change therein that would mitigate this. So I'm guessing Liberty/post-Liberty for a real fix.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 6, 2015 at 12:57 PM, Arne Wiebalck <span dir="ltr"><<a href="mailto:arne.wiebalck@cern.ch" target="_blank">arne.wiebalck@cern.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
As we swapped a fraction of our Ceph mon servers between the pre-production and production cluster<br>
— something we considered to be transparent as the Ceph config points to the mon alias—, we ended<br>
up in a situation where VMs with volumes attached were not able to boot (with a probability that matched<br>
the fraction of the servers moved between the Ceph instances).<br>
<br>
We found that the reason for this is the connection_info in block_device_mapping which contains the<br>
IP adresses of the mon servers as extracted by the rbd driver in initialize_connection() at the moment<br>
when the connection is established. From what we see, however, this information is not updated as long<br>
as the connection exists, and will hence be re-applied without checking even when the XML is recreated.<br>
<br>
The idea to extract the mon servers by IP from the mon map was probably to get all mon servers (rather<br>
than only one from a load-balancer or an alias), but while our current scenario may be special, we will face<br>
a similar problem the day the Ceph mons need to be replaced. And that makes it a more general issue.<br>
<br>
For our current problem:<br>
Is there a user-transparent way to force an update of that connection information? (Apart from fiddling<br>
with the database entries, of course.)<br>
<br>
For the general issue:<br>
Would it be possible to simply use the information from the ceph.conf file directly (an alias in our case)<br>
throughout the whole stack to avoid hard-coding IPs that will be obsolete one day?<br>
<br>
Thanks!<br>
 Arne<br>
<br>
—<br>
<span class="HOEnZb"><font color="#888888">Arne Wiebalck<br>
CERN IT<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></span></blockquote></div><br></div>