Re: [virt-tools-list] [virt-manager PATCH] Add bhyve support

2014-04-07 Thread Roman Bogorodskiy 
  Cole Robinson wrote:

> On 04/04/2014 02:43 PM, Roman Bogorodskiy wrote:
> > Allow connection to bhyve using bhyve:///system URI.
> Patch is fine, but can we find a way to only show this option in the UI where
> it has a chance of actually working (bsd)? 99% of virt-manager users are on
> linux where bhyve isn't available. But I don't know a good way to check. Also
> if we are on bsd maybe we should select Bhyve by default, something to
> consider at least.

As for auto-detection, I plan a follow up patch for that because it
needs a fix not only for bhyve, but also for Qemu for FreeBSD, as
FreeBSD usually has no /usr/bin/qemu, at least if the official
packages/ports are used.

Roman Bogorodskiy


pgp5vjD9yQEyr.pgp
Description: PGP signature
___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [virt-manager PATCH] Add bhyve support

2014-04-07 Thread Daniel P. Berrange 
On Mon, Apr 07, 2014 at 10:24:21AM -0600, Eric Blake wrote:
> On 04/07/2014 09:59 AM, Daniel P. Berrange wrote:
> 
> >>
> >> The more I think about it the more it makes me wonder if we should
> >> learn libvirt return list of all supported/enabled drivers.
> >> Something like:
> >>
> >> char **virGetDrivers(virConnectPtr conn);
> >>
> >> if conn == NULL, the client side drivers are returned, e.g.
> >> {"remote", "vbox", NULL}, if conn is not NULL, the daemon side
> >> drivers are returned, e.g. {"qemu", "bhyve", "lxc", NULL}. But maybe
> >> I'm over thinking it too much.
> > 
> > You have a chicken+egg problem there in that you need to open a connection
> > in order to invoke the API to get the list of connections you can open.
> 
> Although we have been talking about a meta-connection, for doing things
> such as changing log settings, querying how many normal connections are
> open, and so forth.  The management connection could provide this
> information.  On the other hand, the idea of a management connection is
> that is requires different privileges for connecting, so it might not be
> the idea solution.

Yeah I don't think the mgmt connection fits here because of the privilege
level mismatch.

For local nodes we have "NULL" to mean auto-detect.

For remote nodes we do actually support  'remote+tcp://somehost' as a way
to auto-detect the hypervisor, but we don't correctly resolve this into
the real URI once connected (ie virConnectGetURI should return a real
URI, not remote URI)


That all said, I'm not sure I neccessarily agree with Cole's original
proposition that virt-manager shouldn't display "BHyve" as a choice
by default. It feels somewhat discriminatory against FreeBSD to say
that only popular Linux drivers can be visible in the UI by default.

I tend to feel that virt-manager as provided by "upstream" should be
willing to display any libvirt URI by default, providing it is functional
enough for virt-manager to actually work.

If distros wish to cut this back to a subset (eg only KVM + LXC on
Fedora) then that could be done as part of the distro vendor's
packaging.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [virt-manager PATCH] Add bhyve support

2014-04-07 Thread Eric Blake 
On 04/07/2014 09:59 AM, Daniel P. Berrange wrote:

>>
>> The more I think about it the more it makes me wonder if we should
>> learn libvirt return list of all supported/enabled drivers.
>> Something like:
>>
>> char **virGetDrivers(virConnectPtr conn);
>>
>> if conn == NULL, the client side drivers are returned, e.g.
>> {"remote", "vbox", NULL}, if conn is not NULL, the daemon side
>> drivers are returned, e.g. {"qemu", "bhyve", "lxc", NULL}. But maybe
>> I'm over thinking it too much.
> 
> You have a chicken+egg problem there in that you need to open a connection
> in order to invoke the API to get the list of connections you can open.

Although we have been talking about a meta-connection, for doing things
such as changing log settings, querying how many normal connections are
open, and so forth.  The management connection could provide this
information.  On the other hand, the idea of a management connection is
that is requires different privileges for connecting, so it might not be
the idea solution.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature
___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [virt-manager PATCH] Add bhyve support

