incubator-deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Casebolt <>
Subject Re: 0.3.0 RC 1 and RHEV?
Date Thu, 14 Apr 2011 11:53:40 GMT

On Apr 14, 2011, at 7:30 AM, Michal Fojtik wrote:

> On Apr 14, 2011, at 2:39 AM, John Casebolt wrote:
>> Hi David,
>> On Apr 13, 2011, at 6:49 PM, David Lutterkort wrote:
>>> Hi John,
>>> On Fri, 2011-04-08 at 20:12 -0400, John Casebolt wrote:
>>>> Just wondering what the status of the new RHEV driver is as of 0.3.0 RC 1?
>>>> I've tried to get it up and running, but found a few issues.
>>>> Before getting too much further into it, just wanted to make sure that there
aren't any known blockers that would keep RHEVM from working with 0.3.0.
>>>> If there are, I'll just jump up and work with HEAD...
>>> No, there aren't any known bugs in the release candidate (now rc2)
>>> For getting everything set up, the best documentation is still in
>>> teambox[1]
>>> David
>>> [1]
>> Thanks.
>> I'll work with 0.3.0 RC2.
>> We've been using RHEV for quite a while now, and have been experimenting with direct
calls to the RHEV-M API using generic RESTful clients to get the feel of it.
>> We just upgraded today to the latest RHEV-M API milestone release from a few days
>> For anyone interested, we'll be calling Deltacloud from Java using RESTEasy (or another
toolkit if I can't figure out how to cleanly get RESTEasy client integrated into our Maven
>> Our overall use case is to replace a VMWare Lab Manager SOAP API-based virtualization
backend with one based on Deltacloud and (initially) RHEV-M.
>> The only major head-scratcher so far is the lack of availability of the IP address(es)
of the NICs on the VMs via the Deltacloud->RHEV-M API path.
>> I know that in RHEV 2.2, Windows RHEV guest tools provide IP info back to RHEV-M
(at least on the host level if not on the NIC level), but Linux guests do not have an equivalent
>> I also don't see the IP address info (even for the Windows VMs) showing up in the
RHEV-M api.
>> I see on the teambox Wiki that workarounds exist; a pointer to that info would be
greatly appreciated. 
> Yes, to be honest, this IP stuff drives me crazy everyday, but in background I understand
> of getting IP addresses from VM...
> The only workaround I tested so far is a simple HTTP key=>value server on DC API VM
(we're running DC RHEV-M API on RHEV-M VM ;-)
> and then one-line cron task in guests. This cron task just submit MAC->IP to the key=>value
server and then a small hack in
> Deltacloud RHEV-M client library solve this problem. 
>> My understanding is that the IP address info will be available both in RHEV console
and in the API in a future release.
> Yes, that's the plan :)
>  -- Michal
Thanks for all the feedback, guys.

We're admittedly using Lab Manager as much more of a "Virtual Machine" manager than a "Cloud"
manager - in my mind those are two (partially?) divergent things; Cloud Management, at least
IMHO, should enable an opacity to the end user, abstracting away the very things I need in
a more "white box/clear box" VM Manager. For an example from an API standpoint, check out
the differences in the vSphere API [1] and the vCloud API [2]. 

Given our customer's requirements for visibility into and control of the VMs as test platforms
(we've had to do things like virtually deactivate and reactivate NICs on VMs during tests),
that need for more knobs and dials on the VMs is not likely to change soon.

I'm hoping that we can move our approach enough in the cloud direction to leverage deltacloud
for a number of reasons, not the least of which is freedom from vendor lock-in.  I've already
found a number of places in design and implementation where we have cohered ourselves a bit
too much to the VMWare/Lab Manager way of doing things.  For example, when it comes to the
IP addresses, we leverage a Lab Manager concept of Static IP Pools (kinda like private DHCP)
and the ability to retrieve the IP address from the SOAP API.

Thanks to your emails and our prior thought, I've got some ideas.  We have to support provisioning
and testing of RHEL, Windows and Solaris (x86 and maybe even Solaris) guests - as VMs or bare
metal. To do that, we currently use a custom Java-based agent on the VM guests.  That agent
has a messaging channel back to our provisioning service, and I can use that channel and/or
multicast DNS to try to eliminate a dependency on the IP address info returning from the VM.

Thanks again for the input and work so far - hope we can contribute!



View raw message