Status: New
Owner: ----
New issue 796 by [email protected]: LVM as top level abstraction for
every disk template
http://code.google.com/p/ganeti/issues/detail?id=796
Hi,
I like the idea to have LVM as a top level abstraction of the instance's
disks. Example:
* disk template shared file:
- disk image on a shared file system
- loop setup to get /dev/loopX as block device (on primary node)
- put a LVM PV/VG/LV on loopX (at least one or more VGs per instance)
- use LVs as instance's disks
This approach gives following advantages:
- having a hypervisor/disk template independent method for some SAN
semantics
- this are: snapshots, mirroring (replication), storage migration
Example 1:
* disk template drbd: create snapshots above DRBD, so that they get
mirrored (of course with dm_thin_pool)
Example 2:
* migrate online (pvmove) from DRBD to shared file template
* or migrate online from $SAN_vendor1 to $SAN_vendor2 (ext. provider 1 -> 2)
Example 3:
* do SAN based replication to another $SAN (RAID1), even asynchronously
(dis-/connected RAID1)
The usage of cLVM should be avoidable, when only doing LVM changes while
LVM mapping is on primary node (i.e. no instance migration active) ...?
Storage migration blocks instance migration and vise versa.
What do you think?
Thanks, Sascha.
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
