Hi all,<br><br>some more information for further investigation on the "horrible behavior".<br><br>The phenomenon seems to be related to the concurrent access of the shared file system.<br><br>In fact, in my NFS deployment I noticed that problems started when a new VM was booted on a node different from the one where the already running VMs were booted (see the scheduling policy I briefly mentioned in my previous e-mail).<br>
<br>Let me describe what I experimented:<br><br>1) I launched Vm1 and it started to Node1<br>2) I launched Vm2 and it started to Node1<br><br>...<br><br>8) I launched Vm8 and it started to Node1<br><br><< at this point Node1 was full >><br>
<br>9) I launched Vm9 and it started to Node2<br><br><< at this point the cloud was stuck (I couldn't start new VMs and the already running VMs didn't perform properly) >><br><br>The only action I was able to do was to delete VMs.<br>
<br><br><br><br><br><br>Hope it helps,<br>Marco,<br><br><br><div class="gmail_quote">On Tue, Dec 11, 2012 at 5:54 PM, Marco CONSONNI <span dir="ltr"><<a href="mailto:mcocmo62@gmail.com" target="_blank">mcocmo62@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Andrew,<br><br>using NFS for live migration I found strange behaviors too.<br><br>To be more specific, I noted that at a certain point I couldn't boot any new VM. <br>
Live migration in itself was fine provided that I didn't reach a number of concurrent VMs; the problem was that after a number of VMs (in my case 8) the cloud stopped working. I could do much but stopping VMs.<br>
In my case I set up the scheduling in a way that all the VMs were 'dispatched' to a compute node till such a node was 'full'.<br><br>At the end I decided not to use it and use gluster, instead.<br><br>I followed the instructions reported here <a href="http://gluster.org/community/documentation//index.php/OSConnect" target="_blank">http://gluster.org/community/documentation//index.php/OSConnect</a> with some modifications for having a single node running as a gluster server and all the compute nodes running as gluster clients.<br>
Something similar to what you deploy when you use NFS.<br>Note that my deployment is not going to be a production installation, therefore a single gluster file server is OK.<br><br>Also note that I started my installation using Ubuntu 12.04 but the migration didn't work properly for problems in the hypervisor,<br>
With 12.10 everything worked properly.<br><br>Hope it helps,<br>Marco.<div class="HOEnZb"><div class="h5"><br><br><br><br><br><br>On Tue, Dec 11, 2012 at 5:33 PM, Andrew Holway <span dir="ltr"><<a href="mailto:a.holway@syseleven.de" target="_blank">a.holway@syseleven.de</a>></span> wrote:<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
I tried this today:<br>
<br>
<a href="http://docs.openstack.org/trunk/openstack-compute/admin/content/configuring-migrations.html" target="_blank">http://docs.openstack.org/trunk/openstack-compute/admin/content/configuring-migrations.html</a><br>
<br>
Everything seemed to break really horribly.<br>
<br>
Is this documentation up to date? I am going to completely reinstall tomorrow.<br>
<br>
I am using Centos 6.3<br>
<br>
Thanks,<br>
<br>
Andrew<br>
<br>
_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to : <a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
</blockquote></div><br>
</div></div></blockquote></div><br>