I’m running Qubes 4.1. I have some Windows Qubes and followed the directions to install Qubes Windows Tools from the testing repository from this page:
When I boot into Windows, the network has issues. Windows has an “unidentified network”, no internet access. To get it to work, I have to disable the ‘Xen PV Network Device’, (the VM will freeze), do an emergency pause from Qubes, kill the VM, then restart it, and DO NOT reboot when the prompt comes up saying it needs to reboot to update Xen PV. Networking will work for that session, but on the next boot it will not be working again.
If I remove the Xen PV Network driver, networking will not work at all until QWT is re-installed.
Has anyone else experienced this as well? Any solution? QWT does not appear to have an update (yet).
Issue occurs on both Windows 10 and Windows 11
Hey thanks for outlining this issue, I’m having the same problem. Did you ever find a better solution or have any new info? In the meantime I might try installing the driver on a template and running it in an appvm and seeing if that could work as a hacky fix.
It doesn’t work. The idea was that I could get the template vm frozen in whatever state it is in when the session works, but I guess whatever it is is obviously changed when the vm is shutdown.
Hmm, actually as I’m typing this I see the network on the cloned vm has turned off. I have rebooted it and it doesn’t seem to connect at all. So I guess my observation of it being on was an outlier. I don’t know what could possibly be causing that (vm network is working, clone it and then the clone does not except for one brief one-off moment).
Some extra info:
The clone should be exactly the same, I didn’t modify it.
I shutdown the currently running VM before I boot the other vm.
I have another set of windows vm’s (so I have two sets, each set is just one vm cloned a couple of times), whixh contains the vms which I ran debloater/optimizarion scripts. For that one, it is only the 1st clone that gets network access. One thing different about that set was I hadn’t specified a NetVM for the initial vm, and I think that 1st clone was the first of the set to be assigned to a NetVM. So maybe that is a clue and could somehow pinpoint to the cause of the issue?
Although for the cause of the second set, it could be due to the debloater acripts as that also diffeeentiates the two vms (I ran the debloater script on the initial vm and left the clone untouched). Buf if so, that doesn’t explain the issue with clones not working.
Did you check the IP addresses of the clones? If they are different, i.e. each one has a new address, this would collide with the manual IP address setup for the network interface within the Windows VM. That’s a constant source of trouble.
Thanks that clears up my confusion with the cloned vms.
I’ve got them to work now by correctly updating the ip by setting it as static, and it is only the vm who has run optimize/debloat scripts which still doesn’t work.
Just out of curiosity, do you know why windows cannot determine the correct one by default?
I noticed the freshly cloned vm uses the old vms ip configuration, but if I update it by setting it as static, and then switching back to automatically obtain addresses, then the addresses are completely different.
Setting automatic IP in Windows (and also in Linux) VMs let the VM expect to get the correct IP address via DHCP, the server being sys-firewall, which works well for Linux VMs. For Windows VMs, however, this sometimes does not work (for reasons unknown to me), resulting in some more or less random default IP address.