Re: lvm: creating a snapshot
Hi
On Fri, Oct 03, 2014 at 08:43:06PM +0200, lee wrote:
> Hi,
>
> how can I create a LVM snapshot of a VM?
>
>
> root@heimdall:~# lvcreate -L 4G -s /dev/mapper/vg_guests-lv_jarl -n lv_snap_jarl /dev/mapper/vg_mydata
> Physical Volume "/dev/mapper/vg_mydata" not found in Volume Group "vg_guests"
> root@heimdall:~#
>
>
> There is no free space in 'vg_guests'. The only free space is in
> 'vg_mydata'.
That's a problem. Snapshots must be in the same volume group - they
are essentially copy-on-write (sort-of).
> Can I create a snapshot over the network on disks an another
> machine?
No
> Can I extend 'vg_guests', using the free space of 'vg_mydata'?
Not directly. But you *can* merge the two volume groups - but that
requires all of the logical volumes in the "old" volume group are
inactive (i.e. unmounted and closed):
E.g. to merge "oldvg" and "newvg" and end up with a new (larger) "newvg":
lvchange -an oldvg
vgmerge newvg oldvg
> Or would
> I have to shrink 'vg_mydata' to have free space to be able to extend
> 'vg_guests' to be able to create a snapshot?
This is probably possible - depends on whether you can completely free
up a PV.
Note that a PV (physical volume) can only belong to *one* volume
group. So if you can "shave off" a PV from one volume group, then you
can attach it to a different volume group instead.
You can also resize PVs, but since this usually requires messing with
partition tables and such things may require a reboot, this may not be
suitable for your situation.
> I want to back up the VM without shutting it down. If it can't
> avoided, I could shut it down to take the backup. In that case, how
> would I copy the volume to get a useful backup file?
>
> I think I wish I had used btrfs ...
btrfs is good - if you are working with files. When working with
block devices, LVM rules.
But... if you had set things up the analogous way with btrfs, you
would still have the same problem, and you would be asking "Can I
snapshot from one BTRFS file system into another BTRFS file system?"
It sounds you have a strange concept of volume groups here though: one
set of PVs for "data" and another set for "guests" ? Once you
segregate things like that, then you have to live with them being
separate.
The volume group concept is for grouping the *disks*, so you can treat
a group of disks with similar properties as a
interchangeable. So it makes more sense to have volume groups for
e.g. "15krpm" and "SSD". Or you can just have one big volume group,
which makes disk upgrades seamless.
Hope this helps
--
Karl E. Jorgensen
Reply to: