Linux VMs can't reach network after restoring from backup to fresh 4.0rc3 install

70 views
Skip to first unread message

ThierryIT

unread,
Feb 21, 2018, 3:21:58 AM2/21/18
to qubes-users
Hi,

After having restored Linux VM from Qubes 3.2, this VM base on fedora template doesn't reach the network.
In the same time, I am now using Qubes 4rc4, same problem.
I only have this problem with this VM,all other VMs from my 3.2 backup are working.

Thx

awokd

unread,
Feb 21, 2018, 3:58:51 AM2/21/18
to ThierryIT, qubes-users
To make sure I understand what you are doing:
You have an AppVM based on a Fedora template backed up from R3.2. You
restored it to R4.0rc4. Other AppVMs restored work fine, except for this
single AppVM. Correct?

If so, does this problem AppVM use the same template as your working
AppVMs? If that's not the case, try changing it to use the same template.
Also, is it set to use the same NetVM as your working ones?


ThierryIT

unread,
Feb 21, 2018, 4:07:29 AM2/21/18
to qubes-users
Le mercredi 21 février 2018 10:58:51 UTC+2, awokd a écrit :
> On Wed, February 21, 2018 8:21 am, ThierryIT wrote:
> > Hi,
> >
> >
> > After having restored Linux VM from Qubes 3.2, this VM base on fedora
> > template doesn't reach the network. In the same time, I am now using Qubes
> > 4rc4, same problem.
> > I only have this problem with this VM,all other VMs from my 3.2 backup are
> > working.
>
> To make sure I understand what you are doing:
> You have an AppVM based on a Fedora template backed up from R3.2. You
> restored it to R4.0rc4. Other AppVMs restored work fine, except for this
> single AppVM. Correct?

yes

>
> If so, does this problem AppVM use the same template as your working
> AppVMs?

yes

If that's not the case, try changing it to use the same template.

Will try and let you know

> Also, is it set to use the same NetVM as your working ones?

yes

ThierryIT

unread,
Feb 21, 2018, 4:12:39 AM2/21/18
to qubes-users
It seems that I am not able to change the template of all my restored VMs, in Qubes settings, the template is in grey .... Even if the VM is off.

awokd

unread,
Feb 21, 2018, 4:13:55 AM2/21/18
to ThierryIT, qubes-users
On Wed, February 21, 2018 9:07 am, ThierryIT wrote:
> Le mercredi 21 février 2018 10:58:51 UTC+2, awokd a écrit :

>> To make sure I understand what you are doing:
>> You have an AppVM based on a Fedora template backed up from R3.2. You
>> restored it to R4.0rc4. Other AppVMs restored work fine, except for this
>> single AppVM. Correct?
>
> yes
>
>>
>> If so, does this problem AppVM use the same template as your working
>> AppVMs?
>>
>
> yes

OK, then go into Settings on your problem AppVM and change both the
Template and NetVM to some other value and hit OK. Then, go back into
Settings and change them back to the values used by your working AppVMs
and hit OK and try it out.


ThierryIT

unread,
Feb 21, 2018, 4:28:39 AM2/21/18
to qubes-users
Cannot change the template .... it is in grey

awokd

unread,
Feb 21, 2018, 4:36:53 AM2/21/18
to ThierryIT, qubes-users
From your other email and this one, all AppVMs restored from R3.2 have
their template setting in grey, even when powered off? What happens if you
try to change it from the command line with qvm-prefs?

ThierryIT

unread,
Feb 21, 2018, 5:07:55 AM2/21/18
to qubes-users
qvm-prefs vmname template fedora-26

vm-prefs: error: no such property: 'template'

ThierryIT

unread,
Feb 21, 2018, 5:16:31 AM2/21/18
to qubes-users
the not working VM prefs:

autostart D False
backup_timestamp U
debug D False
default_dispvm D fedora-25-dvm
default_user D user
gateway D
gateway6 D
include_in_backups D True
installed_by_rpm D False
ip D 10.137.0.11
ip6 D
kernel D 4.14.18-1
kernelopts D nopat
klass D TemplateVM
label - green
mac D 00:16:3E:5E:6C:00
maxmem D 4000
memory D 400
name - vm-work
netvm - proxyVM-eth
provides_network - False
qid - 11
qrexec_timeout D 60
start_time D 1519206767.23
stubdom_mem U
stubdom_xid D 18
updateable D True
uuid - 5735bd73-e50f-4a63-9a34-6be0b2dc7d3a
vcpus D 2
virt_mode - hvm
visible_gateway D 10.137.0.18
visible_gateway6 D
visible_ip D 10.137.0.11
visible_ip6 D
visible_netmask D 255.255.255.255
xid D 17

awokd

unread,
Feb 21, 2018, 5:31:29 AM2/21/18
to ThierryIT, qubes-users
On Wed, February 21, 2018 10:16 am, ThierryIT wrote:

>
> the not working VM prefs:
>

From these lines in your config, it looks like you've created this VM on
R3.2 as a standalone HVM instead of an AppVM based on a template. Does
that sound right?

klass D TemplateVM
virt_mode - hvm

These are the network settings assigned to this VM. They have probably
changed from what they were in R3.2:

visible_gateway D 10.137.0.18
visible_gateway6 D
visible_ip D 10.137.0.11
visible_ip6 D
visible_netmask D 255.255.255.255

Usually there is a script that runs inside the Linux VM that re-assigns
these to the correct values, but since it's been restored from R3.2 it
might not be working. From within vm-work, try assigning the above values
manually. Check another working VM for the appropriate DNS settings.

ThierryIT

unread,
Feb 21, 2018, 6:18:55 AM2/21/18
to qubes-users
Seems not able to keep the manual network config ... Is the internal script can re-write the config ?

I have add the folder "eth0" in "interfaces.d" -> doesn't keep the config
or
I have add the network config to the file "interfaces"

thx

awokd

unread,
Feb 21, 2018, 6:38:16 AM2/21/18
to ThierryIT, qubes-users
On Wed, February 21, 2018 11:18 am, ThierryIT wrote:
> Le mercredi 21 février 2018 12:31:29 UTC+2, awokd a écrit :

>> Usually there is a script that runs inside the Linux VM that re-assigns
>> these to the correct values, but since it's been restored from R3.2 it
>> might not be working. From within vm-work, try assigning the above
>> values manually. Check another working VM for the appropriate DNS
>> settings.
>
> Seems not able to keep the manual network config ... Is the internal
> script can re-write the config ?

Possibly, I don't exactly know how it works.

> I have add the folder "eth0" in "interfaces.d" -> doesn't keep the config
> or I have add the network config to the file "interfaces"

Instead of trying to fix this broken HVM, maybe it would be best to create
a new "work" AppVM based on a Fedora template (since it sounds like that
was your plan in the first place) and to use qvm-copy-to-vm commands to
copy your data from the old to the new?


Reply all
Reply to author
Forward
0 new messages