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" <a...@globalchangemusic.org> wrote: Thanks, Dag.Then what do you do in case your VM metadata is lost? With XenServeryou 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.sonst...@shapeblue.com> 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...@bw-sw.com> 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 <a...@globalchangemusic.org>: > > > 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 <swel...@ena.com.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 <a...@globalchangemusic.org> > > > Sent: Thursday, August 23, 2018 4:06 PM > > > To: users@cloudstack.apache.org > > > 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...@bw-sw.com> 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 <a...@globalchangemusic.org>: > > >> > > >>> 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.sonst...@shapeblue.com > www.shapeblue.com > Amadeus House, Floral Street, London WC2E 9DPUK > @shapeblue > > > > > > > dag.sonst...@shapeblue.com > www.shapeblue.com > Amadeus House, Floral Street, London WC2E 9DPUK > @shapeblue > > >dag.sonst...@shapeblue.com www.shapeblue.com Amadeus House, Floral Street, London WC2E 9DPUK @shapeblue
