[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH 1/1] [RFC] Parallels Server Bare Metal driver stub



Eric,


Thank you for your comments!


I'll check related to HyperV adoption commits and will try to fix necessary things in the next patch series.


Links to product pages:

http://www.parallels.com/products/server/baremetal/sp/resources/

http://www.parallels.com/download/server/


> Is this driver more like qemu,

> where it requires talking to a daemon like libvirtd (and where remote

> access is provided by libvirt), or more like esx, where it is

> translating things at the client level while talking to an esx protocol

> (and where remote access is provided by the hypervisor)?

We have a userspace daemon on PSBM node which is responsible for incoming requests management (like libvirtd) and client library (libprl_sdk.so) for remote/local access to it. Communication protocol is XML-based over TCP.


> Is it really Linux-only, or if those

> programs someday exist on other platforms, have you artificially

> restricted this driver?

Virtualization SDK is available for 3 platforms (Linux, Windows and Mac OS X) already. I decided to restrict it initially in order to achieve something usable on the single platform first, than extend it to others. Patches for extension will be small - just remove this restriction and add load of the shared library on appropriate paths. Just want to avoid additional testing on the adoption stage.


--

Thanks,

Dmitry.

On Tuesday, September 27, 2011 09:39:14 PM Eric Blake wrote:

> On 09/26/2011 05:59 AM, Dmitry Mishin wrote:

> > Parallels Server Bare Metal is a virtualization solution which allows to

> > run both Containers (OpenVZ-like) and virtual machines (like any other

> > hardware hypervisor).

>

> Any web page link so we can familiarize ourselves with the project?

>

> > This patch implements initial driver stub with almost no functionality

> > except an ability to open and close driver. At the same time it contains

> > initialization of Parallels API and clearly demonstrates supposed

> > approach to future driver implementation. In particular, I suppose to

> > use parallels-virtualization-sdk library provisioned with the PSBM

> > distribution (and separately also) for PSBM's virtual servers

> > management.

> >

> > Signed-off-by: Dmitry Mishin<dim parallels com>

> > ---

> >

> > autobuild.sh | 1 +

> > configure.ac | 21 +++++

> > include/libvirt/virterror.h | 1 +

> > src/Makefile.am | 22 +++++

> > src/README | 1 +

> > src/driver.h | 1 +

> > src/libvirt.c | 9 ++

> > src/psbm/psbm_api.c | 117 ++++++++++++++++++++++++

> > src/psbm/psbm_api.h | 59 ++++++++++++

> > src/psbm/psbm_driver.c | 208

> > +++++++++++++++++++++++++++++++++++++++++++ src/psbm/psbm_driver.h

> > | 32 +++++++

> > src/psbm/psbm_private.h | 49 ++++++++++

> > src/util/virterror.c | 3 +

>

> Missing a hypervisor stub page under docs/ (that would be a good place

> to include the link I mentioned above). Is this driver more like qemu,

> where it requires talking to a daemon like libvirtd (and where remote

> access is provided by libvirt), or more like esx, where it is

> translating things at the client level while talking to an esx protocol

> (and where remote access is provided by the hypervisor)?

>

> Missing changes to libvirt.spec.in and mingw32-libvirt.spec.in for

> making compilation of the new driver conditional when building for

> Fedora and friends.

>

> I'd feel a bit more comfortable reviewing this patch if you also had a

> followon patch that can do some basic APIs, such as start and stop

> guests, or even just list the names of running guests. Of course, those

> should be separate patches, but it is better to push a patch series that

> makes the hypervisor driver useful, rather than just pushing this patch

> in isolation where the hypervisor driver can't do anything at all. Look

> at the recent HyperV hypervisor driver addition (around commit 5e3b0f8)

> for an example of what all is needed to make this driver addition

> successful.

>

> > +

> > +if test "$with_psbm" = "yes"&& test "$with_linux" = "no"; then

> > + AC_MSG_ERROR([The PSBM driver can be enabled on Linux only.])

>

> Are there any libraries that have to be linked in? Is this all calls to

> third-party program(s) (in which case, should configure probe for the

> absolute path of that program)? Is it really Linux-only, or if those

> programs someday exist on other platforms, have you artificially

> restricted this driver?

>

> > +int psbmApiInit(struct psbm_driver *driver)

> > +{

> > + const char *libname = "libprl_sdk.so";

>

> Looks like you are using library calls, so configure needs to probe for

> the existence of this library.

>

> > +

> > +static virDriver psbmDriver = {

> > + .no = VIR_DRV_PSBM,

> > + .name = "PSBM",

> > + .open = psbmOpen, /* 0.3.1 */

> > + .close = psbmClose, /* 0.3.1 */

> > + .type = psbmGetType, /* 0.3.1 */

> > + .version = psbmGetVersion, /* 0.3.1 */

> > + .nodeGetInfo = nodeGetInfo, /* 0.3.1 */

> > + .listDomains = psbmListDomains, /* 0.3.1 */

> > + .numOfDomains = psbmNumDomains, /* 0.3.1 */

>

> Wrong version. You are adding this functions as of 0.9.7, not 0.3.1.

>

> I haven't reviewed this closely, because I'm not familiar enough with

> PSBM yet, but in general, I'm in favor of adding hypervisor drivers, so

> I hope to see this go somewhere.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]