[Openstack-operators] Starting large VMs takes quite long

Boris-Michel Deschenes boris-michel.deschenes at ubisoft.com
Thu Oct 20 13:47:02 UTC 2011

Hi guys,

Just a quick note, I had this setup at some point (NFS-mounted /var/lib/nova/instances) which is essential to get live VM migrations if I'm not mistaken (live migration was working perfectly).  The problem I had with this setup was that the VM startup time was considerably slower than when the images were residing on a local disk (and I mean, even after all images are "cached").

Basically an image will start the fastest when it is cached locally (local drive)
Then, not quite as fast when cached but on a NFS-mounted directory
Then really slowly when residing entirely on another disk and needed to be written locally to be cached

These are the observations I made but I realize other factors weigh in (SAS vs SATA disk, network speed, etc.)  Please advise if you get the same speed in NFS-cached vs local-cached setup as it might convince me to go back to an NFS share (also were you using SAS disks to serve the NFS?).


De : openstack-operators-bounces at lists.openstack.org [mailto:openstack-operators-bounces at lists.openstack.org] De la part de Diego Parrilla
Envoyé : 20 octobre 2011 04:54
À : Till Mossakowski
Cc : openstack-operators at lists.openstack.org
Objet : Re: [Openstack-operators] Starting large VMs takes quite long


my answers below.

On Wed, Oct 19, 2011 at 8:12 PM, Till Mossakowski <Till.Mossakowski at dfki.de<mailto:Till.Mossakowski at dfki.de>> wrote:
my answers below,

many thanks for your quick answer.

   I have set up openstack using stackops.

Good choice ;-)

Yes, the stackops GUI is very nice. However, stackops is based on cactus, right? Is there a way of using diablo with stackops? Perhaps it is possible to upgrade the Ubuntu lucid distro that is coming with stackops to natty or oneiric and then upgrade to diablo using the source ppa:openstack-release/2011.3 for openstack?

Yes, the 0.3 version with Diablo release is coming. We detected some QA issues. But things are working much better now.

5GB image it's not too big... we use NFS to share instances among nodes
to help with the live migration and performance it's acceptable. How
much is 'quite a while' in seconds?

between half a minute and a minute (I haven't taken the exact time...).
This is too long for our users.

If the virtual disks are cached, launching a 40GB virtual machine takes less than 5 seconds in our test platform (IBM x3550M3 Dual Xeon 5620 64GB with NFS as shared storage on 1Gb)

If you share the /var/lib/nova/instances with NFS, during the 'launch'
process the base virtual image is copied to '_base'. Depending on the
size of this file it will take longer. Once it's copied next time you
use this image it should go much faster.

Note: I have tested right now with a 1Gb launching a >25GB Windows VM
and it took 3-4 minutes the first time. New Windows images, it took only
a few seconds.

This is interesting. Is there a way of telling the scheduler to prefer a compute node that already has copied the needed image?

Try this:

1) Configure the compute nodes to use a shared directory with NFS on /var/lib/nova/instances
2) Launch ALL the virtual disks you need at runtime. It will take a while the first time.
3) Virtual disks are now cached in /var/lib/nova/instances/_base
4) Try to launch now the virtual disks again. They should start very fast.

If you need some kind of assistance, please let me know.


Best, Till

Prof. Dr. Till Mossakowski  Cartesium, room 2.51 Phone +49-421-218-64226<tel:%2B49-421-218-64226>
DFKI GmbH Bremen                             Fax +49-421-218-9864226<tel:%2B49-421-218-9864226>
Safe & Secure Cognitive Systems             Till.Mossakowski at dfki.de<mailto:Till.Mossakowski at dfki.de>
Enrique-Schmidt-Str. 5, D-28359 Bremen   http://www.dfki.de/sks/till

Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
principal office, *not* the address for mail etc.!!!:
Trippstadter Str. 122, D-67663 Kaiserslautern
management board: Prof. Wolfgang Wahlster (chair), Dr. Walter Olthoff
supervisory board: Prof. Hans A. Aukes (chair)
Amtsgericht Kaiserslautern, HRB 2313

Diego Parrilla
www.stackops.com<http://www.stackops.com/> |  diego.parrilla at stackops.com<mailto:diego.parrilla at stackops.com> | +34 649 94 43 29 | skype:diegoparrilla


******************** ADVERTENCIA LEGAL ********************
Le informamos, como destinatario de este mensaje, que el correo electrónico y las comunicaciones por medio de Internet no permiten asegurar ni garantizar la confidencialidad de los mensajes transmitidos, así como tampoco su integridad o su correcta recepción, por lo que STACKOPS TECHNOLOGIES S.L. no asume responsabilidad alguna por tales circunstancias. Si no consintiese en la utilización del correo electrónico o de las comunicaciones vía Internet le rogamos nos lo comunique y ponga en nuestro conocimiento de manera inmediata. Este mensaje va dirigido, de manera exclusiva, a su destinatario y contiene información confidencial y sujeta al secreto profesional, cuya divulgación no está permitida por la ley. En caso de haber recibido este mensaje por error, le rogamos que, de forma inmediata, nos lo comunique mediante correo electrónico remitido a nuestra atención y proceda a su eliminación, así como a la de cualquier documento adjunto al mismo. Asimismo, le comunicamos que la distribución, copia o utilización de este mensaje, o de cualquier documento adjunto al mismo, cualquiera que fuera su finalidad, están prohibidas por la ley.

***************** PRIVILEGED AND CONFIDENTIAL ****************
We hereby inform you, as addressee of this message, that e-mail and Internet do not guarantee the confidentiality, nor the completeness or proper reception of the messages sent and, thus, STACKOPS TECHNOLOGIES S.L. does not assume any liability for those circumstances. Should you not agree to the use of e-mail or to communications via Internet, you are kindly requested to notify us immediately. This message is intended exclusively for the person to whom it is addressed and contains privileged and confidential information protected from disclosure by law. If you are not the addressee indicated in this message, you should immediately delete it and any attachments and notify the sender by reply e-mail. In such case, you are hereby notified that any dissemination, distribution, copying or use of this message or any attachments, for any purpose, is strictly prohibited by law.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20111020/818be58b/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ~WRD000.jpg
Type: image/jpeg
Size: 823 bytes
Desc: ~WRD000.jpg
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20111020/818be58b/attachment-0002.jpg>

More information about the Openstack-operators mailing list