Bug 617386

This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **

This wasn't as straightforward as initially anticipated, so since it isn't upstream yet, deferring to 6.2

Thinking about this some more.

The main info that decides what a libvirt connection is actually 'connecting'
to is the hypervisor choice, hostname, and system vs. session instance.
Allowing the user to change any of that, changes what we are actually 'connecting' to. It's not a rename, it's changing the existing connection row to point to something totally different.

So I don't think we want to allow users to change these values for an
existing connection. Really the only use case I can think of for the
feature is the situation you found yourself in, so effort is probably better
spent trying to prevent users from ever getting into that pickle.

Here are the stumbling blocks you originally encountered:

- Open conn dialog itself was pretty crappy. this was improved in 6.1
    thanks to your other bz:
    https://bugzilla.redhat.com/show_bug.cgi?id=617391

- impossible to distinguish between multiple similar connections
    in main manager window. also fixed in 6.1 thanks to another of your
    bz reports:
    https://bugzilla.redhat.com/show_bug.cgi?id=617389
    way it works is we try to ensure that no 2 rows have the same desc,
    by sticking in auth method, user name, and/or more of the hostname
    if two rows would collide.

- you didn't know what hypervisor you were connecting to, or what
    auth mechanism to choose. right now we don't offer much help for this
    in virt-manager. there are some possibilities though

    1)  libvirt hosts already advertise themselves over avahi. maybe we can
        extend the info is advertises to list hypervisors available on the host.
        we can then try and use this info in the 'open connection' dialog to
        limit the options. While this will help in some cases, avahi is
        blocked by default fedora/RHEL firewall policy, and only really works
        on a local network. Also I don't think we could advertise auth
        mechanisms reliably due to technical reasons

   2)   libvirt has a notion of a default URI, where it chooses the default HV
        for us. even works in the remote case if you know the auth mechanism
        ahead of time.

        problem with this in the local case is that virt-manager users
        don't want the default, since for qemu that's the session instance
        which is kind of crippled for various reasons. However, libvirt needs
        to use that as the default since for many configurations a regular
        user will not be able to connect to the qemu 'system' instance.

        so unless we had a way of telling libvirt "choose a default but only
        from these few acceptable options", we have to make the user manually
        choose the HV, or use our limited probing capabilities to guess a
        default.

        those issues also apply to the remote default case, but less of an
        issue since /session uris don't work remotely (virt-manager may
        still want to filter possible defaults since it's only tested with
        a few hypervisors). another issue is that some old libvirt doesn't
        accept this syntax (first release was Dec 2008). also virt-manager
        would have to reconstruct a stable URI after connecting so we
        don't always just use 'remote://' syntax, but that's solvable.

    Bottom line for this problem is that there are some possible things
    here we can do to help out the user, but probably won't ever be able
    to get it perfect.

So, after all that, conclusion is that the major issues you originally
encountered are already solved in RHEL6, I don't think it's a good idea to
allow editing HV of an 'existing' connection, but there are some possible
things we can explore to make this situation better.

I've opened a bug against upstream libvirt for exposing HV options over
avahi: https://bugzilla.redhat.com/show_bug.cgi?id=725262

I'm moving this one to the upstream virt-manager tracker to explore using
the 'default' remote URIs.

Hi Cole,

Thanks for the detailed summary! Just a quick question, re:

==========

"The main info that decides what a libvirt connection is actually 'connecting'
to is the hypervisor choice, hostname, and system vs. session instance.
Allowing the user to change any of that, changes what we are actually
'connecting' to. It's not a rename, it's changing the existing connection row
to point to something totally different.

"So I don't think we want to allow users to change these values for an
existing connection."

==========

Can you actually have multiple hypervisors running on the same host? Is that a common case? 

I understand that https://bugzilla.redhat.com/show_bug.cgi?id=617389 now fills in additional info on each row so you can distinguish between them -- but I'm just wondering why you would ever want multiple rows of settings for the same host there (again assuming you wouldn't have more than one hypervisor on one host.) The only answer I can think of is if you had multiple user accounts on the hypervisor, but I'm not sure why you would or that it would be all that common. If you did have multiple accounts, you'd clearly want separate connections, but... I think you'd always want to edit. What if you typo'ed your username or the hostname? Delete & create from scratch seems a harsh price to pay?

Maybe, to eliminate typos, and to eliminate the need to want to edit, test the connection before saving out the settings, giving the user a change to edit and test again?

Just a thought. Not sure if it helps.

(In reply to comment #6)
> Hi Cole,
> 
> Thanks for the detailed summary! Just a quick question, re:
> 
> ==========
> 
> "The main info that decides what a libvirt connection is actually 'connecting'
> to is the hypervisor choice, hostname, and system vs. session instance.
> Allowing the user to change any of that, changes what we are actually
> 'connecting' to. It's not a rename, it's changing the existing connection row
> to point to something totally different.
> 
> "So I don't think we want to allow users to change these values for an
> existing connection."
> 
> ==========
> 
> Can you actually have multiple hypervisors running on the same host? Is that a
> common case? 
> 

Definitely not a common case, but not impossible. While xen and kvm don't mix, xen and plain qemu can, and LXC is available on any modern linux machine built into the kernel.

In the localhost case, users may want to do qemu:///system and qemu:///session at the same time once qemu:///session is more functional (but we could special case localhost).

I get what you're saying though, in most cases users shouldn't need multiple connections to the same host. Maybe if the user is trying to do 'open connection' to a host that already has a connection populated, we show a checkbox in the dialog saying 'replace existing connection to $HOSTNAME', activated by default.

> I understand that https://bugzilla.redhat.com/show_bug.cgi?id=617389 now fills
> in additional info on each row so you can distinguish between them -- but I'm
> just wondering why you would ever want multiple rows of settings for the same
> host there (again assuming you wouldn't have more than one hypervisor on one
> host.) The only answer I can think of is if you had multiple user accounts on
> the hypervisor, but I'm not sure why you would or that it would be all that
> common. If you did have multiple accounts, you'd clearly want separate
> connections, but... I think you'd always want to edit. What if you typo'ed your
> username or the hostname? Delete & create from scratch seems a harsh price to
> pay?
> 
> Maybe, to eliminate typos, and to eliminate the need to want to edit, test the
> connection before saving out the settings, giving the user a change to edit and
> test again?
> 

I think that's a good idea: we should try to connect, if it fails, remove the connection and drop the user back into the connection dialog.

> Just a thought. Not sure if it helps.

very helpful, thanks!

Fixed upstream now