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
> 

Reply via email to