<div dir="ltr">Hello,<br><br><div class="gmail_quote">On Wed, Sep 3, 2008 at 3:12 AM, William Voorsluys <span dir="ltr"><<a href="mailto:williamvoor@gmail.com">williamvoor@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hello Alvaro,<br>
<br>
I'm forwarding this thread to ONE users. We are discussing on network<br>
customization in the context of the WS + ONE integration.<br>
<br>
More comments inline.<br>
<div><div></div><div class="Wj3C7c"><br>
>> Hello Alvaro,<br>
>><br>
>> It's really good to hear you are interested in the integration between<br>
>> Globus WS and OpenNebula. My work regarding this integration was done<br>
>> as part of Google Summer of Code, which just finished a week ago.<br>
>> Since there are still some things to be improved, it would be nice if<br>
>> we joined our efforts.<br>
>> I'm cc'ing this reply to Borja, who mentored my project on Google SOC.<br>
>> Also, do you mind carrying on this discussion in the OpenNebula<br>
>> mailing list?<br>
><br>
> I don't mind at all! :) I simply thought it might not be that interesting...<br>
> hehe<br>
><br>
>><br>
>> > For example, a problem I noticed, for which you already commented me a<br>
>> > solution, was to know the IP of a submitted VM... With the reply I got<br>
>> > from<br>
>> > you, I got clear the way to know it... I was just wondering if there was<br>
>> > a<br>
>> > "method" which returned the IP to the user, just in case she is not<br>
>> > managing<br>
>> > the server, for example. Or to know VM's IP if the user didn't input any<br>
>> > MAC<br>
>> > at all...<br>
>> > I've implemented a "Forward" IpConfig - AcqusitionMethod, which simply<br>
>> > lets<br>
>> > OpenNEbula configure the network (I'm totally replacing worksp-control<br>
>> > backend!) and it doesn't do much (nothing?), of course. But I just<br>
>> > imagined<br>
>> > an implementation were the user, even without introducing a MAC address,<br>
>> > got<br>
>> > an IP (previously unknown for her) after submitting its template, to<br>
>> > immediately start using the VM. I guess it's not possible and then I<br>
>> > would<br>
>> > just make a mapping function between MAC and IP addresses...<br>
>><br>
>> On the Workspace Service, networking functionality (associations) is<br>
>> managed by a Network Adapter (NA), which is responsible for assigning<br>
>> IPs from a pool of available addresses. In fact, users don't input MAC<br>
>> address, instead the NA generates a MAC address and binds it to an IP<br>
>> address, then assigning this pair to a workspace configuration.<br>
><br>
> This depends on one of the three acquisition methods imlemented, right? If<br>
> so, the thing is that I want to implement a new "Forward" acquistiono<br>
> method...<br>
<br>
</div></div>Exactly. The configuration steps I described are related to the<br>
AllocateAndConfigure method.<br>
<div class="Ih2E3d"><br>
>> Later on, the DHCP server is automatically configured by the backend<br>
>> script<br>
>> to assign that IP to the VM that requests an IP lease with that MAC<br>
>> address.<br>
><br>
> To which backend script are you referring?<br>
<br>
</div>There are 3 Python scripts that deal with network customization:<br>
dhcp-conf-alter.py,  dhcp-config.sh and  ebtables-config.sh. They are<br>
part of the Workspace backend. Since I have replaced the current<br>
backend, these scripts are not used. However, as I mentioned it would<br>
not be hard to port these scripts to allow automatic network<br>
configuration on this integration. The Workspace front-end itself, via<br>
a network adapter, could invoke this script to make the necessary<br>
changes to the DHCP server config file. Thus, provided that the image<br>
submitted is configure to use DHCP and its primary NIC is bound the<br>
correct bridge, the VM would automatically acquire one of the IP<br>
address available on the chosen association.<br>
I have not looked deeply into the current network adapter<br>
implementation, so I'm not sure how this would be done.<br>
In summary, my suggestion to you would be trying to improve network<br>
customization on the WS side instead of having this "Forward"<br>
acquisition method.</blockquote><div><br>Yes, it would be nice to improve current networking settings, but in my approach, I must use this "Forward" method. Any case, those improvements can be made in the near future, but I'm not planning to do them right now...<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
Cheers,<br>
<br>
William.<br>
<div><div></div><div class="Wj3C7c"><br>
>> IMO this functionality should be preserved (possibly ported from the<br>
>> backend scripts to the service side) so that even if we drop the<br>
>> original backend scripts we would have automatic DHCP configuration.<br>
><br>
> This would be perfect, but this should really be automagic network<br>
> configuration. What I want is the case in which you want an implementation<br>
> where the Workspace frontend doesn't know anything about the backend (one,<br>
> to the case) but the IP of the server hosting the backend...<br>
><br>
>><br>
>> That also means that ONE does not need to manage networking. Porting<br>
>> these scripts was one of the things I wanted to do but time didn't<br>
>> allow, but you might be interested in doing. Such an effort would<br>
>> allow ONE to have automatic IP assignment using the "acquisition<br>
>> methods" already implemented in the WS.<br>
><br>
> My approach was different: I wanted to implement a new "Forward" acquistion<br>
> method. It would just let any backend (in this case onevm) configure network<br>
> settings. In other words, Workspace would not be responsible in assigning<br>
> IP, but the backend.<br>
> The idea was that the resourcepool file contained only one line to the (ONE)<br>
> backend server, who would be in charge to configure everything... In your<br>
> approach, where do you get the backend IP from? Is it, to say something, the<br>
> first line of that file?<br>
> Because I think that someone may provide a ONE service (I mean, a cluster<br>
> virtualization service) and should not know anything about any other IP but<br>
> backend's. That way, the user would only ask for an execution of a VM and<br>
> then would get an IP in return, to start using it... Do you think this is<br>
> feasible? Any help? Because I might be overlooking something...<br>
><br>
><br>
>><br>
>> > Another question I came up with, was a correct mapping between<br>
>> > Workspace's<br>
>> > "reboot", "pause" and "unpause" flags to OpenNEbula's, with no proper<br>
>> > candidates for the moment (onevm's "save" and "restore" is not exactly<br>
>> > the<br>
>> > same!)...<br>
>> > As of now, I've mapped the following flags parsed to the programs:<br>
>> ><br>
>> > Workspace | worksp-control | onevm | xm:<br>
>> ><br>
>> > deploy | create | onevm submit + onevm deploy (to which machine? maybe<br>
>> > using<br>
>> > the getHosts API you commented??) | scp... + xm create...<br>
>> > destroy | remove | onevm shutdown | xm shutdown...<br>
>> > destroy --deleteall | remove deleteall | onevm cancel | xm destroy...<br>
>> > shutdown-save | remove + unpropagate | onevm shutdown + onevm delete |<br>
>> > xm<br>
>> > shutdown...<br>
>> ><br>
>> > But what about reboot, pause, unpause? Do you have a different solution?<br>
>> > No<br>
>> > direct mapping for those cases I guess...<br>
>><br>
>> First of all, please note I haven't used the CLI to invoke ONE<br>
>> commands. Instead, I'm using ONE's XML-RPC API.<br>
><br>
> I think your aproach might be better and, indeed, I was thinking of porting<br>
> my existing solution... Because I faced problems like getting the ID of the<br>
> newly submitted template that, in your aproach, is easily handled :D<br>
><br>
>><br>
>> Anyway, the mapping I used was the following:<br>
>><br>
>> 1. deploy -> onevm submit<br>
>> I don't call 'onevm deploy' since I assume that scheduling will be done by<br>
>> ONE.<br>
><br>
> Yes, I agree. Anyway, do you leave worksp-control --propagate unimplemented<br>
> (just like shutdown-save) or make it call onevm submit?<br>
><br>
>><br>
>> 2. For destroy related commands I simply call 'onevm shutdown'. I'm<br>
>> not using onevm delete. Maybe I should call delete sometime, but this<br>
>> is not currently done. Also, there is not such command 'onevm cancel',<br>
>> is there?<br>
><br>
> You're right. With onevm shutdown should work... But what about using onevm<br>
> delete in the unpropagate worksp-control flag? Or leave it unimplemented? I<br>
> think it may fit... By the way, there is no such a onevm cancel, you're<br>
> right :p I turns out that I saw a function (action_cancel) in<br>
> ./src/vmm_mad/xen/one_vmm_xen.rb which calls, indeed, the xm destroy<br>
> command, which is, in turn, what worksp-control --remove --deleteall<br>
> calls...<br>
><br>
>><br>
>> 3. Shutdown save<br>
>> The notion of 'propagation' is not really necessary when using ONE,<br>
>> since it relies on NFS to propagate VM images to the nodes. So, once<br>
>> the VM is shutdown, its image is already unpropagated, which in the WS<br>
>> context means copying the VM image back from cluster nodes to the node<br>
>> where the WS is installed.<br>
><br>
> You're absolutely right. So I guess Workspace --shutdown-save is like<br>
> Workspace --shutdown, whic in turn calls onevm shutdown too, right? Or it is<br>
> a different case to Workspace --destroy? At the end, we might have three<br>
> Workspace flags executing onevm shutdown... :p<br>
><br>
>><br>
>> 4. Reboot<br>
>> onevm stop + resume.<br>
><br>
> But onevm stop saves the state of the machine, just like suspend does<br>
> (<a href="http://www.opennebula.org/doku.php?id=documentation:rel1.0:ug" target="_blank">http://www.opennebula.org/doku.php?id=documentation:rel1.0:ug</a>) and does not<br>
> shutdown the machine, right? I mean, when you resume it back again, it goes<br>
> to the previous state (with its previous configuration and errors :p) of the<br>
> VM, isn't it?<br>
><br>
>><br>
>> 5. Pause/Unpause<br>
>> onevm suspend  + resume<br>
><br>
> I think this is the more similar mapping, though IMO, onevm suspend is like<br>
> "hibernation" and worksp-control --pause is like "suspend" ;)<br>
><br>
>><br>
>> I'm not sure if this mapping is perfect or not. But we can discuss<br>
>> this further with the OpenNebula developers.<br>
>><br>
>> > Though I have some more annoyances in my head, those are the important<br>
>> > ones... What do you think, may we share information about it? ;) I<br>
>> > really<br>
>> > hope so... :)<br>
>> > In any case, I guess you're very busy so I'd like to absolutely thank<br>
>> > you<br>
>> > for reading until here and giving me some attention!<br>
>><br>
>> Please e-mail me anytime!<br>
><br>
> Thank you very very much for all your time and help provided :)<br>
><br>
>><br>
>> I will also forward you the pointers to the code I have produced<br>
>> during this summer.<br>
>><br>
>> Cheers,<br>
>><br>
>> William<br>
><br>
> Best regards,<br>
><br>
> Alvaro<br>
><br>
><br>
> --<br>
> Álvaro<br>
><br>
<br>
<br>
<br>
</div></div><font color="#888888">--<br>
William Voorsluys<br>
<br>
<a href="http://williamvoor.googlepages.com" target="_blank">williamvoor.googlepages.com</a><br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Álvaro<br>
</div>