Open Stack

Ignoring issues of Ram . I have a number of questions as the following model:

My node-1's resource as the following:

    CPU : 4 core
    RAM: 4 GB.

Now , My Node-1 is hosting 4 instances:

    3 instance: (each VM: 1 core CPU, 2 GB ram,..).
    2 instance(i-00000001, i-00000002) is turn of and 1 instance(i-00000003) is
    running.
    1 instance : (1 core CPU, 1 GB ram).
    It is running.(i-00000004)

I request new ínstance by the euca-run-instance command. My new instance (
i-00000005) is located on the node 1. This is the problem for the
nova-scheduler.

What is happen ? If I reboot 2 instances : i-00000001,i-00000002.

How do we manage this problem in Openstack ?

I think that: My 2 instances (i-00000001 , i-00000002) should be migrated to the
rest available resources as node-2 and node-3.

If not, it's actually very difficult to manage and reboot the instances which
are turned off. And their resources-allocated will be reused for the new
instances.

----- Thông điệp gốc : ----- 

Gửi từ : Vishvananda Ishaya [vishvananda at gmail.com]

Gửi lúc : 12/04/2012 11:43 PM

Gửi tới : openstack at lists.launchpad.net;vishvananda at gmail.com

Chủ đỠ: Re: [Openstack] The Scheduling feature when reboot the
instance

 

No this does not exist. If you are going to overprovision ram, you should
probably make sure that you have swap enabled on your host. 


Vish


On Apr 12, 2012, at 4:10 AM, Văn Äình Phúc wrote:


 

    Hi.

    I'm using Openstack (2011.3
    (2011.3-nova-milestone-tarball:tarmac-20110922115702-k9nkvxqzhj130av2) with
    3 Compute nodes.

    My scheduling option is default.

    I have the problem as the following steps:

        Compute node 1 is installed the modules: nova-api, nova-compute and
        nova-network.
        The resource of node-1 max is fitfor 3 instances (m1.small): i-00000001,
        i-00000002, i-00000003.
        I turn off i-00000001.
        and then I request new ínstance by the euca-run-instance command , My
        new instance ( i-00000004) is located on the node 1.
        The resources: RAM , CPU,.. of node-2 and node-3 is available.
        finally, I reboot the i-00000001.What is happen? the i-00000001 is
        rebooted on the node-1 , and It's shutdown off after reboot.I checked
        the libvirt's log :

        "Failed to allocate 2147483648 B: Cannot allocate memory
        2012-04-12 16:11:50.530: shutting down"

    So , Do Openstack have the sheduling feature when rebooting the instance ?

    Example: As above , My instance (i-00000001) will be migrated to node-2 or
    node-3 when the resource of node-1 is not available.

    <phucvdbmail.gif>

     

    

     

    Văn Äình Phúc
    Manager - Cloud Team

    Techno Department

    Bkav Specialization Division

    

    Office: Bkav Building - Yen Hoa New Town, Cau Giay Dist, Hanoi

    Tel: (84-4) 3763.2552

    Mobile: 0169 4702 388

    ____________________________________________

    Do your best, the rest will come !

    Hãy là m việc hết mình, những Ä‘iá»u tốt
    đẹp sẽ đến với bạn !

    

    Disclaimer: This e-mail and any files transmitted with it are confidential
    and may contain privileged information. It is intended solely for the use of
    the individual to whom it is addressed and others authorized to receive it.
    If you are not the intended recipient you are notified that disclosing,
    copying, distributing or taking any action in reliance on the contents of
    this information is strictly prohibited. If you have received this message
    in error, please notify the sender immediately by reply e-mail and delete
    completely this e-mail from your system, without reproducing, distributing
    or retaining copies.

    

    _______________________________________________
    Mailing list: https://launchpad.net/~openstack
    Post to : openstack at lists.launchpad.net
    Unsubscribe : https://launchpad.net/~openstack
    More help : https://help.launchpad.net/ListHelp


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120413/7de53eb6/attachment.html>