Open Stack

Hi，

After delete all instance and recreate them, their fixed-ip and uuid
will change.
I don't think the way is good enough to end user.

If we can rebuild instance with same uuid and fixed-ip, etc to another
host will be good.

- Tian

于 2012年11月13日 17:02, Édouard Thuleau 写道:
> Hi Jānis,
>
> Yes, by deleted I mean clear all related VM entries in DB. I don't
> know how to do that for the moment.
>
> Édouard.
>
> On Mon, Nov 12, 2012 at 10:46 AM, Jānis Ģeņģeris
> <janis.gengeris at gmail.com> wrote:
>> Hi,
>>
>> What do you mean with deleting all servers? If the node is down, then all
>> the VM data is gone too, or you are talking about DB entries?
>>
>>
>> On Mon, Nov 12, 2012 at 11:08 AM, Édouard Thuleau <thuleau at gmail.com> wrote:
>>> I try to implement a simple way to automate the backup mechanism (eg.
>>> every day): https://blueprints.launchpad.net/nova/+spec/backup-schedule
>>>
>>> And I though of a solution to respond to your needs: when a node fails
>>> (for any reasons), I disable it, I delete all servers was running on
>>> it and I restart them from the last available backup.
>>>
>>> Édouard.
>>>
>>> On Fri, Nov 9, 2012 at 8:45 PM, Vishvananda Ishaya
>>> <vishvananda at gmail.com> wrote:
>>>> The libvirt driver has actually gotten quite good at rebuilding all of
>>>> the data for instances. This only thing it can't do right now is redownload
>>>> base images from glance. With current state if you simply back up the
>>>> instances directory (usually /var/lib/nova/instances) then you can recover
>>>> by bringing back the whole directory and doing a nova reboot <uuid> for each
>>>> instance.
>>>>
>>>> You could just stick the whole thing on an lvm and snaphot it regularly
>>>> for dr. The _base directory can be regenerated with images from glance so
>>>> you could also write a script to regenerate it and not have to worry about
>>>> backing it up. The code to add to nova to make it automatically re-download
>>>> the image from glance if it isn't there shouldn't be too bad either, which
>>>> would mean you could safely ignore the _base directory for backups.
>>>> Additionally using qcow images in glance and the config option
>>>> `force_raw_images=False` will keep this directory much smaller.
>>>>
>>>> Vish
>>>>
>>>>
>>>> On Nov 9, 2012, at 2:51 AM, Jānis Ģeņģeris <janis.gengeris at gmail.com>
>>>> wrote:
>>>>
>>>> Hello all,
>>>>
>>>> I would like to know the available solutions that are used regarding to
>>>> backing up and/or snapshotting running
>>>> instances on compute nodes. Documentation does not mention anything
>>>> related to this. With snapshots I don't mean
>>>> the current snapshot mechanism, that imports image of the running VM
>>>> into glance. I'm using KVM, but this is
>>>> significant for any hypervisor.
>>>>
>>>> Why is this important?
>>>> Consider simple scenario when hardware on compute node fails and the
>>>> node goes down immediately and is not recoverable
>>>> in reasonable time. The images of the running instances are also lost.
>>>> Shared file system is not considered here as it
>>>> may cause IO bottlenecks and adds another layer of complexity.
>>>>
>>>> There have been a few discussions on the the list about this problem,
>>>> but none have really answered the question.
>>>>
>>>> The documentation speaks of disaster recovery when power loss have
>>>> happened and failed compute node recovery from
>>>> shared file system. But don't cover the case without shared file system.
>>>>
>>>> I can think of few solutions currently (for KVM):
>>>> a) using LVM images for VMs, and making LVM logical volume snapshots,
>>>> but then the current nova snapshot mechanism
>>>> will not work (from the docs - 'current snapshot mechanism in OpenStack
>>>> Compute works only with instances backed
>>>> with Qcow2 images');
>>>> b) snapshot machines with OpenStack snapshotting mechanism, but this
>>>> doesn't fit somehow, because it has
>>>> other goal than creating backups, will be slow and pollute the glance
>>>> image space;
>>>>
>>>> Regards
>>>> --janis
>>>> _______________________________________________
>>>> 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
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>
>>
>>
>> --
>> --janis
> _______________________________________________
> 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


-- 
best regards,
gtt