Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (nike.apache.org: domain of eo2@yandex.ru designates
 95.108.253.141 as permitted sender)
From: Ivan Efremov <eo2@yandex.ru>
To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>
In-Reply-To: <20CF38CB4385CE4D9D1558D52A0FC0587584A4@SJCPEX01CL03.citrite.net>
References: <2294901403061958@web5h.yandex.ru>
	 <20CF38CB4385CE4D9D1558D52A0FC058757EF7@SJCPEX01CL03.citrite.net>
	 <1449801403105446@web11g.yandex.ru>
 <20CF38CB4385CE4D9D1558D52A0FC0587584A4@SJCPEX01CL03.citrite.net>
Subject: Re: Managing individual ESXi instances
MIME-Version: 1.0
Message-Id: <949831403184287@web10g.yandex.ru>
Date: Thu, 19 Jun 2014 17:24:47 +0400
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=koi8-r

Thanks for the reply!

Ivan


18.06.2014, 21:43, "Alex Huang" <Alex.Huang@citrix.com>:
> Hi Ivan,
>
> To introduce a new hypervisor, it's a matter of
> - Adding a new Discoverer implementation to tell CloudStack which Resource best works with the new Hypervisor.
> - Adding a new Resource implementation that deals with all of the hypervisor commands sent to it. �This is the big part due to the large set of commands we send to it.
>
> For someone who understands CloudStack code and the hypervisor well, I think a prototype can be done in about two months or so. �For ESX, you have to figure out a how to map functions that CS supports but is not with ESX. �For example, I think migration and live storage migration. �You can decide not to support them in the prototype and just support simple vm/volume/network life cycle for now.
>
> --Alex
>> �-----Original Message-----
>> �From: Ivan Efremov [mailto:eo2@yandex.ru]
>> �Sent: Wednesday, June 18, 2014 8:31 AM
>> �To: dev@cloudstack.apache.org
>> �Subject: Re: Managing individual ESXi instances
>>
>> �Hi Alex,
>>
>> �How do you think, what is the rough estimation of adding ESX API support to
>> �CloudStack?
>> �AFAIU the main point of integration of the new API is plugins/hypervisors.
>> �Are there any other major points that should be patched when adding a new
>> �hypervisor type?
>>
>> �Thanks,
>> �Ivan
>>
>> �18.06.2014, 18:24, "Alex Huang" <Alex.Huang@citrix.com>:
>>> �IIRC, the reason is because the vCenter API is more powerful than the ESX
>> �API. �At the time (before Apache), the features that requested needed
>> �vCenter. There's currently no proposal to use plain ESXi. �Would love to see
>> �one though.
>>> �--Alex
>>>> ��-----Original Message-----
>>>> ��From: Ivan Efremov [mailto:eo2@yandex.ru]
>>>> ��Sent: Tuesday, June 17, 2014 8:26 PM
>>>> ��To: dev@cloudstack.apache.org
>>>> ��Subject: Managing individual ESXi instances
>>>>
>>>> ��Hi all,
>>>>
>>>> ��I've sent this mail to the users list but this one looks as the better
>> �destination.
>>>> ��I'm new to the CloudStack platform and I'm wondering why the platform
>>>> ��does need the vCenter API and can not use ESXi directly,
>>>>
>>>> ��Can anyone elaborate on this?
>>>> ��Are there any proposals for adding ESXi integration to CloudStack?
>>>>
>>>> ��Thanks,
>>>> ��Ivan