no longer can create shared network
 

I am running Centos 5.2 x86_64, Xen 3.2.1, and virt-manager 0.5.4.

Ever since I upgraded xen and virt-manager to the newest, I cant seem to
create a new xen pv domU with a shared network device (bridged I guess?).
Nothing shows up in the shared network device list. Heck, even when I try
the default network option, the domU created cant connect to the internet. I
have 3 domU's that I created before this upgrade that seem to work fine. Any
ideas?

Thanks,
Mark

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools

no longer can create shared network
 

Mark Chaney wrote:
> I am running Centos 5.2 x86_64, Xen 3.2.1, and virt-manager 0.5.4.
>
> Ever since I upgraded xen and virt-manager to the newest, I cant seem to
> create a new xen pv domU with a shared network device (bridged I guess?).
> Nothing shows up in the shared network device list. Heck, even when I try
> the default network option, the domU created cant connect to the internet. I
> have 3 domU's that I created before this upgrade that seem to work fine. Any
> ideas?
>
> Thanks,
> Mark
>

Check ~/.virt-manager/virt-manager.log and see if there is a traceback anywhere.
If you pulled down the stock 0.5.4 my guess is you will hit a number of issues
on centos since we use newer dbus calls and rely on updated versions of gtk-vnc
and possibly libvirt.

- Cole

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools

no longer can create shared network
 

You mean something like this?

[Fri, 11 Jul 2008 14:48:02 virt-manager 28541] ERROR (connection:175) Unable
to connect to HAL to list network devices: '%s'dbus_bindings.DBusException
Could not get owner of name 'org.freedesktop.Hal': no such name
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/connection.py", line 155, in
__init__
self.hal_iface.connect_to_signal("DeviceAdded",
self._net_phys_device_added)
File "/usr/lib64/python2.4/site-packages/dbus/_dbus.py", line 291, in
connect_to_signal
self._obj.connect_to_signal(signal_name, handler_function,
dbus_interface, **keywords)
File "/usr/lib64/python2.4/site-packages/dbus/proxies.py", line 151, in
connect_to_signal
path=self._object_path,
File "/usr/lib64/python2.4/site-packages/dbus/_dbus.py", line 179, in
add_signal_receiver
named_service = bus_object.GetNameOwner(named_service,
dbus_interface='org.freedesktop.DBus')
File "/usr/lib64/python2.4/site-packages/dbus/proxies.py", line 25, in
__call__
ret = self._proxy_method (*args, **keywords)
File "/usr/lib64/python2.4/site-packages/dbus/proxies.py", line 102, in
__call__
reply_message = self._connection.send_with_reply_and_block(message ,
timeout)
File "dbus_bindings.pyx", line 455, in
dbus_bindings.Connection.send_with_reply_and_block
DBusException: Could not get owner of name 'org.freedesktop.Hal': no such
name

Also, how in the world can RHEL 5.2 be considered old?


Mark Chaney wrote:
> I am running Centos 5.2 x86_64, Xen 3.2.1, and virt-manager 0.5.4.
>
> Ever since I upgraded xen and virt-manager to the newest, I cant seem to
> create a new xen pv domU with a shared network device (bridged I guess?).
> Nothing shows up in the shared network device list. Heck, even when I try
> the default network option, the domU created cant connect to the internet.
I
> have 3 domU's that I created before this upgrade that seem to work fine.
Any
> ideas?
>
> Thanks,
> Mark
>

Check ~/.virt-manager/virt-manager.log and see if there is a traceback
anywhere.
If you pulled down the stock 0.5.4 my guess is you will hit a number of
issues
on centos since we use newer dbus calls and rely on updated versions of
gtk-vnc
and possibly libvirt.

- Cole

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools

no longer can create shared network
 

Mark Chaney wrote:
> You mean something like this?
>
> [Fri, 11 Jul 2008 14:48:02 virt-manager 28541] ERROR (connection:175) Unable
> to connect to HAL to list network devices: '%s'dbus_bindings.DBusException
> Could not get owner of name 'org.freedesktop.Hal': no such name
> Traceback (most recent call last):
> File "/usr/share/virt-manager/virtManager/connection.py", line 155, in
> __init__
> self.hal_iface.connect_to_signal("DeviceAdded",
> self._net_phys_device_added)
> File "/usr/lib64/python2.4/site-packages/dbus/_dbus.py", line 291, in
> connect_to_signal
> self._obj.connect_to_signal(signal_name, handler_function,
> dbus_interface, **keywords)
> File "/usr/lib64/python2.4/site-packages/dbus/proxies.py", line 151, in
> connect_to_signal
> path=self._object_path,
> File "/usr/lib64/python2.4/site-packages/dbus/_dbus.py", line 179, in
> add_signal_receiver
> named_service = bus_object.GetNameOwner(named_service,
> dbus_interface='org.freedesktop.DBus')
> File "/usr/lib64/python2.4/site-packages/dbus/proxies.py", line 25, in
> __call__
> ret = self._proxy_method (*args, **keywords)
> File "/usr/lib64/python2.4/site-packages/dbus/proxies.py", line 102, in
> __call__
> reply_message = self._connection.send_with_reply_and_block(message ,
> timeout)
> File "dbus_bindings.pyx", line 455, in
> dbus_bindings.Connection.send_with_reply_and_block
> DBusException: Could not get owner of name 'org.freedesktop.Hal': no such
> name
>

Yeah that would do it. I don't know if it would be a simple fix or not:
you can try pulling down the current upstream and see if that produces
any different results. Chances are though that things would require
a bit of backporting to work on the rhel stack.


