S. J. van Harmelen schrieb:
Hi list, In advance my excusses for this radar long post (although it's easy readable ;), but I want to make sure that I understand it correctly so I don't end up making a very costly mistake. I have a storage server (Debian Etch) with mutlipath-tools running and on top of that I use IET iscsi-target software to export the multipathed device to a XenSource server. XenSource creates a PV on the entire exported disk, and then creates a few LV's when I create some virtual machines.
Which IMO is a pity, as logically, LVM exists and is usable on that given Xen server only. This means you can't really use multiple Xen servers, live migration etc.
Now I would like to take snapshots of these virtual machines as a backup. So I want to take a snapshot every day, but hold them for only one day. These are quite static machines, so I need want several snapshots per machine. Just one in case something happens or a bad adjustment is made.
OK, should work.
I asume that when I drop the snapshot just before creating the new one, all changes are merged back to the original volume. Correct? While this merging is happening, does the disk then becomes unavailable to the virtual machine, or doesn't the virtual machine doesn't notice the merge?
I believe there is no "merging back", as the changes are being made to the snapshot volume. If you drop the snapshot, it just doesn't exist anymore, and the original volume does exist as it did before.
So yes, you can safely drop the snapshots, the process is transparent.
Also I was wondering if it's a smart idea to create a PV and a LV (both spanning the whole disk) on the storage server, and then exporting the LV true iSCSI to the XenSource server. In that way I can take the snapshots on to storage server directly.
Yes, it is indeed better and more flexible solution.
Questions that I think of then are if it's not a problem that XenSource then creates a new PV and some LV's in je LV I created adn exported on the storage server. Is that a problem, or should this work fine?
Hmm? I don't think I understand what you mean.
And another question is how I can then restore a single LV Xen created, from the snapshot of the LV that spans the whole disk on the storage server? In that case I can not just revert to the old disk before taking the snapshot, because then all the LV's created by Xen will be set back to that point, and not just the LV that went bad.
# Will only work if snapshot size is equal or greater than # the original volume dd if=/dev/LVM/volume-snapshot of=/dev/LVM/volume # or, if the allowed snapshot size is smaller, we don't want our # precious snapshot dropped dd if=/dev/LVM/volume-snapshot of=/dev/LVM/new-volume dd if=/dev/LVM/new-volume of=/dev/LVM/volume
Last question... Without creating a PV and a LV on the storage server and just letting XenSource create what it needs to provision the virtual machines, I can still see the PV and the LV's Xen created on the storage server. Could I take the snapshots from there, although the PV and LV's where not created here?
Only when you don't use them on the Xen server at the same time (no iSCSI connection; LVM modules on the Xen server unloaded, LVM modules on the storage server loaded). Which brings us to a point: it is better to manage LVMs on a storage server than on a Xen host.
-- Tomasz Chmielewski http://lists.wpkg.org _______________________________________________ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
