From: Tomasz Chmielewski <mangoo@wpkg.org>
To: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] LVM snapshots in a iSCSI and XenSource environment
Date: Tue, 20 Nov 2007 12:37:30 +0100 [thread overview]
Message-ID: <4742C6FA.6020006@wpkg.org> (raw)
In-Reply-To: <1195557183.6329.54.camel@sanderbal>
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
next prev parent reply other threads:[~2007-11-20 11:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-20 11:13 [linux-lvm] LVM snapshots in a iSCSI and XenSource environment S. J. van Harmelen
2007-11-20 11:37 ` Tomasz Chmielewski [this message]
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=4742C6FA.6020006@wpkg.org \
--to=mangoo@wpkg.org \
--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).