Adding mailing list.
>
>
> From: Antoine Boucher <antoi...@haltondc.com>
> Subject: Re: Lost of a KVM host with VMs on Local storage
> Date: September 28, 2022 at 1:30:30 PM EDT
> To: Nux <n...@li.nux.ro>
>
> Hi Nux,
>
> Thank you for your response. The template path would be acceptable. As for
> messing with the db it should not be a problem once I understand the
> structure, It would be great to have a UI option to force the clean-up
> volumes in such conditions. I have at least 3 in destroy state that I need
> to manually clean-up.
>
> Thanks for your help.
>
> -Antoine
>
>
>> On Sep 28, 2022, at 11:32 AM, Nux <n...@li.nux.ro <mailto:n...@li.nux.ro>>
>> wrote:
>>
>> Hi,
>>
>> Ideally you would have a full baremetal backup of the hypervisor if using
>> local storage.
>> If that is not a possibility, then you could convert the volume snapshot of
>> the VM into a template and deploy it on the desired hypervisor.
>>
>> You will not be able to "revert to snapshot" if your hypervisor is
>> completely gone, as you have noticed, in the DB there are references to both
>> hypervisor and storage pool that would need messing with.
>>
>> ---
>> Nux
>> www.nux.ro <http://www.nux.ro/>
>>
>> On 2022-09-28 15:43, Antoine Boucher wrote:
>>> Hello,
>>> We have a few high iops VMs running on local storage on some of our
>>> KVM hosts. We backup (snapshots) these VMs on a regular basis on
>>> secondary storage.
>>> In the event of a compete KVM host failure.
>>> What would be the best practice to clean-up and restart the VMs from
>>> backups to a new host.
>>> Would it just be a simple restore from the snapshot to the new host
>>> and the MS will fix the corresponding references to the dead VM and
>>> volume object? I remember having to delete records in the MS db to
>>> remove the volume reference when a host was removed before removing
>>> its local volume from the GUI.
>>> Regards,
>>> Antoine
>