Zfsonlinux.org has info on using ZFS with debian. I create vm images and snapshot them and clone the snapshots all the time. The clones are writable and only use as much space as corresponds to the difference from the source. The volumes have to be ZVOL s, not regular files. I have found this very reliable. -- John Holland jholland@vin-dit.org gpg public key ID 0x9551CF2D ----- Original Message ----- From: lee <lee@yagibdah.de> Sent: 10/04/2014 - 9:31 AM To: debian-user@lists.debian.org Subject: Re: lvm: creating a snapshot > "Karl E. Jorgensen" <karl@jorgensen.org.uk> writes: > >> 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 > > Hm, ok, LVM sucks then. > >>> 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 > > That would make the system disks and the data disks depend on each > other. I'd like to keep them independent. > >>> 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. > > Physical volumes are the logical volumes provided by the RAID > controller. I could delete the data because I have a backup. If I do > that, I might better run the disks as JBOD (if I can get that to work) > and use btrfs instead. It wouldn't bring me closer to making backups of > the VMs, though. > >> 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. > > Well, it's like this: > > > |-- SATA 2TB --| > |-- SATA 2TB |--> LV RAID5 --> LVM: vg_mydata (84GB avail) > |-- SATA 2TB --| > ServeRaid 8k---| > |-- SAS 72GB --| > | |--> LV RAID1 --> dom0, LVM: vg_guests (full) > |-- SAS 72GB --| > > > 'vg_guests' is on its own partition. That's IMHO a very reasonable > setup. Only LVM is unreasonable in that it doesn't let me make > snapshots, which is one of the two reasons why I used it. (The other > reason is that it makes it simple and efficient to provide volumes to > the guests which then can be partitioned from within the guests.) > > I want to make snapshots of logical volumes in 'vg_guests' to create > backups, and they must go into a LVM-LV in 'vg_mydata' because there are > 84GB available for this and no free space anywhere else. > > That shouldn't be a problem at all. > > Alternatively, I'd be fine with backing up the whole 'vg_guests' while > the guests are shut down. I just want a backup of them which I can > restore from if I have to. > > So could I somehow copy a whole LVM volume group? This could be done > from dom0, and I could push the data over the network or put it into the > free space of 'vg_mydata'. It would be very awkward, yet still better > than no backup at all. > > I could back up the partition 'vg_guests' is on with dd, but perhaps > there is a better way? > >> 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. > > A reboot would be possible, though I don't want to mess with partition > tables. The server can be shut down for up to 4 days before I'd have a > problem. > >>> 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. > > In which way would LVM be better than btrfs? I can't even make a > snapshot with LVM ... > >> 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?" > > Perhaps I would since I cannot reasonably combine 2TB disks and 72GB > disks in a RAID5 across all of them with btrfs, or can I? Are you > saying I wouldn't be able to make a snapshot or to create a backup with > btrfs, either? > > But then, since all disks are evenly sized, why shouldn't I be able to > create a RAID5 with btrfs across all of them (letting aside that I don't > want to mix them and that I'm not sure if I can get the RAID controller > to present them as JBOD)? > >> 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. > > What's strange about separating the system from the data? > >> The volume group concept is for grouping the *disks*, so you can treat >> a group of disks with similar properties as a interchangeable. > > Interchangeable? When I remove a disk or some disks from a volume > group, the volume group would be damaged and inaccessible, wouldn't it? > >> So it makes more sense to have volume groups for e.g. "15krpm" and >> "SSD". > > That's what the RAID already does, by providing logical volumes. > >> Or you can just have one big volume group, which makes disk upgrades >> seamless. > > That wouldn't allow me to keep system and data separate. I'd find that > rather messy. > > But then, I don't know ... perhaps it's still the only way to achieve > the required abstraction from the physical disks and actually what is > desired. Btrfs would come in really handy for this. > > > Question: If I wanted to have more disks than I can fit into the server, > what would I do? Buy a storage rack that fits 24 disks or so, which is > connected via fibre channel? I'd probably need a fibre channel HBA in > the server? How is Linux support for them? How are the disks presented > to the server? Can I plug SATA disks into such a storage rack? Are all > the storage racks compatible to every FC HBA? Do they have some sort of > RAID controller integrated, or what do they do? > > How exactly is this done? Is there some documentation I could read > about this? > > > -- > Hallowed are the Debians! > > > -- > To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org > Archive: [🔎] 877g0gttau.fsf@yun.yagibdah.de">https://lists.debian.org/[🔎] 877g0gttau.fsf@yun.yagibdah.de
Attachment:
signature.asc
Description: PGP/MIME digital signature