Re: Cannot get sound in Qemu/KVM vm
On Tue, May 09, 2023 at 03:14:14PM -0700, Unknown wrote: > Hello. I have a Parabola linux x64 host and a Parabola Linux 32-bit > guest. Parabola is an Arch-based distro. I also have a Windows 7 x64 > guest that lacks audio. > > lspci in the > host tells me that I have an Intel 100 Series/C230 Series Chipset > Family HD Audio Controller and an NVIDIA GM107 High Def Audio > Controller. > Perhaps it will clarify things if you use the following command in the host system to see which of them you are actually using: pactl list short sinks Ideally, do that for both headphones and whatever else you are using to hear the audio. My point is that you seem to have at least two HDMI audio output devices, and perhaps one or two analogue outputs. > The host always has sound. The guest used to have sound, but I'd > continually lose sound after a few days until I restarted the VM. Then > the guest lost sound completely; I don't know why. Media players, > youtube videos, etc. seem to play normally, but I simply cannot hear > anything, with or without headphones. Alsa and pulseaudio are installed > in the guest. > I note that 'headphones' usually means the sort you plug in to a 2.5mm (described as 1/8" in America) socket, but there are variations. And 'without headphones' *could* be a different output (e.g. analogue audio to headphones, HDMI audio to a TV). Now please try thati pactl command in the linux guest (*with* pulseaudio installed). You can select a specific sink from the available sinks with pacmd set-default-sink > I've tried setting QEMU_AUDIO_DRV (to alsa) on the host. I've tried > all of the sound device settings in libvirt (ICH6, ICH9, and AC97). > I've tried deleting pulseaudio from the guest. I've tried maxing out the > volume on both the guest (with alsamixer and pavucontrol) and the host > (with alsamixer). > Alsa tends to be problematic because it can "own" the audio and prevent other applications producing sound. From time to time on a non-qemu host I've recently lost audio after suspend, but listing and setting the sinks has restored it. Worst case it may be necessary to stop and start an application (killall -HUP whatever). > Any suggestions? I have read that audio is some sort of ongoing problem > with KVM. Is this true? > It certainly used to be, but I've been too busy on other things (and short of disk space) to try recent versions of qemu. I think I had working audio with pulse in host and client a year or so ago, but I'm not 100% sure. The AC97 controller on real hardware was ancient, seems unlikely to be what is needed unless the guest is really old linux. For variants of HDMI (ICH6, ICH9 I suppose) I tend to enable *all* of the kernel HDMI variations in a linux guest. I will suggest that getting sound working in the linux guest is the first step (you might need to compile your own kernel). For a Windows 7 64-bit guest I'm afraid I have no idea what would be required. ĸen -- ARTHUR: I am your king! WOMAN: Well, I didn't vote for you. -- Monty Python and The Holy Grail
Re: Unpredictable performance degradation in QEMU KVMs
On Tue, Oct 05, 2021 at 06:58:51PM -0500, Parnell Springmeyer wrote: > Hi, we use QEMU VMs for running our integration testing infrastructure and > have run into a very difficult to debug problem: occasionally we will see a > severe performance degradation in some of our QEMU VMs. > > We've tried tuning our QEMU VMs (a long time ago) but we still have this > issue. Is this something anyone has experience with and I'm just not > finding it via Google? Or could someone recommend some troubleshooting > steps? > I can't answer the question (my qemu experience is limited to x86_64 linux running x86_64 linux guests, I think that relative runtimes in the guests are usually degraded by the overhead of running in qemu). And yes, finding the right search terms can be difficult. But some questions which might help elucidate information : 1. What guest OS and architecture, and what host OS and architecture ? 'linux' is good enough for OS if that is what you are using, I doubt distro variations make much difference, but running different OS's on guests, and particularly running incompatible architectures such as aarch64 on x86_^4, will add overheads which probably vary according to exactly what the VM is running. 2. Are you running multiple guest instances on the same host(s) ? 3. If you are running multiple guests on each host, do your hosts have enough cores ? I have read that specifying more cores for the guest than are actually available is possible, but that doesn't sound like a recipe for performance. Of course, if your guests are externally-connected servers running real (but different) loads then I guess overspecifying the number of cores for each will often be beneficial if their peak loads do not coincide. For C-I tests with random build jobs, that might not be such a good idea if ninja or cargo are used (those will try to use N+2 CPUs if you have multiple cores - 4 or more, from memory). ĸen -- We had to carve each 0 and 1 on separate granite wheelbarrows and then carry them on our backs, neck-deep in the snow uphill both ways and with a wolf nailed to our skull to keep us warm! -- 'JockTroll' on slashdot
copy and paste in qemu-6.1.0 without spice ?
In https://www.kraxel.org/blog/2021/05/qemu-cut-paste/ I read that qemu-6.1.0 will have copy+paste, similar to what spice has had, but that it is turned off by default. That article has references to the new files, and I can see that they have been compiled in my 6.1.0 build. It also says that copy+paste is turned off by default for security reasons. There is an example of how to replace the spice c+p with the new-style, adding -chardev qemu-vdagent,id=ch1,name=vdagent,clipboard=on to the invocation of qemu. But when I add that I get: qemu-system-x86_64: -chardev qemu-vdagent,id=ch1,name=vdagent,clipboard=on: 'qemu-vdagent' is not a valid char driver name Looking at the 6.1.50 docs (is that a development w-i-p version?) the only mention of paste in the invocation section is as an option for spice to turn off disable-copy-paste. So, can this be used without spice in the current rlease, and if so, what option should I use to enable copy+paste, please ? ĸen -- I drew a gun. He drew a gun. I drew another gun. Soon we were surrounded by lovely drawings of guns. -- Chic Murray
Re: building dif. target system using qemu suit - Update.
On Sun, Sep 05, 2021 at 08:24:08PM +0200, Frans de Boer wrote: > On 9/4/21 10:31, Frans de Boer wrote: > > LS, > > > > When I use qemu-aarch64to start a chroot jail and within the jail use > > qemu-aarch64-binfmt to cope with the different binary file headers, I > > can't use bash properly. > > > > That is, the -r and -x flags do not give the normal response. I tested > > also with -a, -d, -f, -e and -s, and they worked as expected. This > > behavior stops me from building a new (aarch64) system on a x86_64 build > > system. Within the chroot jail, I can start programs, run (bash) scripts > > as long as these scripts do not use the -r and -x tests. There are maybe > > more tests not working or just working, but these are the ones I tested. > > > > Normally, one would use a build system with the same target > > architecture, but that implies that you already have a target system up > > and running. Qemu with binfmt sounded as a possible solution, but as > > reported above, that seems not the case any longer. > > > > But maybe I do something wrong and thus seek advice how to proceed from > > here. > > > > Regards, Frans. > Tried the same with ppc64, same bad results. > > Frans. Frans, I assume you mean 'test -r ' and 'test -x ' ? I've never used qemu for compiling a different arch, but I guess that you have some version of both 'ls' and 'ldd' ? Perhaps, running 'ls -l' against a file which does exist but fails the '-r' test, and 'ldd' against a file which is present and excepted to be executable (and not a script) might provide you with clues. ĸen -- +++ Divide By Cucumber Error. Please Reinstall Universe And Reboot +++ - Hogfather
Re: image works in native but not in vm when -cpu is set to host
On Sat, Nov 28, 2020 at 02:09:41AM +0200, Nerijus Baliunas via wrote: > On Fri, 27 Nov 2020 23:17:52 +0000 Ken Moffat via > wrote: > > > > > Please provide them by text here, the link does not work. Regards, > > > > Nerijus > > > > You didn't ask the other question (details of the panic: might be > > missing driver, might be invalid opcode as far as qemu is concerned, > > might be something else entirely. > > I did. I don't know why OP did not provide them yet. > > Regards, > Nerijus Sorry, I can't type. What I meant to write was "You didn't *answer* the other question." (and 'You' was for the OP). ĸen -- Internal error in fortune program: fnum=2987 n=45 flag=1 goose_level=-232323 Please write down these values and notify fortune program admin.
Re: image works in native but not in vm when -cpu is set to host
On Fri, Nov 27, 2020 at 11:17:37PM +0100, daggs wrote: > Greetings Nerijus, > > > Sent: Friday, November 27, 2020 at 11:34 AM > > From: "Nerijus Baliunas via" > > To: qemu-discuss@nongnu.org > > Subject: Re: image works in native but not in vm when -cpu is set to host > > > > Please provide them by text here, the link does not work. Regards, Nerijus You didn't ask the other question (details of the panic: might be missing driver, might be invalid opcode as far as qemu is concerned, might be something else entirely. I'll note that I've never tried to boot an image natively and then try to run it in qemu, I've always assumed that optimising for the real host and then for whatever qemu provides are likely to give slightly different results (and when I've used qemu, the partitioning has been very different from the real system). But one difference between the two in what I'm replying to: > here: > vm: > Architecture:x86_64 > CPU op-mode(s): 32-bit, 64-bit > Byte Order: Little Endian > Address sizes: 40 bits physical, 48 bits virtual ^^ vs > native: > Architecture:x86_64 > CPU op-mode(s): 32-bit, 64-bit > Byte Order: Little Endian > Address sizes: 39 bits physical, 48 bits virtual ^^ I haven't looked at the physical size recently, but it does seem to be very machine-specific. On my ryzen+ laptop where I'm typing this, physical is 43 bits on linux-5.8. ĸen -- Internal error in fortune program: fnum=2987 n=45 flag=1 goose_level=-232323 Please write down these values and notify fortune program admin.
Re: uninstalling
On Sat, Sep 12, 2020 at 10:18:49AM +0200, gunnar.wagner wrote: > now when that is clarified can we suggest any solution? > > @Narcis Garcia ... can you tell us more about your the operating system > your computer is running on? what may help us to suggest a possible > solution. > Umm, it was Liz C who has the problem. Sounds like a windows 64-bit file, so probably windows 10. I see that Liz uses gmail, so not Cc'ing becasue my post will probably end up marked as spam - with luck, sending via the lsit might get through. Google found https://itsafety.net/report/20190802-77d29db5357775b675b0bbe7f4184b61-host-services-64-exe_process-partofthreat but that links to some tool for removing thins - probably legitimate, but I have no idea and there is always the possibility that it is itself compromised. See also https://www.file.net/process/host%20services%20x64.exe.html which has a link to what is (I hope) the same anti-malware tool, and to Security Test Manager which will apparently tell you what that runing Host Services is actually doing. Again, I have no idea if that S T M is legitimate. Oh, I suppose that for windows 10, trying to run a download will at least tell you who signed it. ĸen > > > On 12.09.20 06:09, Christopher William Snowhill wrote: > > It sounds as if the user has installed a trojan monero miner, either > > through not updating their machine like is recommended, or from > > installing pirated audio production software from bittorrent trackers > > or shady web sites, which have been bundling such miner virtual > > machines for at least two years now. They boot a Linux virtual machine > > that gobbles up at least an entire cpu core mining for an anonymous > > pool, and therefore probably isn't traceable. It used to be that the > > variant, LoudMiner, used qemu with hvf on macOS, and VirtualBox on > > Windows, but now it seems variants are branching out to using qemu > > with intel haxm on Windows machines. > > > > On Fri, Sep 11, 2020, at 2:09 AM, Narcis Garcia via wrote: > >> How is "Host services 64.exe" related to Qemu? > >> > >> > >> > >> Narcis Garcia > >> El 10/9/20 a les 20:51, Liz C ha escrit: > >> > Hi. > >> > I’ve never installed your app but I have it in my computer (I don’t > >> > know why). My antivirus says that Host services 64.exe is a troyan > >> > virus. I uninstalled it many times and deleted everything but it keeps > >> > showing after a few days. How can I deleted forever? I don’t have > >> > nothing against you but I don’t want this app. > >> > Hope you can help me! > >> > Liz > >> -- I could not live without Champagne. In victory I deserve it, in defeat I need it. -- Churchill
Re: Probs on Windows Host
On Sat, Nov 02, 2019 at 11:18:34AM -0700, Johny Why wrote: > hi > > getting some issues with qemu running arch-linux guest on a windows 10 host. > - unexpected ram size > - no eth0 > - no internet connection > For the eth0 question - > archlabs live iso boots, and says: > `-> ram: 47mb` > Why not 600M? > > > ip link > 1: lo 2. ens3 > Why no eth0? > For machines with potentially several interfaces, somebody decided to give predicatable names, see e.g. https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ This is normal on most current distros. On the desktop machine where I'm typing this the single i/f is enp8s0. > Attempting to enable wifi with: > ``` > systemctl enable dhcpcd@ens3.service > systemctl start dhcpcd@ens3.service > https://bbs.archlinux.org/viewtopic.php?pid=1182093 > ``` > No errors, but pinging google.com fails with "0 received". > That is not the wifi, it is the wired ethernet. If qemu finds a wireless interface it will have a name starting 'wl'. > any suggestions? > thx ĸen -- Whilst all mushrooms are edible, the trick is to eat only those which will prove to be edible more than once. The Celebrated Discworld Almanak recommends you play safe and eat beans on toast.
Re: [Qemu-discuss] Bug reports ?
On Sun, Aug 23, 2015 at 02:01:47AM +0100, Peter Maydell wrote: On 23 August 2015 at 01:09, Ken Moffat zarniwh...@ntlworld.com wrote: Is this the right place to ask about what seems to be a fairly catastrophic bug (host machine running recent x86_64 linux and 4.2-rc kernels locks up with 2.4.0 when qemu is running but seems fine with 2.3.0) or do I need to subscribe to a different list ? You'll probably do better to report it on qemu-devel (that is a high-volume list; I don't think you need to be subscribed to send it email). Or you could file a bug report at https://bugs.launchpad.net/qemu -- though that only gets attention because bug mail is forwarded to qemu-devel, so it's another way of mailing the list, in effect. Locking up the host kernel is technically speaking a KVM bug (or some other kernel bug) rather than a QEMU bug, but the people who care will be on qemu-devel. thanks -- PMM Peter, thanks for that, and you are correct, it definitely is a kernel issue. I was trying to form a is this kernel good or bad ? testcase, and decided to try leaving qemu (running Xorg from 'startx' with xscreensaver enabled) for 3 hours. Did that with kernel 4.2.0-rc8 and qemu-2.3.0, and when I came back the box was unresponsive. I'll take this to lkml and copy qemu-devel. ĸen -- This one goes up to eleven: but only on a clear day, with the wind in the right direction.
[Qemu-discuss] Bug reports ?
Is this the right place to ask about what seems to be a fairly catastrophic bug (host machine running recent x86_64 linux and 4.2-rc kernels locks up with 2.4.0 when qemu is running but seems fine with 2.3.0) or do I need to subscribe to a different list ? TIA for any replies, it may take me two or three days to respond because of non-computing priorities. ĸen -- This one goes up to eleven: but only on a clear day, with the wind in the right direction.
Re: [Qemu-discuss] linux: ioctl(KVM_CREATE_VM) failed: 12 Cannot allocate memory
On Fri, Feb 27, 2015 at 07:27:04AM +0100, Jakob Bohm wrote: On 27/02/2015 05:22, Ken Moffat wrote: ioctl(KVM_CREATE_VM) failed: 12 Cannot allocate memory failed to initialize KVM: Cannot allocate memory and google produced nothing useful about where I need to look. This is linux-3.19.0 and qemu-2.2.0 (and linuxfromscratch-7.7-rc / current BLFS). Any pointers, pretty please with sugar ? I think it is self-explanatory: Not enough free memory in the system, mostprobably because your X server had allocated too much. The command free of the top lines in top output should tell you how much is left. Enjoy Jakob OK, thanks. I'll keep an eye on that. ĸen -- Nanny Ogg usually went to bed early. After all, she was an old lady. Sometimes she went to bed as early as 6 a.m.
Re: [Qemu-discuss] linux: ioctl(KVM_CREATE_VM) failed: 12 Cannot allocate memory
On Fri, Feb 27, 2015 at 02:12:28AM +, Ken Moffat wrote: I had kvm working fine (i686 guest) from a new x86_64 host system - after fixing up some Xorg server issues - and then I decided to create a new x86_64 guest (this is linuxfromscratch, so using an old guest to build a new one). But now when I try to start qemu with any of my images, even one which worked a couple of hours ago after I last reran 'startx', I get: ioctl(KVM_CREATE_VM) failed: 12 Cannot allocate memory failed to initialize KVM: Cannot allocate memory and google produced nothing useful about where I need to look. This is linux-3.19.0 and qemu-2.2.0 (and linuxfromscratch-7.7-rc / current BLFS). Any pointers, pretty please with sugar ? Eventually, I finished the application tests I had been doing, and decided to reboot to see if that would fix it. But before rebooting, I killed Xorg with ctrl-alt-backspace (yes, I'm old school ;) and then ran 'startx' again : now qemu is working once more. Very weird, I was starting to think it might be a kernel regression, but apparently not. Any pointers for what the error message means would still be appreciated. ĸen -- Nanny Ogg usually went to bed early. After all, she was an old lady. Sometimes she went to bed as early as 6 a.m.
[Qemu-discuss] linux: ioctl(KVM_CREATE_VM) failed: 12 Cannot allocate memory
I had kvm working fine (i686 guest) from a new x86_64 host system - after fixing up some Xorg server issues - and then I decided to create a new x86_64 guest (this is linuxfromscratch, so using an old guest to build a new one). But now when I try to start qemu with any of my images, even one which worked a couple of hours ago after I last reran 'startx', I get: ioctl(KVM_CREATE_VM) failed: 12 Cannot allocate memory failed to initialize KVM: Cannot allocate memory and google produced nothing useful about where I need to look. This is linux-3.19.0 and qemu-2.2.0 (and linuxfromscratch-7.7-rc / current BLFS). Any pointers, pretty please with sugar ? ĸen -- Nanny Ogg usually went to bed early. After all, she was an old lady. Sometimes she went to bed as early as 6 a.m.
