linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: "S. J. van Harmelen" <svh@dds.nl>
To: linux-lvm@redhat.com
Subject: [linux-lvm] LVM snapshots in a iSCSI and XenSource environment
Date: Tue, 20 Nov 2007 12:13:03 +0100	[thread overview]
Message-ID: <1195557183.6329.54.camel@sanderbal> (raw)

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.

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.

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?

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.

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?

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.

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?

Hope someone can tell me what the best option is, and if all this is
possible?

Thanks!!

Sander

             reply	other threads:[~2007-11-20 11:13 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-20 11:13 S. J. van Harmelen [this message]
2007-11-20 11:37 ` [linux-lvm] LVM snapshots in a iSCSI and XenSource environment Tomasz Chmielewski
2007-11-20 12:21   ` S. J. van Harmelen
2007-11-20 13:06     ` Tomasz Chmielewski
2007-11-20 16:12       ` S. J. van Harmelen
2007-11-20 17:29         ` malahal
2007-11-20 17:56           ` S. J. van Harmelen
2007-11-23  8:27           ` S. J. van Harmelen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1195557183.6329.54.camel@sanderbal \
    --to=svh@dds.nl \
    --cc=linux-lvm@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).