OSDir


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

Re: KVM Live Snapshots


OK, thanks, Dag.

I think I finally get it.

On 8/27/2018 2:47 AM, Dag Sonstebo wrote:
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