2014-04-07 Thread Daniel P. Berrange 
On Mon, Apr 07, 2014 at 05:56:25PM +0200, Michal Privoznik wrote:
> On 07.04.2014 17:43, Michal Privoznik wrote:
> >On 07.04.2014 17:12, Cole Robinson wrote:
> >>On 04/04/2014 02:43 PM, Roman Bogorodskiy wrote:
> >>>Allow connection to bhyve using bhyve:///system URI.
> >>>---
> >>>  virtManager/connect.py | 8 ++--
> >>>  1 file changed, 6 insertions(+), 2 deletions(-)
> >>>
> >>>diff --git a/virtManager/connect.py b/virtManager/connect.py
> >>>index b779c75..bc6d56d 100644
> >>>--- a/virtManager/connect.py
> >>>+++ b/virtManager/connect.py
> >>>@@ -32,7 +32,8 @@ from virtManager.baseclass import vmmGObjectUI
> >>>  (HV_QEMU,
> >>>  HV_XEN,
> >>>  HV_LXC,
> >>>-HV_QEMU_SESSION) = range(4)
> >>>+HV_QEMU_SESSION,
> >>>+HV_BHYVE) = range(5)
> >>>
> >>>  (CONN_SSH,
> >>>  CONN_TCP,
> >>>@@ -153,6 +154,7 @@ class vmmConnect(vmmGObjectUI):
> >>>  model.append(["Xen"])
> >>>  model.append(["LXC (Linux Containers)"])
> >>>  model.append(["QEMU/KVM user session"])
> >>>+model.append(["Bhyve"])
> >>>  combo.set_model(model)
> >>>  uiutil.set_combo_text_column(combo, 0)
> >>>
> >>>@@ -364,6 +366,8 @@ class vmmConnect(vmmGObjectUI):
> >>>  hvstr = "xen"
> >>>  elif hv == HV_QEMU or hv == HV_QEMU_SESSION:
> >>>  hvstr = "qemu"
> >>>+elif hv == HV_BHYVE:
> >>>+hvstr = "bhyve"
> >>>  else:
> >>>  hvstr = "lxc"
> >>>
> >>>@@ -385,7 +389,7 @@ class vmmConnect(vmmGObjectUI):
> >>>  hoststr += addrstr + "/"
> >>>
> >>>  uri = hvstr + hoststr
> >>>-if hv == HV_QEMU:
> >>>+if hv in (HV_QEMU, HV_BHYVE):
> >>>  uri += "system"
> >>>  elif hv == HV_QEMU_SESSION:
> >>>  uri += "session"
> >>>
> >>
> >>Patch is fine, but can we find a way to only show this option in the
> >>UI where
> >>it has a chance of actually working (bsd)? 99% of virt-manager users
> >>are on
> >>linux where bhyve isn't available. But I don't know a good way to
> >>check. Also
> >>if we are on bsd maybe we should select Bhyve by default, something to
> >>consider at least.
> >>
> >
> >Well, you can use the driver remotely, I mean,
> >bhyve+ssh:///system even from linux.
> 
> The more I think about it the more it makes me wonder if we should
> learn libvirt return list of all supported/enabled drivers.
> Something like:
> 
> char **virGetDrivers(virConnectPtr conn);
> 
> if conn == NULL, the client side drivers are returned, e.g.
> {"remote", "vbox", NULL}, if conn is not NULL, the daemon side
> drivers are returned, e.g. {"qemu", "bhyve", "lxc", NULL}. But maybe
> I'm over thinking it too much.

You have a chicken+egg problem there in that you need to open a connection
in order to invoke the API to get the list of connections you can open.


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [virt-manager PATCH] Add bhyve support

2014-04-07 Thread Michal Privoznik 

On 07.04.2014 17:43, Michal Privoznik wrote:

On 07.04.2014 17:12, Cole Robinson wrote:

On 04/04/2014 02:43 PM, Roman Bogorodskiy wrote:

Allow connection to bhyve using bhyve:///system URI.
---
  virtManager/connect.py | 8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/virtManager/connect.py b/virtManager/connect.py
index b779c75..bc6d56d 100644
--- a/virtManager/connect.py
+++ b/virtManager/connect.py
@@ -32,7 +32,8 @@ from virtManager.baseclass import vmmGObjectUI
  (HV_QEMU,
  HV_XEN,
  HV_LXC,
-HV_QEMU_SESSION) = range(4)
+HV_QEMU_SESSION,
+HV_BHYVE) = range(5)

  (CONN_SSH,
  CONN_TCP,
@@ -153,6 +154,7 @@ class vmmConnect(vmmGObjectUI):
  model.append(["Xen"])
  model.append(["LXC (Linux Containers)"])
  model.append(["QEMU/KVM user session"])
+model.append(["Bhyve"])
  combo.set_model(model)
  uiutil.set_combo_text_column(combo, 0)

@@ -364,6 +366,8 @@ class vmmConnect(vmmGObjectUI):
  hvstr = "xen"
  elif hv == HV_QEMU or hv == HV_QEMU_SESSION:
  hvstr = "qemu"
+elif hv == HV_BHYVE:
+hvstr = "bhyve"
  else:
  hvstr = "lxc"

@@ -385,7 +389,7 @@ class vmmConnect(vmmGObjectUI):
  hoststr += addrstr + "/"

  uri = hvstr + hoststr
-if hv == HV_QEMU:
+if hv in (HV_QEMU, HV_BHYVE):
  uri += "system"
  elif hv == HV_QEMU_SESSION:
  uri += "session"



Patch is fine, but can we find a way to only show this option in the
UI where
it has a chance of actually working (bsd)? 99% of virt-manager users
are on
linux where bhyve isn't available. But I don't know a good way to
check. Also
if we are on bsd maybe we should select Bhyve by default, something to
consider at least.



Well, you can use the driver remotely, I mean,
bhyve+ssh:///system even from linux.


The more I think about it the more it makes me wonder if we should learn 
libvirt return list of all supported/enabled drivers. Something like:


char **virGetDrivers(virConnectPtr conn);

if conn == NULL, the client side drivers are returned, e.g. {"remote", 
"vbox", NULL}, if conn is not NULL, the daemon side drivers are 
returned, e.g. {"qemu", "bhyve", "lxc", NULL}. But maybe I'm over 
thinking it too much.


Michal

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [virt-manager PATCH] Add bhyve support

2014-04-07 Thread Michal Privoznik 

On 07.04.2014 17:12, Cole Robinson wrote:

On 04/04/2014 02:43 PM, Roman Bogorodskiy wrote:

Allow connection to bhyve using bhyve:///system URI.
---
  virtManager/connect.py | 8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/virtManager/connect.py b/virtManager/connect.py
index b779c75..bc6d56d 100644
--- a/virtManager/connect.py
+++ b/virtManager/connect.py
@@ -32,7 +32,8 @@ from virtManager.baseclass import vmmGObjectUI
  (HV_QEMU,
  HV_XEN,
  HV_LXC,
-HV_QEMU_SESSION) = range(4)
+HV_QEMU_SESSION,
+HV_BHYVE) = range(5)

  (CONN_SSH,
  CONN_TCP,
@@ -153,6 +154,7 @@ class vmmConnect(vmmGObjectUI):
  model.append(["Xen"])
  model.append(["LXC (Linux Containers)"])
  model.append(["QEMU/KVM user session"])
+model.append(["Bhyve"])
  combo.set_model(model)
  uiutil.set_combo_text_column(combo, 0)

@@ -364,6 +366,8 @@ class vmmConnect(vmmGObjectUI):
  hvstr = "xen"
  elif hv == HV_QEMU or hv == HV_QEMU_SESSION:
  hvstr = "qemu"
+elif hv == HV_BHYVE:
+hvstr = "bhyve"
  else:
  hvstr = "lxc"

@@ -385,7 +389,7 @@ class vmmConnect(vmmGObjectUI):
  hoststr += addrstr + "/"

  uri = hvstr + hoststr
-if hv == HV_QEMU:
+if hv in (HV_QEMU, HV_BHYVE):
  uri += "system"
  elif hv == HV_QEMU_SESSION:
  uri += "session"



Patch is fine, but can we find a way to only show this option in the UI where
it has a chance of actually working (bsd)? 99% of virt-manager users are on
linux where bhyve isn't available. But I don't know a good way to check. Also
if we are on bsd maybe we should select Bhyve by default, something to
consider at least.



Well, you can use the driver remotely, I mean, 
bhyve+ssh:///system even from linux.


Michal

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [virt-manager PATCH] Add bhyve support

2014-04-07 Thread Cole Robinson 
On 04/04/2014 02:43 PM, Roman Bogorodskiy wrote:
> Allow connection to bhyve using bhyve:///system URI.
> ---
>  virtManager/connect.py | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/virtManager/connect.py b/virtManager/connect.py
> index b779c75..bc6d56d 100644
> --- a/virtManager/connect.py
> +++ b/virtManager/connect.py
> @@ -32,7 +32,8 @@ from virtManager.baseclass import vmmGObjectUI
>  (HV_QEMU,
>  HV_XEN,
>  HV_LXC,
> -HV_QEMU_SESSION) = range(4)
> +HV_QEMU_SESSION,
> +HV_BHYVE) = range(5)
>  
>  (CONN_SSH,
>  CONN_TCP,
> @@ -153,6 +154,7 @@ class vmmConnect(vmmGObjectUI):
>  model.append(["Xen"])
>  model.append(["LXC (Linux Containers)"])
>  model.append(["QEMU/KVM user session"])
> +model.append(["Bhyve"])
>  combo.set_model(model)
>  uiutil.set_combo_text_column(combo, 0)
>  
> @@ -364,6 +366,8 @@ class vmmConnect(vmmGObjectUI):
>  hvstr = "xen"
>  elif hv == HV_QEMU or hv == HV_QEMU_SESSION:
>  hvstr = "qemu"
> +elif hv == HV_BHYVE:
> +hvstr = "bhyve"
>  else:
>  hvstr = "lxc"
>  
> @@ -385,7 +389,7 @@ class vmmConnect(vmmGObjectUI):
>  hoststr += addrstr + "/"
>  
>  uri = hvstr + hoststr
> -if hv == HV_QEMU:
> +if hv in (HV_QEMU, HV_BHYVE):
>  uri += "system"
>  elif hv == HV_QEMU_SESSION:
>  uri += "session"
> 

Patch is fine, but can we find a way to only show this option in the UI where
it has a chance of actually working (bsd)? 99% of virt-manager users are on
linux where bhyve isn't available. But I don't know a good way to check. Also
if we are on bsd maybe we should select Bhyve by default, something to
consider at least.

- Cole

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [virt-viewer 2/3] man: Fix link to GPLv2 text

2014-04-07 Thread Christophe Fergeau 
On Fri, Apr 04, 2014 at 10:03:17AM -0600, Eric Blake wrote:
> On 04/04/2014 06:52 AM, Christophe Fergeau wrote:
> > The unversionned http links point to the GLPv3 text while virt-viewer is
> > still licensed under the GPLv2.
> > ---
> >  man/remote-viewer.pod | 4 ++--
> >  man/virt-viewer.pod   | 4 ++--
> >  2 files changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/man/remote-viewer.pod b/man/remote-viewer.pod
> > index baa78c5..fedbcf0 100644
> > --- a/man/remote-viewer.pod
> > +++ b/man/remote-viewer.pod
> > @@ -285,8 +285,8 @@ Report bugs to the mailing list 
> > C >  
> >  Copyright (C) 2012-2014 Red Hat, Inc., and various contributors.
> >  This is free software. You may redistribute copies of it under the terms 
> > of the GNU General
> > -Public License C. There is NO 
> > WARRANTY, to the extent
> > -permitted by law.
> > +Public License C. 
> > There is NO WARRANTY,
> > +to the extent permitted by law.
> 
> The link still works (and looks better) if you s;old-licenses/;;

Ah thanks, I've now changed these links to the better looking version.

Christophe


pgpwJFzaZ4Bun.pgp
Description: PGP signature
___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

[virt-tools-list] [virt-viewer] man: Use nicer link to GPLv2

2014-04-07 Thread Christophe Fergeau 
As pointed out by Eric Blake,
https://www.gnu.org/licenses/gpl-2.0.html and
https://www.gnu.org/licenses/old-licenses/gpl-2.0.html
both point to the same location, with the former being nicer to read.
---
Pushed under the trivial rule.

Christophe


 man/remote-viewer.pod | 2 +-
 man/virt-viewer.pod   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/man/remote-viewer.pod b/man/remote-viewer.pod
index 10ed1ba..72d950a 100644
--- a/man/remote-viewer.pod
+++ b/man/remote-viewer.pod
@@ -285,7 +285,7 @@ Report bugs to the mailing list 
C. 
There is NO WARRANTY,
+Public License C. There is NO 
WARRANTY,
 to the extent permitted by law.
 
 =head1 SEE ALSO
diff --git a/man/virt-viewer.pod b/man/virt-viewer.pod
index 3944f18..7127e5f 100644
--- a/man/virt-viewer.pod
+++ b/man/virt-viewer.pod
@@ -153,7 +153,7 @@ Report bugs to the mailing list 
C. 
There is NO WARRANTY,
+Public License C. There is NO 
WARRANTY,
 to the extent permitted by law.
 
 =head1 SEE ALSO
-- 
1.9.0

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list