Hello, I am in desperate need of assistance. In my guest Windows VM, there is no sounds playing. In Linux guests, however, everything is fine.
I use KVM virtualization, managing it in virt-manager. [FONT=arial]I can provide any necessary screenshots. Host OS is OpenSUSE Tumbleweed. Where should i dig?
One note: I have another distribution, Manjaro, specifically, where settings appear to be the same, but there is no such audio problem.
I’m talking about qemu.conf and $ virsh edit [VM_Name]. Identical on both distributions, but there, Windows guest works just fine. I have no idea why.
What version MSWindows are you running as Guests?
Today’s most recent Win10 are supposed to contain the necessary virtio drivers in the Windows kernel, but if you are running something older (eg Win7 or early Win10 and not updated), then you’ll need to install the virtio drivers separately (There are other Forum threads on where to get these Windows virtio drivers).
Windows 10 is guest vm. It is not a virtio drivers problem, because VirtIO drivers iso doesn’t include sound drivers. Sound device set in virt-manager is ICH9. AC97 is not an option, because the same configuration works just fine in another distro with the same VM.
In Windows guest vm, it doesn’t seem to have problems with drivers. Everything is fine in Windows Device Manager, no warnings. And it looks like sound is played in VM, because equalizer reacts when I launch mediaplayer with some music. But, there is no output to host OS. Either it is VERY quiet, or not sent to physical audio device in host.
I’ll add some more information, maybe this will make a difference.
All version are fresh, host OS got all the recent updates. This includes QEMU, KVM, Virt-Manager, etc.
Guest Windows 10 VM is version 2004, most recent also.
I use a Spice server on all VMs, and in all of them, except for Windows VMs, sound is fine. I’ll try to include .xml file with settings next time.
The problems began after I reinstalled OpenSUSE Tumbleweed on my host machine.
I copied .qcow2 virtual drive with Windows, installed from another machine. After configuring hardware in virt-manager, sound worked.
But, if I try the same installation here, on this OpenSUSE machine, there is no sound. What is wrong?
Not following your description…
The virtual disk format shouldn’t make a difference, what disk is copied from what to what?
Installed from another machine? Are you saying that the virtual machine was installed on a different HostOS and copied to your HostOS running Tumbleweed?
In any case, you might try creating a new VM and see if your problems are limited to the machine you created or affects many or all machines you create on that one machine.
OK, not to be obscure…
I have two computers. Each has its own OS. First has OpenSUSE, second - Manjaro.
When I install Windows on a VM in OpenSUSE, there is no sound in it. However, when I do the same in Manjaro, sound is working, out-of-the-box, no drivers needed.
So, if I then copy this VM with installed Windows from Manjaro to OpenSUSE, the sound also works.
So, why the sound isn’t working when Windows installed in OpenSUSE, question remains.
This reads like Windows guest detects the ‘virtual sound’ hardware and so the appropriate driver is correctly configured when first installed in the Manjro VM environment, (but not if done via the openSUSE hosted environment for some reason). Out of interest, which sound hardware (emulation?) does Windows detect in the Manjaro hosted VM?
OK, not to be obscure…
I have two computers. Each has its own OS. First has OpenSUSE, second - Manjaro.
When I install Windows on a VM in OpenSUSE, there is no sound in it. I tried re-creating, with no result.
However, when I do the same in Manjaro, sound is working, out-of-the-box, no drivers needed.
So, if I then copy this VM with working sound from Manjaro to OpenSUSE, the sound in this “cloned” VM also works.
So, why the sound isn’t working when Windows is installed on a VM which created purely in OpenSUSE, question remains.
What I did: I copied windows.qcow2 with installed Windows 10, which I created in Manjaro. And paste it to OpenSUSE, importing existing disk image in virt-manager. Created with this “method” VM, has working sound in OpenSUSE.
Not sure I can give a proper answer to that…
What I know, is that in both Windows VMs in Manjaro and OpenSUSE, the Device Manager shows the same.
High Definition Audio Device with the same Hardware Ids. It looks like the driver is the same, I don’t know…
*Today 18:23
** Originally Posted by deano_ferrari
*
**This reads like Windows guest detects the 'virtual sound' hardware and so the appropriate driver is correctly configured when first installed in the Manjro VM environment, (but not if done via the openSUSE hosted environment for some reason). Out of interest, which sound hardware (emulation?) does Windows detect in the Manjaro hosted VM?*
Not sure I can give a proper answer to that..
What I know, is that in both Windows VMs in Manjaro and OpenSUSE, the Device Manager shows the same.
High Definition Audio Device with the same Hardware Ids. It looks like the driver is the same, I don’t know…
Offhand,
I’m guessing that your HostOS installs on Manjaro and Tumbleweed machines and moving a machine from one to the other is introducing factors people don’t ordinarily see.
For most things there wouldn’t be a problem but sound might be a special issue.
As I suggested,
I recommend you do a brand new install on Tumbleweed and test your audio (still on Tumbleweed).
If your audio is fine, it’d superficially confirm my suspicion.
If you want to continue to troubleshoot what might be the exact issue, I see a few results from my Google search that could be relevant to your situation.
If on the other hand, you still have audio problems with your new machine…
Well, those articles might still help troubleshooting, but IMO it’s more important to first test a VM running on the same machine it’s built on.
After recent update, the sound is returned, packages “qemu” and “virt-manager” was updated. Looks like one or both of them was the cause.
The similar situation had happened with qbitorrent, probably 2-3 weeks ago. Previous update created and the next update has solved the issue.
Problem is solved, thread may be closed.