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 -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list