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 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141003212402.GB27564@hawking