> Also, how in the world can RHEL 5.2 be considered old?

The entire point of RHEL is a release with a mostly stable set of major
components that is maintained with bug fixes. We don't pull in the latest
and greatest versions of every piece in the stack for an update release.
As a result, dbus in 5.2 is probably just a patched version of dbus from
5.0 (haven't checked) making it essentially over a year old.

- Cole

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools

no longer can create shared network
 

So should I go back to 0.5.3? I figured I should update to 0.5.4 since I am
using the newest version of xen

-----Original Message-----
From: Cole Robinson [mailto:crobinso@redhat.com]
Sent: Sunday, July 13, 2008 4:36 PM
To: Mark Chaney
Cc: 'Fedora/Linux Management Tools'
Subject: Re: [et-mgmt-tools] no longer can create shared network

Mark Chaney wrote:
> You mean something like this?
>
> [Fri, 11 Jul 2008 14:48:02 virt-manager 28541] ERROR (connection:175)
Unable
> to connect to HAL to list network devices: '%s'dbus_bindings.DBusException
> Could not get owner of name 'org.freedesktop.Hal': no such name
> Traceback (most recent call last):
> File "/usr/share/virt-manager/virtManager/connection.py", line 155, in
> __init__
> self.hal_iface.connect_to_signal("DeviceAdded",
> self._net_phys_device_added)
> File "/usr/lib64/python2.4/site-packages/dbus/_dbus.py", line 291, in
> connect_to_signal
> self._obj.connect_to_signal(signal_name, handler_function,
> dbus_interface, **keywords)
> File "/usr/lib64/python2.4/site-packages/dbus/proxies.py", line 151, in
> connect_to_signal
> path=self._object_path,
> File "/usr/lib64/python2.4/site-packages/dbus/_dbus.py", line 179, in
> add_signal_receiver
> named_service = bus_object.GetNameOwner(named_service,
> dbus_interface='org.freedesktop.DBus')
> File "/usr/lib64/python2.4/site-packages/dbus/proxies.py", line 25, in
> __call__
> ret = self._proxy_method (*args, **keywords)
> File "/usr/lib64/python2.4/site-packages/dbus/proxies.py", line 102, in
> __call__
> reply_message = self._connection.send_with_reply_and_block(message ,
> timeout)
> File "dbus_bindings.pyx", line 455, in
> dbus_bindings.Connection.send_with_reply_and_block
> DBusException: Could not get owner of name 'org.freedesktop.Hal': no such
> name
>

Yeah that would do it. I don't know if it would be a simple fix or not:
you can try pulling down the current upstream and see if that produces
any different results. Chances are though that things would require
a bit of backporting to work on the rhel stack.


> Also, how in the world can RHEL 5.2 be considered old?

The entire point of RHEL is a release with a mostly stable set of major
components that is maintained with bug fixes. We don't pull in the latest
and greatest versions of every piece in the stack for an update release.
As a result, dbus in 5.2 is probably just a patched version of dbus from
5.0 (haven't checked) making it essentially over a year old.

- Cole

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools

no longer can create shared network
 

Mark Chaney wrote:
> So should I go back to 0.5.3? I figured I should update to 0.5.4 since I am
> using the newest version of xen
>

Yeah I would recommend just sticking with the virt-manager in 5.2.

- Cole

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools

no longer can create shared network
 

[root@ratchet /]# lshal
error: libhal_ctx_init: (null): (null)
Could not initialise connection to hald.
Normally this mean the HAL daemon (hald) is not running or not ready.
lshal.c 689 : INFO: called LIBHAL_FREE_DBUS_ERROR but dbusError was not set.

-----Original Message-----
From: Cole Robinson [mailto:crobinso@redhat.com]
Sent: Sunday, July 13, 2008 7:05 PM
To: Mark Chaney
Subject: Re: [et-mgmt-tools] no longer can create shared network

Mark Chaney wrote:
> Downgrading didn't seem to make a diff =/
>
> What version of libvirt should I be running?
>
> -----Original Message-----
> From: Cole Robinson [mailto:crobinso@redhat.com]
> Sent: Sunday, July 13, 2008 6:53 PM
> To: Fedora/Linux Management Tools
> Cc: macscr@macscr.com >> Mark Chaney
> Subject: Re: [et-mgmt-tools] no longer can create shared network
>
> Mark Chaney wrote:
>> So should I go back to 0.5.3? I figured I should update to 0.5.4 since I
> am
>> using the newest version of xen
>>
>
> Yeah I would recommend just sticking with the virt-manager in 5.2.
>
> - Cole
>

The stock 5.2 version and you are still getting that error? Does 'lshal'
return anything?

- Cole

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools

no longer can create shared network
 

Mark Chaney wrote:
> [root@ratchet /]# lshal
> error: libhal_ctx_init: (null): (null)
> Could not initialise connection to hald.
> Normally this mean the HAL daemon (hald) is not running or not ready.
> lshal.c 689 : INFO: called LIBHAL_FREE_DBUS_ERROR but dbusError was not set.
>

Okay so virt-manager seems fine, there is just some hal or dbus issue. Try
starting hald like it says, but if that fails for some reason I really can't
help.

- Cole

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools

no longer can create shared network
 

On Sun, Jul 13, 2008 at 03:44:01PM -0500, Mark Chaney wrote:
> You mean something like this?
>
> [Fri, 11 Jul 2008 14:48:02 virt-manager 28541] ERROR (connection:175) Unable
> to connect to HAL to list network devices: '%s'dbus_bindings.DBusException
> Could not get owner of name 'org.freedesktop.Hal': no such name

HAL isn't running - turn it on again.

Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools