On Tue, Oct 16, 2007 at 04:55:16PM -0600, Nick Couchman wrote: > Hmm...so why doesn't using the "--no-dbus" option make a difference? Also, Virt-manager exposes some of its external API via DBus, so that other desktop apps can control virt-manager's UI. The --no-dbus flag merely disables this remote UI control ability. Virt-manager still needs DBus to talk with HAL. > would things be better if I go back to previous versions? Not really, we've been using DBus since day 1. Basically we made a conscious design decision to only support virt-manager on the modern Linux desktop platform, which in practice means approximately Fedora Core 6 vintage or later. There is a lot of development in the Linux desktop arena & to get the best user interaction experiance we need to take advtange of this. RHEL-4 just doesn't cut it as a viable desktop because it is frozen on a application stack more than 2 years old at this point. By all means run servers on RHEL-4, but for desktop applications something more recent is a far better bet. NB, I know until recently you had to run virt-manager on the same host as you are virtualizing, so if you're running Xen on a RHEL-4 host I understand why you'd want to run virt-manager on a RHEL-4 host. We are evolving to the point where virt-manager will be run remotely for all operations - we're 50% there - you can manage existing guests, but not create new guests at this time. Dan, -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| _______________________________________________ et-mgmt-tools mailing list et-mgmt-tools@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/et-mgmt-tools
