On Tuesday, February 20, 2018 at 12:46:45 PM UTC-7, Yuraeitha wrote: > On Tuesday, February 20, 2018 at 6:59:14 PM UTC+1, Sonny Horton wrote: > > I was originally on R3.2 and created 5 Standalone VMs: antergos, kali, > > parrotOS, Ubuntu (desktop), win7 > > > > I upgraded along the way to various R4.0 release candidates. I skipped rc1 > > as it was not usable on my hardware. rc2 was usable with some work, and > > rc3 has been working great. At each upgrade through rc3, I used backups of > > the Standalone VMs that were created in 3.2. > > > > However, When I decided to take the rc4 plunge, I took fresh backups of the > > VMs from R4.0rc3. > > > > All 5 VMs restored cleanly (although slowly) from backup and all operate > > normally, except: > > > > None of the 5 VMs have access to the network - at all (neither browser nor > > ping - either by name or IP). > > > > I've done the following: > > > > Made sure that each of the VMs is using sys-firewall as its netvm. > > > > Made sure that I can reach the network from sys-firewall (using both > > command line [ping] and browser tools). > > > > Made sure each Standalone VM is in PVH mode (except win7, which I have > > tried both as PVH and HVM). > > > > Made sure no exclusive firewall rules are in place (allow all outbound > > traffic is selected). > > > > Double-checked to make sure that the new rc4 template VMs are able to > > connect to the network - they all are. Note that the Standalone VMs are > > the ONLY ones I restored from rc3 - not any template VMs or VMs derived > > from templates. > > > > Note that the state indicator in Qube Manager is yellow for each of these > > Standalone VMs when they are running. I couldn't find a legend for this, > > but assume it is not as good as green :) > > > > > > I am still a bit of a novice Qubes user, but rather competent otherwise. I > > would welcome any informed direction on where to take my troubleshooting > > next. My goal is to get these 5 VMs running with network access one rc4, > > especially the kali and parrotOS VMs, which are fairly customized setups. > > The others are quite generic and are for testing. > > > > Thanks in advance for your help! > > > > Sonny Horton > > Could it by any chance be that this is a similar issue to that of standalone > Windows in Qubes 4, where the old Qubes tools network service is broken? The > solution there is to disable the Qubes network service inside Windows, and > then manually set the IP/subnet/Gateway/QubesDNS. Perhaps something similar > has to be done in these other standalone VM's now? > > Windows has to be run in HVM mode though (PV probably works too, but at least > PVH is officially confirmed not to work with Windows 7). > > Did you try click on the VM in the Qube Manager to see if the yellow > indicator changes? You might know this already, but the Qube Manager is > "somewhat" frozen in Qubes 4, or at the very least so slow that it appears > frozen. For example if you start a VM, or close a VM, while the Qube Manager > window is up, then it won't update the new status. Similar, if you start th > Qube Manager while your VM's are starting up or shutting down, then they will > show yellow, which they also did back in Qubes 3.2. during start or stop of > VM's. I think it's a little better with recent updates though, if you click > on the individual VM's in the window, then the status will update upon the > click. Maybe it happens automatically if more patient? I never use the Qube > Manager anymore, so I'm not sure how its behavior changes after each update. > Maybe it behaves different in Q4 RC-4? A re-install was announced not to be > necessary between RC-3 and RC-4 in the release news, but there are still some > small variations though, perhaps the Qube Manager is quicker in RC-4? At > least for me, it's very slow, and it appears frozen. > > With the standalone VM issue, manual configuration of IP's is the only > suggestion that I can think of. If you already tried that or it doesn't work, > then best wait for someone who knows more, I can only offer Qubes trial and > error suggestions at best.
Initially followed my ignorant reflexes and replied to the e-mail, sorry! @yuraeitha - thank you for the reply. I’ve had the win7 VM working in R4.0rc3 with networking, having applied the qubes tools fix [IIRC it was a simple reinstall of tools], so I don’t believe this to be the issue. With regard to win7 as well, I do have it set to use HVM (I tried PVH for grins as that was how it was set initially after the restore). I did update the Qube Manager window - both by clicking on the running VM and by using the refresh button in the toolbar. The icon stays yellow. I did notice that state indicators do not change when you terminate a standalone VM outside the Qube Manager, but do if you refresh the view. I did also notice an error message that reports itself as a possible bug in Qube Manager when you use it to stop a standalone VM. I have not fully validated this error, but I likewise don’t believe it has anything to do with the networking issue. Also, the reason I went with a clean install of rc4 was to avoid waiting for the upcoming patches for rc3 to address known vulnerabilities. Having previous success restoring my VM backups in an R4.0 environment, I had confidence in this approach. I’d like to explore the idea of manual IP configuration, but I am not sure how to proceed, given that it appears that the VMs can’t seem to connect to the virtual network interface provided by sys-firewall at all… Not at least given the tools I am presently aware of. If you know more, please do share - and thank you again for your reply and suggestions. S.H. -- 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/758e630d-b5af-4f4f-a74b-5aa0b6d7ef0e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
