<div dir="ltr">Hi,<div><br></div><div style>thank you both for such a high quality and educational thread. I wasn't aware of the possibility of configuring the LVM metadata in a host as read-only, but it fits beautifully with OpenNebula.</div>

<div style><br></div><div style>Mihály, would you like to share your experiences somewhere in the OpenNebula community? <a href="http://wiki.opennebula.org">wiki.opennebula.org</a> or <a href="http://blog.opennebula.org">blog.opennebula.org</a>? I think many people can benefit from your setup.</div>

<div style><br></div><div style>cheers,</div><div style>Jaime<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jan 21, 2013 at 6:58 PM, Miloš Kozák <span dir="ltr"><<a href="mailto:milos.kozak@lejmr.com" target="_blank">milos.kozak@lejmr.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Oh snap, that sounds great I didn't know about that.. it makes all easier. In this scenario only frontend can work with LVM, so no issues of concurrent change. Only one last think to make it really safe against that. Is there any way to suppress LVM changes from hosts, make it read only? And let it RW at frontend?<br>


<br>
Thanks<br>
<br>
<br>
Dne 21.1.2013 18:50, Mihály Héder napsal(a):<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
no, you don't have to do any of that. Also, nebula doesn't have to<br>
care about LVM metadata at all and therefore there is no corresponding<br>
function in it. At /etc/lvm there is no metadata, only configuration<br>
files.<br>
<br>
Lvm metadata simply sits somewhere at the beginning of your<br>
iscsi-shared disk, like a partition table. So it is on the storage<br>
that is accessed by all your hosts, and no distribution is necessary.<br>
Nebula frontend simply issues lvcreate, lvchange, etc, on this shared<br>
disk and those commands will manipulate the metadata.<br>
<br>
It is really LVM's internal business, many layers below opennebula.<br>
All you have to make sure that you don't run these commands<br>
concurrently  from multiple hosts on the same iscsi-attached disk,<br>
because then they could interfere with each other. This setting is<br>
what you have to indicate in /etc/lvm on the server hosts.<br>
<br>
Cheers<br>
Mihály<div><div class="h5"><br>
<br>
On 21 January 2013 18:37, Miloš Kozák <<a href="mailto:milos.kozak@lejmr.com" target="_blank">milos.kozak@lejmr.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thank you. does it mean, that I can distribute metadata files located in<br>
/etc/lvm on frontend onto other hosts and these hosts will see my logical<br>
volumes? Is there any code in nebula which would provide it? Or I need to<br>
update DS scripts to update/distribute LVM metadata among servers?<br>
<br>
Thanks, Milos<br>
<br>
Dne 21.1.2013 18:29, Mihály Héder napsal(a):<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
lvm metadata[1] is simply stored on the disk. In the setup we are<br>
discussing this happens to be a  shared virtual disk on the storage,<br>
so any other hosts that are attaching the same virtual disk should see<br>
the changes as they happen, provided that they re-read the disk. This<br>
re-reading step is what you can trigger with lvscan, but nowadays that<br>
seems to be unnecessary. For us it works with Centos 6.3 so I guess Sc<br>
Linux should be fine as well.<br>
<br>
Cheers<br>
Mihály<br>
<br>
<br>
[1]<br>
<a href="http://www.centos.org/docs/5/html/Cluster_Logical_Volume_Manager/lvm_metadata.html" target="_blank">http://www.centos.org/docs/5/<u></u>html/Cluster_Logical_Volume_<u></u>Manager/lvm_metadata.html</a><br>
<br>
On 21 January 2013 12:53, Miloš Kozák <<a href="mailto:milos.kozak@lejmr.com" target="_blank">milos.kozak@lejmr.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
thank you for great answer. As I wrote my objective is to avoid as much<br>
of<br>
clustering sw (pacemaker,..) as possible, so clvm is one of these things<br>
I<br>
feel bad about them in my configuration.. Therefore I would rather let<br>
nebula manage LVM metadata in the first place as I you wrote. Only one<br>
last<br>
thing I dont understand is a way nebula distributes LVM metadata?<br>
<br>
Is kernel in Scientific Linux 6.3 new enought to LVM issue you mentioned?<br>
<br>
Thanks Milos<br>
<br>
<br>
<br>
<br>
Dne 21.1.2013 12:34, Mihály Héder napsal(a):<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi!<br>
<br>
Last time we could test an Equalogic it did not have option for<br>
create/configure Virtual Disks inside in it by an API, so I think the<br>
iSCSI driver is not an alternative, as it would require a<br>
configuration step per virtual machine on the storage.<br>
<br>
However, you can use your storage just fine in a shared LVM scenario.<br>
You need to consider two different things:<br>
-the LVM metadata, and the actual VM data on the partitions. It is<br>
true, that the concurrent modification of the metadata should be<br>
avoided as in theory it can damage the whole virtual group. You could<br>
use clvm which avoids that by clustered locking, and then every<br>
participating machine can safely create/modify/delete LV-s. However,<br>
in a nebula setup this is not necessary in every case: you can make<br>
the LVM metadata read only on your host servers, and let only the<br>
frontend modify it. Then it can use local locking that does not<br>
require clvm.<br>
-of course the host servers can write the data inside the partitions<br>
regardless that the metadata is read-only for them. It should work<br>
just fine as long as you don't start two VMs for one partition.<br>
<br>
We are running this setup with a dual controller Dell MD3600 storage<br>
without issues so far. Before that, we used to do the same with XEN<br>
machines for years on an older EMC (that was before nebula). Now with<br>
nebula we have been using a home-grown module for doing that, which I<br>
can send you any time - we plan to submit that as a feature<br>
enhancement anyway. Also, there seems to be a similar shared LVM<br>
module in the nebula upstream which we could not get to work yet, but<br>
did not try much.<br>
<br>
The plus side of this setup is that you can make live migration work<br>
nicely. There are two points to consider however: once you set the LVM<br>
metadata read-only you wont be able to modify the local LVMs in your<br>
servers, if there are any. Also, in older kernels, when you modified<br>
the LVM on one machine the others did not get notified about the<br>
changes, so you had to issue an lvs command. However in new kernels<br>
this issue seems to be solved, the LVs get instantly updated. I don't<br>
know when and what exactly changed though.<br>
<br>
Cheers<br>
Mihály Héder<br>
MTA SZTAKI ITAK<br>
<br>
On 18 January 2013 08:57, Miloš Kozák <<a href="mailto:milos.kozak@lejmr.com" target="_blank">milos.kozak@lejmr.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi, I am setting up a small installation of opennebula with<br>
sharedstorage<br>
using iSCSI. THe storage is Equilogic EMC with two controllers.<br>
Nowadays<br>
we<br>
have only two host servers so we use backed direct connection between<br>
storage and each server, see attachment. For this purpose we set up<br>
dm-multipath. Cause in the future we want to add other servers and some<br>
other technology will be necessary in the network segment. Thesedays we<br>
try<br>
to make it as same as possible with future topology from protocols<br>
point<br>
of<br>
view.<br>
<br>
My question is related to the way how to define datastore, which driver<br>
and<br>
TM is the best and which?<br>
<br>
My primal objective is to avoid GFS2 or any other cluster filesystem I<br>
would<br>
prefer to keep datastore as block devices. Only option I see is to use<br>
LVM<br>
but I worry about concurent writes isn't it a problem? I was googling a<br>
bit<br>
and I found I would need to set up clvm - is it really necessary?<br>
<br>
Or is better to use iSCSI driver, drop the dm-multipath and hope?<br>
<br>
Thanks, Milos<br>
<br>
______________________________<u></u>_________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opennebula.org" target="_blank">Users@lists.opennebula.org</a><br>
<a href="http://lists.opennebula.org/listinfo.cgi/users-opennebula.org" target="_blank">http://lists.opennebula.org/<u></u>listinfo.cgi/users-opennebula.<u></u>org</a><br>
<br>
</blockquote></blockquote></blockquote></blockquote>
______________________________<u></u>_________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opennebula.org" target="_blank">Users@lists.opennebula.org</a><br>
<a href="http://lists.opennebula.org/listinfo.cgi/users-opennebula.org" target="_blank">http://lists.opennebula.org/<u></u>listinfo.cgi/users-opennebula.<u></u>org</a><br>
</blockquote></div></div></blockquote><div class="HOEnZb"><div class="h5">
<br>
______________________________<u></u>_________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opennebula.org" target="_blank">Users@lists.opennebula.org</a><br>
<a href="http://lists.opennebula.org/listinfo.cgi/users-opennebula.org" target="_blank">http://lists.opennebula.org/<u></u>listinfo.cgi/users-opennebula.<u></u>org</a><br>
</div></div></blockquote></div><br></div><br clear="all"><div><br></div>-- <br>Jaime Melis<br>Project Engineer<br>OpenNebula - The Open Source Toolkit for Cloud Computing<br><a href="http://www.OpenNebula.org" target="_blank">www.OpenNebula.org</a> | <a href="mailto:jmelis@opennebula.org" target="_blank">jmelis@opennebula.org</a>