On 11/13/18 9:15 PM, Otto Kratik wrote:
On Monday, November 12, 2018 at 11:44:08 PM UTC-5, Ivan Mitev wrote:
Oh, I see. I've updated the issue to add a mention about the gateway.
Actually the issue was originally meant to document the problems with
QWT on R4 but it slowly evolved into a step-by-step guide.
The ip output by `qvm-prefs vmname visible_gateway` ; if you don't have
a fancy vpn/firewall setup, it's likely 10.137.0.6.
Thanks - I added the sys-firewall gateway value and that seemed to do the trick
in restoring connectivity (which is of course, entirely obvious in hindsight).
A couple of oddities I noticed though:
With everything manually configured and working, I can successfully ping the
VM's own ip address and the gateway from within the VM, however I can *NOT*
ping the DNS servers at all.
Attempting to ping 10.139.1.1 or 10.139.1.2 results in:
Response from 10.128.100.62: Destination net unreachable
The DNS server ips are destination nat'ed so you can't ping them. I
forgot about that when I advised to ping them - sorry.
I have no idea what that IP address above is. Obviously DNS resolution is
working since I can lookup websites correctly as expected, but the ping attempt
either fails with that reply or times out completely, every single time.
Also, if I delete the DNS entries from adapter IPv4 config completely and then do
"ipconfig /all" from command line, they seem to get magically filled in by
themselves, with one slight change:
10.138.1.1 <-- (note the 138 instead of 139)
10.139.1.2
..And everything continues to work fine in terms of connectivity. The Qubes
Network Setup service is definitely disabled and stopped, so I am not quite
sure how that auto-fill is occurring.
No idea.
With the qubes network service disabled the only way I'd think of would
be to get the ips from the dhcp server running in the xen stub domain
but this shouldn't work with the PV driver (which is the reason
automatic settings work without QWT - see my other email in reply to
Achim Patzner) - and if it did the vm's ip/mask/gw should have been set
too automatically.
Also AFAIK there's no 10.138.1.1 ip used in R4, so it must be coming
from QWT.
I can also use other externally operated DNS like:
8.8.8.8
4.4.4.4
1.1.1.1
And it gets saved correctly in ipconfig and also produces full connectivity. I
am going to try garbage values and see what happens, but it almost seems like
the HVM is somehow routing its DNS queries automatically regardless of entered
values, but maybe not.
The DNS queries should be sent to the servers you specified. The NAT
rules in sys-firewall and sys-net are only valid for 10.139.1.{1,2} (at
least on my setup).
I've also added a note about QWT 4 breaking *new* HVMs (I thought the
breakage was only when updating from QWT3 to QWT4). It seems it's a
hit-or-miss process, IIRC some users managed to have QWT4 running.
Hit or miss, yes... possibly partially related to the state of updates in
Windows 7 at the time QWT4 is installed. Those reporting success (in this
thread and issue 3585) seem to have installed updates into Win7 first before
installing the guest tools. In my case I tried installing QWT4 into a fresh
Win7 SP1 with no updates applied yet, and it broke completely. So that might be
the crux, though it's just a hypothesis.
Indeed. Actually the issue mentions that relatively recent updates
*must* be installed in order to be able to use the PV storage driver,
so it might a requirement for other stuff. Windows being windows, it's
really a hit-or-miss process.
At some point if I have the 2-3 days needed to fully update Windows 7, I may try removing QWT3 and
installing QWT4 to see what happens. Of course I will try this in a clone, since I have no idea how
easy or difficult it actually is to uninstall QWT3223 cleanly, and it's far more likely I'll break
something in the attempt. Is it just a question of selecting "Remove" from the internal
Win7 "Add/Remove Programs", and then installing QWT4 anew? Or is there a more elaborate
procedure required?
The time needed to update Windows can be reduced to a few hours (!) by
using larger update packs, like described in the following guide:
https://plugable.com/2016/06/08/windows-7-wont-update-what-to-do/
advice: clone the VM before each important step and always keep at least
the past 2 clones; I remember discarding a clone after the VM
successfuly booted, only to find out that it wouldn't boot next time.
FWIW I never managed to update from QWT3 to QWT4, whatever I tried -
updating "over" QWT3, removing QWT3 first (through add/remove
programes), ...
advice 2: fully update the VM first and then mess with QWT. Again, clone
first before testing anything.
Good luck - you'll need some :)
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/f61a823e-e2c2-1c0d-08a5-f08e3c090e37%40maa.bz.
For more options, visit https://groups.google.com/d/optout.
