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--