[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

KVM Live Snapshots


Hi Asai,

In the context of CloudStack your metadata is effectively in the CloudStack DB. If you want to capture the point-in-time settings for the VMs in question you would simply do a "virsh dumpxml <domain>" against the VM and capture this data somehow. Keep in mind though it's not going to be particularly useful to you under CloudStack. If you ever needed to restore a VM you would do so by importing the volumes you backed up, create a template from the root volume, create a new VM from this and attach any imported data disks - and during this process CloudStack would build new metadata for you since you are effectively building a new VM.

Regards,
Dag Sonstebo
Cloud Architect
ShapeBlue

On 24/08/2018, 18:35, "Asai" <asai@xxxxxxxxxxxxxxxxxxxxx> wrote:

    Thanks, Dag.
    
    Then what do you do in case your VM metadata is lost?  With XenServer 
    you can export the VM as an XVA file.  Then re-import into XenCenter as 
    a whole VM.  Is there nothing so simple in KVM / Cloudstack?
    
    How do you keep your VM metadata and your disk in a recoverable package?
    
    Asai
    
    On 8/24/2018 1:58 AM, Dag Sonstebo wrote:
    > Sorry I should also have pointed out - the method outlined below is effectively the same as the steps carried out during a volume snapshot process - where the convert writes the snapshot to secondary storage.
    >
    > Regards,
    > Dag Sonstebo
    > Cloud Architect
    > ShapeBlue
    >
    > On 24/08/2018, 09:51, "Dag Sonstebo" <Dag.Sonstebo@xxxxxxxxxxxxx> wrote:
    >
    >      Hi Asai,
    >      
    >      To answer your previous question - VM snapshots are inline in the qcow2 image, i.e. contained in the disk itself, and you need to use qemu-img convert to write this to a separate file. The following should point you in the right direction:
    >      
    >      root@ref-trl-678-k-M7-dsonstebo-kvm2:~# virsh list
    >       Id    Name                           State
    >      ----------------------------------------------------
    >       1     s-1-VM                         running
    >       2     v-3-VM                         running
    >       4     i-2-4-VM                       running
    >      
    >      root@ref-trl-678-k-M7-dsonstebo-kvm2:~# virsh snapshot-list 4
    >       Name                 Creation Time             State
    >      ------------------------------------------------------------
    >       i-2-4-VM_VS_20180824084100 2018-08-24 08:34:00 +0000 running
    >      
    >      root@ref-trl-678-k-M7-dsonstebo-kvm2:~# virsh snapshot-info 4 --snapshotname  i-2-4-VM_VS_20180824084100
    >      Name:           i-2-4-VM_VS_20180824084100
    >      Domain:         i-2-4-VM
    >      Current:        yes
    >      State:          running
    >      Location:       internal
    >      Parent:         -
    >      Children:       0
    >      Descendants:    0
    >      Metadata:       yes
    >      
    >      ============
    >      
    >      In the db:
    >      
    >      > SELECT * FROM cloud.vm_snapshots
    >      
    >      ******************** 1. row *********************
    >                       id: 1
    >                     uuid: 4ad297d6-ea70-418c-9df3-bf9ccde3eb8c
    >                     name: i-2-4-VM_VS_20180824084100
    >             display_name: livesnap1
    >              description:
    >                    vm_id: 4
    >               account_id: 2
    >                domain_id: 1
    >      service_offering_id: 1
    >         vm_snapshot_type: DiskAndMemory
    >                    state: Ready
    >                   parent:
    >                  current: 1
    >             update_count: 2
    >                  updated: 2018-08-24 08:42:30
    >                  created: 2018-08-24 08:41:00
    >                  removed:
    >      
    >      
    >      ============
    >      
    >      To write the above inline snapshot to disk you would do something like this:
    >      
    >      qemu-img convert -f qcow2 -O qcow2 -s i-2-4-VM_VS_20180824084100 /mnt/pathtoqcow2fileforVM /tmp/mycopiedsnapshot.qcow2
    >      
    >      
    >      
    >      Regards,
    >      Dag Sonstebo
    >      Cloud Architect
    >      ShapeBlue
    >      
    >      On 24/08/2018, 02:13, "Ivan Kudryavtsev" <kudryavtsev_ia@xxxxxxxxx> wrote:
    >      
    >          Therea are API calls which enable creation of image snapshots from VM
    >          snapshot. I suppose it's the thing Simon is talking about. It doesn't help
    >          with full VM image backup (incl RAM) but it helps doing synchronous same
    >          timestamp backup across all VM volumes. Actually it's the result most
    >          persons require for backups.
    >          
    >          Also, take a look at:
    >          https://wiki.libvirt.org/page/Qemu_guest_agent
    >          It is a part of the strategy for proper backups.
    >          
    >          пт, 24 авг. 2018 г., 7:59 Asai <asai@xxxxxxxxxxxxxxxxxxxxx>:
    >          
    >          > This sounds like a great idea, except where can I find the VM snapshot in
    >          > the file system?  I’ve checked the database for some kind of indication,
    >          > and I’ve check primary and secondary storage to try to locate this snapshot
    >          > file but I can’t find it… Any insights on this?
    >          >
    >          > Thanks!
    >          >
    >          > Asai
    >          >
    >          >
    >          > > On Aug 23, 2018, at 2:25 PM, Simon Weller <sweller@xxxxxxx.INVALID>
    >          > wrote:
    >          > >
    >          > > There are lots of ways you can implement a Business Continuity or DR
    >          > plan.
    >          > >
    >          > > Some folks implement a second region or zone in a different market and
    >          > build their applications or services to be resilient across different data
    >          > centers (and/or markets). This often involved various forms of data
    >          > replication (DB, file et al).
    >          > >
    >          > > If you rely on secondary storage for backups, the assumption here is
    >          > that it uses a different storage system than your primary storage and it
    >          > can be used for recovery if your primary storage was to fail.
    >          > >
    >          > >
    >          > > Now since the VM snapshot feature can be called by API and the resulting
    >          > QCOW2 file is written to primary storage, you could use a script to execute
    >          > the snapshot and then copy off the QCOW2 files somewhere else.
    >          > >
    >          > > You could also use something like the Veeam agent -
    >          > https://www.veeam.com/windows-linux-availability-agents.html and backup
    >          > your VMs to an offsite NFS mount.
    >          > >
    >          > >
    >          > > - Si
    >          > >
    >          > >
    >          > >
    >          > >
    >          > > ________________________________
    >          > > From: Asai <asai@xxxxxxxxxxxxxxxxxxxxx>
    >          > > Sent: Thursday, August 23, 2018 4:06 PM
    >          > > To: users@xxxxxxxxxxxxxxxxxxxxx
    >          > > Subject: Re: KVM Live Snapshots
    >          > >
    >          > > So, I think this is kind of an elephant in the room.
    >          > >
    >          > > How do we get a standalone VM backup?  Or what is the best way to back
    >          > up Cloudstack?
    >          > >
    >          > > Right now we are making regular DB backups, and backing up secondary
    >          > storage (for volume snapshots).  But in case of disaster, how do we recover
    >          > this?
    >          > >
    >          > > Is there third party software available?
    >          > > Asai
    >          > >
    >          > >
    >          > >> On Aug 22, 2018, at 10:17 AM, Ivan Kudryavtsev <
    >          > kudryavtsev_ia@xxxxxxxxx> wrote:
    >          > >>
    >          > >> There is no way to run scheduled snapshots for whole vm, at least with
    >          > KVM.
    >          > >> I suppose the function is for adhoc only, especially as you may know
    >          > they
    >          > >> are not copied to secondary storage.
    >          > >>
    >          > >> чт, 23 авг. 2018 г., 0:10 Asai <asai@xxxxxxxxxxxxxxxxxxxxx>:
    >          > >>
    >          > >>> Great, thanks for that.
    >          > >>>
    >          > >>> So, is there a way then to make these whole VM snapshots recurring like
    >          > >>> recurring volume snapshots?
    >          > >>>
    >          > >>> What are best practices for recovering a volume snapshot?  e.g.
    >          > disaster
    >          > >>> recovery scenario?
    >          > >>>
    >          > >>> Asai
    >          > >>>
    >          > >>>
    >          > >>>
    >          > >>>
    >          > >
    >          >
    >          >
    >          
    >      
    >      
    >      Dag.Sonstebo@xxxxxxxxxxxxx
    >      www.shapeblue.com
    >      Amadeus House, Floral Street, London  WC2E 9DPUK
    >      @shapeblue
    >        
    >       
    >      
    >      
    >
    >
    > Dag.Sonstebo@xxxxxxxxxxxxx
    > www.shapeblue.com
    > Amadeus House, Floral Street, London  WC2E 9DPUK
    > @shapeblue
    >    
    >   
    >
    


Dag.Sonstebo@xxxxxxxxxxxxx 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue