Open Stack

As a stop gap for the IP problem, keep in mind that you can create a
neutron port separately and boot the instance to it. Then when you delete
the instance the port will remain and hold onto the IP so you can boot to
it with a different instance later.

On Jul 5, 2017 18:31, "Eddie Yen" <missile0407 at gmail.com> wrote:

> Hi, thanks for reply first!
>
> After I tried shelve instance, yes it really release GPU resources.
> But as Dinesh said, can't unshelve this instance if all GPUs occupied.
>
> Before known about shelve instance, I have do few approach.
>
> One is using "resize" the instance's flavor to non-GPU flavor, but can't
> do this if all GPUs occupied.
>
> Another one is like Jay's recommend is that create instance as volume, and
> delete instance but keep volume if this VM not going to use GPU.
> Then re-create instance with previous volume and non-GPU flavor.
> And yes, this approach have IP address problem that may cause application
> atypical.
>
> I'll try how to make my application not to rely on a persistent IP.
>
> Thanks,
> Eddie.
>
> 2017-07-05 19:36 GMT+08:00 Jay Pipes <jaypipes at gmail.com>:
>
>> On 07/05/2017 04:18 AM, Eddie Yen wrote:
>>
>>> Hi everyone,
>>>
>>> I'm using OpenStack Mitaka (which deployed from Fuel 9.2) and doing GPU
>>> things.
>>>
>>> I got a problem is I need to delete current instance which contains GPU
>>> to release device if I want assign GPU to another new instance temperately.
>>>
>>> I'll got "No valid host was found" if I creating new instance contains
>>> GPU flavor without delete present instance, even the instance is shutdown.
>>>
>>> Is there any way that I just shutdown the instance rather than delete it
>>> to release GPU device?
>>>
>>
>> As Dinesh mentioned you *can* use shelve for this, but frankly, I think
>> the shelve API leads to more problems than it solves (see his response
>> about needing to delete the new instance before unshelving).
>>
>> I'd recommend redesigning your application to be more cloud-native. In
>> other words, separate operating system state from application state, use
>> volumes for all persistent application state, and do not rely on a
>> persistent IP address. [1]
>>
>> Once you've done that, you can just treat your VMs like cattle and
>> terminate them.
>>
>> Best,
>> -jay
>>
>> [1] Please note I did not use the word "container" in this description of
>> cloud-native application.
>>
>> _______________________________________________
>> Mailing list: http://lists.openstack.org/cgi
>> -bin/mailman/listinfo/openstack
>> Post to     : openstack at lists.openstack.org
>> Unsubscribe : http://lists.openstack.org/cgi
>> -bin/mailman/listinfo/openstack
>>
>
>
> _______________________________________________
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20170705/ee56be89/attachment.html>