Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
I'm reading through openQRM documentation, and I can't find any mention of fibre channel storage. Is it unsupported or does the support depend on underlying OS (Linux?). Can it be supported via some plugin (couldn't find any).
Thanks for any pointers!
simply connect your FC to your virtualization hosts, create a lvm volume group on the FC device(s) and use kvm-storage or xen-storage. This will allow you to manage the FC devices via openQRM.
many thanks + have a nice day,
Project Manager openQRM
how do you handle shared FC Storage then? Simply adding LVM on top does not provide any kind of locking for shared FC LUNs.
right, but openQRM takes care to activate the lvol only for one VM.
If you need you can also use CLVM but you will loose the option to snapshot.
many thanks and have a nice day,
so you are saying, the LVM PVs will be available on several hosts but the specific LVs will only be active on one host at a time? How do you handle LVM metadata updates? I know CLVM would be a solution but i'd rather avoid that for lack of snapshotting.
So far i came to the conclusion that seperate FC LUNs for each VM might be a way around that. Then the snapshot functionality has to be implemented in the FC SAN though.
How is your recommended best practice with FC SAN on each kvm host?
So far i have not seen someone writing about a setup like that. It is usually iSCSI or AOE.
we update the metadata on each hosts before activating the lv (pvscan/vgscan).
With a FC SAN you have several options e.g. :
- connect the SAN volumes to all hosts and use kvm-storage (local-deployment)
- connect the SAN volume to a linux box, create an lvm-iscsi storage out of it and use kvm + network-deployment
With the second option you then have 2 storage layers and you may snapshot/backup at each layer. Also well for scalability.
Project Manager openQRM
thank you for your reply.
I would like to fully understand your usage of LVM in this case.
You are saying that the LVM volume group is active on multiple hosts while the LVM logical volumes are only set active on the respective host. That poses two questions for me:
a) How is a metadata change to the VG handled? I.e. if the VG is resized the metadata needs to be updated on all hosts. AFAIK this can only be consistently done with CLVM. Same for creation of a new LV. So if you are doing a pvscan/vgscan prior to activating a LV you expect everything to work out as long as nobody tries to change metadata on more than one host inbetween pvscan/vgscan. Sounds risky to me without CLVM.
b) How does migration work? AFAIK here the LV would need to be active on both hosts.
So far my conclusion is, that shared FC storage should be directly exposed to kvm guests on a per LUN basis. That way there is no LVM/CLVM locking problem. There also is no snapshot capability but with CLVM that does not exist anyway.
Is that possible to achieve with OpenQRM and what would be the OpenQRM "terms" for that be? kvm-storage?
iSCSI on top would render the FC storage and its performance advantages on each host moot. It would further put a lot more load on the 2 network interfaces. And it would reduce the availability of the SAN storage by implementing another layer.
I appreciate your feedback! :)
a) almost agree with you about the resize. clvm of course would be an option … still it is missing the snapshot capability which is quite important for many people
b) right, but only one VM is effectively accessing it at a time. Works fine :)