[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] Share storage using iscsi [EDIT as I cut off part]



Dnia poniedziałek 17 sierpień 2009 o 21:03:12 Dave Allan napisał(a):
> Łukasz Mierzwa wrote:
>[...]
> > Let me make that little more clear:
> > 1. Lets assume I have one storage node that is acting as a iscsi target.
> > 2. This storage node has one big block device (RAID of some kind) that
> > will be used for storing virtual machines volumes
> > 3. I have multiple nodes for hosting virtual machines.
> > 4. Each of those hosting nodes needs to be able to access every volume
> > stored on the storage node (for live migration) using iscsi.
> >
> > I'm looking for proper way to do this. Right now I'm thinking about this
> > setup:
> > 1. On the storage node I will create lvm volume group using my RAID.
> > 2. Each virtual machine volume is created as lvm logical volume, it
> > doesn't matter how this volume is created (by hand, using management app
> > or any other way) but it always happens on the storage node. I could
> > export whole RAID as a single LUN, create lvm volume group on top of
> > that, but to be able to work with this lvm volume group from every
> > hosting node at the same time I would need to use clustered lvm (or
> > something like that) and that would add some complexity.
> > 3. Each lvm logical volume is exported as unique LUN (also out of
> > libvirt scope)
> > 4. iscsi LUNs are discovered using libvirt iscsi volume pool, and
> > assigned to right virtual machine.
>
> I see what you're proposing, and you're correct.  If you confine the
> visibility of the LVs to the iSCSI target and expose each one as a
> separate iSCSI LUN, you don't need clvm on the nodes.  That will work
> fine, and libvirt will handle the discovery through a refresh of the
> volume pool.  As you point out, libvirt won't handle telling the iSCSI
> target to create the new LUNs.
>
> If you go the route of exposing the VG to the nodes, you would need clvm
> on the nodes.
>
> As a side note, I don't object to creating functionality to allow
> libvirt to manage iSCSI targets, extending the volume create/delete code
> to interface with the target.  However, I don't want to try to create
> code to manage every possible iSCSI target.  If you wanted to submit a
> patch to libvirt to do the kind of target management you're looking for,
> I would support that effort, and I'd be happy to work with you to set up
> a framework for plugging in code to manage whatever arrays anybody
> wanted to support.  You're not the only person to want that
> functionality, and if it's done in a well-defined way, I think it would
> be a good thing.  Others on the list might have different opinions.

That would be great but unfortunately I have not much experience with C/C++ 
and I'm afraid that this would take a while for me to achieve. I'm more of 
sysadmin with some python skills than a programmer. Also my spare time is 
limited as I'm working on a hobby project 
(http://github.com/prymitive/pumpkin).

Łukasz Mierzwa


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]