Whew! Here we go for round three! Let's see if we can get this to work in the end. Here goes.
Firstly, my VM actually was in qemu:///system, NOT in qemu:///session. So, even though I wasn't having to enter my root password, the VM must have been running as root anyway (?! Why did they do that ?!). So, here goes trying a VM in qemu:///session. (I'm typing this as I do the steps to see if I can reproduce your problem and fix it, so if it seems a little unplanned as I go, that's because it is.)
So, first I went into virt-manager, and started to make a new connection to QEMU/KVM different than the default one - this time I'm using "QEMU/KVM user session". When I selected it in virt-manager, it told me that "networking options were very limited". So this looks like where the problem begins. Let's see if I can get around it.
Having established the connection, now I'm going to create a new KolibriOS VM in it and see what happens.
So, during VM creation, virt-manager no longer sees my ISO Files directory containing my VM installers. So I'm going to add a new storage pool pointing to my ISO files so that I can actually make the VM. (directory: /home/user/ISO Files)
OK, now I have access to my ISOs. Now, I'm going to make the new KolibriOS VM with my "kolibri.iso" file. (OS type: Generic default, CPU count: 1, Memory: 256 MB. Kolibri is a tiny OS.)
I'm not going to give the VM any disk storage since KolibriOS is designed to be used directly off of the ISO.
Now, finally I'm at the end, and I notice one interesting thing. I'm given the option of using either usermode networking or a shared device name. I'm going to start with usermode networking, and if that doesn't work, we're gonna try again with shared device "virbr0", and see what happens.
I hit the Finish button. Now my VM should boot up in short order.
OK, it booted up, and I got "You are now connected to the network". Seems promising.
Now I've opened WebView, and I'm going to go to "Kolibri Stuff" and see what happens. If that works, I'm going to see if I can get to Google.
The "Kolibri Stuff" button worked - now I see the page "http://store.kolibri-n.org/en.html". Now let's try Google.
Sure enough, there's Google, complete with it's Privacy Policy link.. Let's see what happens if I click that.
Well, quite obviously WebView doesn't understand what on earth this page says, but I did get a nice big bunch of convoluted JavaScript on my screen, so obviously it downloaded something. Let's try NSInstall.
OK, it's having to download the NetSurf application. If it can download that, I assume that networking is working.
Download complete. Now let's try Google again.
OK, NetSurf didn't like Google. Let's try Dedoimedo. This is basically a bunch of Linux reviews and stuff like that.
Final conclusion - NetSurf stinks! I'm going back to WebView. (http://www.dedoimedo.com/index.html). Finally! It opened!
So, since I can successfully browse around inside my usermode VM, I assume that this is working. A "virsh -c qemu:///session list" now shows my "UserKolibriOS" VM running. Here's what it shows:
Id Name State
-------------------------------
1 UserKolibriOS running
And "virsh -c qemu:///system list" now shows this:
Id Name State
--------------------
So, I have a usermode VM accessing the Internet just fine. Now, let's try again, doing the same thing, but this time with Lubuntu 18.04, so that we get the virtio network adapter. (I'm doing this battery of tests because I want to make absolutely sure that everything works before dumping loads of configuration files on you.)
Here's my Lubuntu 18.04 VM config: 2 CPUs, 1024 MB of RAM, usermode networking, no virtual hard drive.
OK, the VM is booting. Let's see what happens.
The VM is booted. It seems to think that it's connected to the network. I'm going to open up Google and do a search for "blue screen of death", and see what happens.
Wow! The Internet in my VM almost seems to be working faster than the Internet on my physical system. I was able to bring up "Blue Screen of Death" on Wikipedia from my search, and opened it up. I'm now staring at a relatively grim picture of a frowning Windows 10 on my VM window. So, I am concluding that usermode networking is working just fine for web browsing in the VM. Now, let's see what my configuration is doing.
Firstly, I noticed that no "connected to tun vnet0" appeared on my screen when I launched the KolibriOS VM, and when I launched the Lubuntu 18.04 VM.
Now, here's the network adapter configuration, first for KolibriOS:
<interface type="user">
<mac address="52:54:00:6f:ab:33"/>
<model type="e1000"/>
<address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x0"/>
</interface>
Now, here's what Lubuntu 18.04 looks like:
<interface type="user">
<mac address="52:54:00:7d:63:ba"/>
<model type="virtio"/>
<address type="pci" domain="0x0000" bus="0x01" slot="0x00" function="0x0"/>
</interface>
So now my configuration looks identical to yours, except for my configuration is missing the bit about "link state="up"". Yet, my networking works and yours doesn't. Hmm...
All I can think now is that the networking settings in your VMs OS must not be working, and that your VM itself must be configured perfectly.
Finally, I'm going to run one final test - Lubuntu 18.04 with the shared device "virbr0". Let's see if it works with the network bridge even though it's a usermode VM.
Total fail! I got this mess on my screen when I tried it:
Unable to complete install: 'internal error: /usr/lib/qemu/qemu-bridge/helper
--br=virbr0 --fd=29: failed to communicate with bridge helper: Transport
endpoint is not connectedH001F007F stderr=failed to parse default acl file`/
-etc/qemu/bridge.conf''
What?! Obviously it doesn't want to connect to my network bridge. I think that you're right that bridged networking won't work at all with a usermode VM. But usermode networking did work, so it shouldn't be necessary.
I did notice something on the link you gave me to the info about usermode networking. It had a link to a page about QEMU's networking, that ended in usermode networking. It said at the end that "this option does provide a very useful default in that the guest OS will have largely transparent network access almost like any other application running on the host." (This was at "https://people.gnome.org/~markmc/qemu-networking.html".) Is QEMU actually allowed to connect to the Internet? Or has it somehow been blocked? Not sure if it's even possible to block a single process from Internet access in Linux, but maybe. If QEMU can't connect, the VM won't be able to connect.
So, final conclusion - I think that this is a problem with the virtual OS, not with the configuration of your virtual machine. Try Lubuntu 18.04 - it worked immediately, right out of the box. You can download it from here: "https://lubuntu.me/downloads/". See if the networking works there. Other than that, it looks like you're doing everything right.
Edit - This problem was finally solved by editing some stuff in "/etc/resolv.conf" in the virtual OS. This worked on Ubuntu and Arch Linux. Usermode networking now works. Thanks Ned64! (See comment from Ned64 below for details.)
Hope this helps!
host [some domain name] [your first resolver IP from /etc/resolv.conf]
.