Re: [ovirt-users] USB 2.0 compatibility -- RESOLVED!
On Thu, Feb 9, 2017 at 3:24 AM Yedidyah Bar Davidwrote: > [...] > > Would you like to open an RFE and suggest a new arrangement for the UI, > and push a doc update to the website? I would, but I felt uncomfortable doing that, as I'm still an oVirt newb. I thought perhaps I legitimately missed this somewhere. I'll peruse the doc organization to see where I think this makes sense, and I'll certainly do that and the RFE. Thanks. Jonathan -- Sent from my Commodore64 ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] USB 2.0 compatibility -- RESOLVED!
I was finally able to resolve this. So that maybe other users can find how to fix this if they run into the same issues: tl;dr: Edit the virtual machine in question, go under Console, make sure SPICE is chosen for graphics, and under "USB Redirection" choose "Native." When you reboot the VM, it will have both UHCI and EHCI (2.0) controllers. Now, any USB 2.0 devices that you attach will work correctly. Long version: I struggled with this for quite a while. While doing some additional research, I found a note in the 4.1.0 release notes referencing BZ 1373223. This particular note was for ppc64 architecture systems, but it curiously said that enabling USB Redirection under SPICE would change the USB controllers available on the host. I dug a little deeper into the bug thread and found a couple of references that seemed to indicate that x86/x86_64 exhibited the same behavior. Apparently, UHCI (1.1) is the default because it supports SmartCards, but the EHCI (2.0) controller does not. So, turning on USB Redirection under SPICE settings for the console enables an EHCI controller, thereby enabling devices that require USB 2.0. Personal opinion: This is really obfuscated. It would be great if this switch lived somewhere more obvious. Even if that doesn't happen, this should exist in a document somewhere. Maybe it does and I couldn't find it, but I tried! jonathan -- Jonathan Woytek http://www.dryrose.com KB3HOZ PGP: 462C 5F50 144D 6B09 3B65 FCE8 C1DC DEC4 E8B6 AABC ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[ovirt-users] USB 2.0 compatibility
Hello all. Please forgive me if this is covered officially somewhere, but my google-fu has been unable to help me find much recent information. I have a couple of devices (RTL SDR's) that require USB 2.0, but the pass through seems to only support a virtual 1.1 hub for devices. The devices are correctly recognized and configured by the hypervisor host, but when connected to a VM, they show up on a 1.1 hub, and the driver fails to load as a result. I have found some older information that only USB 1.1 devices were supported via USB pass through. I haven't found much newer information, though, and also couldn't find newer problem reports. I'm running 4.1, upgraded from a 4.0 installation, on Centos 7. I was hoping to build a little RF capture and analysis cluster using several of these devices, but this is a bit of a roadblock! Any ideas? Jonathan -- Sent from my Commodore64 ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] oVirt Hosted Engine Deployment Issues (and fixed!)
I've made some headway on this last night. Since I'm bootstrapping a new network here, there are some temporary patches in place that will go away once virtualization is running and some additional services can be spun up. Nameservice is one of those temporary patches, as is inter-network routing. I could dig queries on the host where I was deploying the hosted engine, so I thought all was well. The hosted engine lives on a different network, though, and I thought all of the routes were in place for it to get to nameservice, but I found one missing this morning. The error messages for these have made a lot more sense, though, so that makes life easier! jonathan On Fri, Dec 2, 2016 at 8:28 AM, Tom Gamull <tgam...@redhat.com> wrote: > I had some similar issues (also with IPV6 which I haven’t retried > lately). I ended up double checking /etc/resolv.conf and just dropping an > entry there and also ensuring the name servers were present in the ifcfg > files. This did the trick. Depending on how you configure LACP, sometimes > the DNS seems to magically disappear when ovirt creates the ovirtmgmt > bridge interface. If you are having an issue, it’s likely that interface. > > The other thing that “may” be occurring is IPv6 is being used for DNS and > you don’t have an IPv6 DNS server (or it’s not routing correctly). You can > verify that by disabling IPv6 (you have to use sysctl, ifcfg options won’t > completely do it). If that works, then IPv6 was the issue. > > Tom > > On Dec 2, 2016, at 4:18 AM, Simone Tiraboschi <stira...@redhat.com> wrote: > > > > On Fri, Dec 2, 2016 at 3:11 AM, Jonathan Woytek <woy...@dryrose.com> > wrote: > >> Hello all. I've been trying to get a hosted-engine style deployment up >> and running on a small three-hypervisor cluster for prototyping some things >> before they get moved into a production environment. My hypervisors each >> have a 802.3ad bonded interface with several VLANs trunked over the link. >> The network is not currently connected to the internet, but can be for >> updates and the like. There is DNS available and correctly configured. >> >> I struggled for a few days trying to get the hosted engine to deploy >> correctly. Some issues I encountered were minor documentation issues (and >> mostly just me misinterpreting something that was written). For example, >> when choosing an image source, I could choose cdrom, file, or something >> else, and I tried to choose file (thinking "image file", since I had an ISO >> to use for building the engine vm). Of course, it would bomb because it >> wanted me to give it a preconfigured engine file, NOT an ISO. I eventually >> figured I'd just get the appliance engine file, and went that route (and, >> in that case, that part worked!). >> >> Then, it started to bomb consistently right after starting the network >> configuration step. It turned out that the motherboards I had (Supermicro) >> did not have UUIDs encoded on them--they were blank. As a result, the vdi >> step was failing to gather the information it needed, but it kept dying >> with error messages that were pretty difficult to decipher. I eventually >> stumbled across the UUID as "None" in the return block, which finally led >> me to dmidecode to verify that the UUID was blank. Then I had to figure out >> how to actually get the UUID set. I found an AMI utility that helped me get >> them set to something, though it didn't actually set them correctly. In the >> meantime, Supermicro helpfully replied to my support request with a link to >> a utility they provide to do the same thing (though I wish that had been >> documented somewhere on their site!). >> >> UUIDs finally set, I started to work through a few other issues, and >> finally came to the point where it was gathering some network information >> before going to do the next step, and now it kept dying saying that the >> hostname was not unique, then it listed every IP address configured on the >> system (and there were several). DNS was working, and pointed to the >> correct IP address for the hostname. The hostname was set correctly. I >> could not get this to resolve. I got frustrated and posted on twitter. A >> few nice people here saw it and recommended that I join the mailing list. >> That's why I'm here now. >> >> Before I posted here, though, I wanted to try again when I was fresh and >> not having dealt with all of the previous problems. My first attempt was to >> drop the hostname into /etc/hosts, thinking maybe the install wasn't >> consulting DNS or was confused because there were several IP addresses. >> >> BINGO. This fixe
[ovirt-users] oVirt Hosted Engine Deployment Issues (and fixed!)
Hello all. I've been trying to get a hosted-engine style deployment up and running on a small three-hypervisor cluster for prototyping some things before they get moved into a production environment. My hypervisors each have a 802.3ad bonded interface with several VLANs trunked over the link. The network is not currently connected to the internet, but can be for updates and the like. There is DNS available and correctly configured. I struggled for a few days trying to get the hosted engine to deploy correctly. Some issues I encountered were minor documentation issues (and mostly just me misinterpreting something that was written). For example, when choosing an image source, I could choose cdrom, file, or something else, and I tried to choose file (thinking "image file", since I had an ISO to use for building the engine vm). Of course, it would bomb because it wanted me to give it a preconfigured engine file, NOT an ISO. I eventually figured I'd just get the appliance engine file, and went that route (and, in that case, that part worked!). Then, it started to bomb consistently right after starting the network configuration step. It turned out that the motherboards I had (Supermicro) did not have UUIDs encoded on them--they were blank. As a result, the vdi step was failing to gather the information it needed, but it kept dying with error messages that were pretty difficult to decipher. I eventually stumbled across the UUID as "None" in the return block, which finally led me to dmidecode to verify that the UUID was blank. Then I had to figure out how to actually get the UUID set. I found an AMI utility that helped me get them set to something, though it didn't actually set them correctly. In the meantime, Supermicro helpfully replied to my support request with a link to a utility they provide to do the same thing (though I wish that had been documented somewhere on their site!). UUIDs finally set, I started to work through a few other issues, and finally came to the point where it was gathering some network information before going to do the next step, and now it kept dying saying that the hostname was not unique, then it listed every IP address configured on the system (and there were several). DNS was working, and pointed to the correct IP address for the hostname. The hostname was set correctly. I could not get this to resolve. I got frustrated and posted on twitter. A few nice people here saw it and recommended that I join the mailing list. That's why I'm here now. Before I posted here, though, I wanted to try again when I was fresh and not having dealt with all of the previous problems. My first attempt was to drop the hostname into /etc/hosts, thinking maybe the install wasn't consulting DNS or was confused because there were several IP addresses. BINGO. This fixed the "not unique" address problem! ... now I just had to go and clean up a botched installation because it also couldn't find the hostname for the hosted engine (also in DNS, but I just put it in /etc/hosts to hopefully get around whatever issue that is). So.. long story short.. Thanks for good software and for being so willing to support it, and thanks for putting up with reading this whole thing. Now, if someone can explain why DNS isn't being consulted for host names correctly, that would be super... :) jonathan -- Jonathan Woytek http://www.dryrose.com KB3HOZ PGP: 462C 5F50 144D 6B09 3B65 FCE8 C1DC DEC4 E8B6 AABC ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users