8:45 a.m.
This is a multi-part message in MIME format.
--------------040400080701000207050401
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
On 11/08/2013 01:00 AM, hackxay wrote:
Hi.
When we add a new host,engine can installed the vdsm on the host and
vdsm can call the interface of libvirt.
The libvirt support VirtualBox.But the VDSM uses qemu-kvm.
I want to let vdsm can use libvirt to call the interface of VitualBox.
I agree that it is unfortunate that we have limited the power of libvirt
in terms of the number of backends it can manage when integrating it
into oVirt.**Extending to VirtualBox would be an interesting project,
but I'm not sure how valuable it would be. As a long-time user of
VirtualBox I found it to be slower than KVM. I guess it could allow
people to use non-Linux Nodes. Like Dan said, a lot of work there so the
payoff would have to be big enough to justify it.
On the other hand, I think it would have far greater impact in terms of
number of use cases/users if we expanded VDSM to manage VMware ESX.
VMware is still arguably the market leader for virtualization. At the
very least, this would then provide a migration path for anybody wanting
to move away from VMware to oVirt (or, perhaps, visa-versa if we don't
do a good enough job with oVirt ;). Since the Nodes would effectively
still be restricted to Linux the task should be easier than e.g.
supporting a Node consisting of Windows+VirtualBox. As with VirtualBox,
there's no SPICE capability for VMware, so in addition to the VDSM work
the User Portal should be extended to support e.g. VMware Horizon View
Client.
-Bob
P.S. If we *did* support VirtualBox, the User Portal should be extended
to broker VNC connections since that's one way to connect to a console
with VBox. That wouldn't be a bad project in itself, and would have
value even without VirtualBox.
--------------040400080701000207050401
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 11/08/2013 01:00 AM, hackxay
wrote:<br>
</div>
<blockquote
cite="mid:38f27188.46c5.142364bf261.Coremail.hackxay@163.com"
type="cite">
<style type="text/css"> <!--@import url(scrollbar.css);
--></style>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<style> body{FONT-SIZE:12pt;
FONT-FAMILY:宋体,serif;} </style>
<meta name="GENERATOR" content="MSHTML 11.00.9600.16384">
<base target="_blank">
<div><font size="2"
face="微软雅黑">Hi.</font></div>
<div><font size="2"
face="微软雅黑">When we add a new
host,engine can
installed the vdsm on the host and vdsm can call the interface
of libvirt.</font></div>
<div><font size="2"
face="微软雅黑">The libvirt support
VirtualBox.But
the VDSM uses qemu-kvm.</font></div>
<div><font size="2"
face="微软雅黑">I want to let vdsm
can use libvirt
to call the interface of VitualBox.</font><br>
</div>
</blockquote>
<br>
I agree that it is unfortunate that we have limited the power of
libvirt in terms of the number of backends it can manage when
integrating it into oVirt.<b> </b>Extending to VirtualBox would be
an interesting project, but I'm not sure how valuable it would be.
As a long-time user of VirtualBox I found it to be slower than KVM.
I guess it could allow people to use non-Linux Nodes. Like Dan said,
a lot of work there so the payoff would have to be big enough to
justify it.<br>
<br>
On the other hand, I think it would have far greater impact in terms
of number of use cases/users if we expanded VDSM to manage VMware
ESX. VMware is still arguably the market leader for virtualization.
At the very least, this would then provide a migration path for
anybody wanting to move away from VMware to oVirt (or, perhaps,
visa-versa if we don't do a good enough job with oVirt ;). Since the
Nodes would effectively still be restricted to Linux the task should
be easier than e.g. supporting a Node consisting of
Windows+VirtualBox. As with VirtualBox, there's no SPICE capability
for VMware, so in addition to the VDSM work the User Portal should
be extended to support e.g. VMware Horizon View Client.<br>
<br>
-Bob<br>
<br>
P.S. If we *did* support VirtualBox, the User Portal should be
extended to broker VNC connections since that's one way to connect
to a console with VBox. That wouldn't be a bad project in itself,
and would have value even without VirtualBox.<br>
<br>
</body>
</html>
--------------040400080701000207050401--