Description of problem: i'm really struggling to connect to a remote hypervisor using virt-manager. i've been trying everything. one thing i noticed that's a little irritating usability-wise is that once i create a 'connection' to a remote hypervisor, there is no way to edit it the connection properties after the first connection attempt. for example, i'm trying to set up a connection to a remote hypervisor, and i have no idea which options i should be picking in the 'add connection' dialog so i'm flailing about trying different ones. i dont even know if the hypervisor is xen or kvm (although i think it's xen.) every time i want to try a different option to try to get this thing to connect, i make a new connection. it litters my virt manager screen, and most of them look exactly the same so i can't tell them apart. e.g., my window looks like this: desktop-virthost1.lab.bos.redhat.com (QEMU) desktop-virthost1.lab.bos.redhat.com (QEMU) desktop-virthost1.lab.bos.redhat.com (QEMU) desktop-virthost1.lab.bos.redhat.com (Xen) desktop-virthost1.lab.bos.redhat.com (Xen) desktop-virthost1.lab.bos.redhat.com (Xen) Which options did I choose to make the first different from the second different from the third? I don't have any idea, and I can't view my connection options, I can't edit them either. Ideally I'd really love for there to be an 'edit connection properties' dialog for each remote hypervisor. at the very least let me view them :) Version-Release number of selected component (if applicable): virt-manager-0.8.4-7.el6.noarch How reproducible: very Steps to Reproduce: 1. create a connection to a remote hypervisor, pick kvm/qemu 2. whoops you made a mistake, switch that same connection to be xen 3. frown in sadness as you find out it's not possible :)
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