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 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.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
