Migrating to 4.0 (backup / restore)

87 views
Skip to first unread message

Nuno Branco

unread,
Jan 23, 2018, 11:55:52 AM1/23/18
to qubes-users
Basically, if I backup my current 3.2 VMs am I going to be able to
restore them on 4.0 ? Not clear on what the implications are of the HVM
vs PVVM change on 4.0 are for backups / restores.

--

Best regards,
Nuno Branco


Ivan Mitev

unread,
Jan 23, 2018, 1:16:35 PM1/23/18
to qubes...@googlegroups.com


On 01/23/18 18:55, Nuno Branco wrote:
> Basically, if I backup my current 3.2 VMs am I going to be able to
> restore them on 4.0 ? Not clear on what the implications are of the HVM
> vs PVVM change on 4.0 are for backups / restores.

I replaced my 3.2 setup with 4.0rc3 a few days ago and I'm quite happy
with it; there were a few hiccups though so if I were you I'd test first
on a separate HD or be ready to install 3.2 back. The HVM vs PVVM change
was transparent although some of the things listed below might be a
result of the change.

- I had an issue when restoring dom0's home [1] ; the solution was to
recover the files manually from the backup. You may want to have a
separate dom0 backup - I'm not sure how easy it is to perform the backup
recovery with multiple VMs in a backup "bundle".

- I couldn't launch apps from the menu for a restored fedora VM that was
standalone in 3.2. qvm-start'ing apps from dom0 worked though. I tried
to update the qubes-* rpms in that VM to 4.0 (hacking qubes' yum repo to
4.0) but it ended up in a total mess, I eventually restored it again
from 3.2 and will debug that later.

- Windows VM (win7) works - sort of: I can launch the windows template
and it works fine, but the "standalone based on template" VMs restored
from 3.2 won't start. I didn't have the time to debug that yet as those
are non critical.

- 4.0rc3's fedora VMs are based on fedora 25 so you'll have to download
the newer fedora-26 template rpm and update your VM configurations. You
may wait for 4.0rc4 which I understand should be released soon - it
should include fedora 26 by default

- if for some reason you often have to look at all your VMs' cpu usage
at once, I haven't seen a way to do it yet. Qubes-manager is missing
from 4.0rc3 but should be back (in a new form) in 4.0rc4, I don't know
if they'll restore the cpu usage feature though. There was also a hint
that this could be shown from the new applet menu [2] but like with
everything above debugging time is scarce and I have yet to see if the
applet's menu visible info is user configurable.


Everything else in my workflow works as before - sys-usb, sys-net with
PCI devices, ...
I haven't tested "native" backup+restore on 4.0 yet though.

Hope this helps.

Ivan

[1] https://github.com/QubesOS/qubes-issues/issues/3467
[2] https://github.com/QubesOS/qubes-issues/issues/2132

Yuraeitha

unread,
Jan 24, 2018, 8:12:22 PM1/24/18
to qubes-users
Any VM's restored from Qubes 3.2. will retain their PV state, but can be changed to HVM or PVH. However, it might not be the desired approach, at least, in my experience, it isn't. Perhaps newer updates fixed what caused my issues, but either way, here is what I recommend to avoid any potential issues.

This might help Ivan too, regarding the issue starting applications. Generally my experience have been that using any old templates or AppVM's from Qubes 3.2. works "somewhat". However, they were in my experience sluggish, slow, and even sometimes error prone. I don't know if this issue has been fixed, but during the Qubes 4 RC-2 phase I had this issue. In contrast, any Qubes 4 templates/AppVM's I made were free from errors, and were running smooth. My deduction then, was to get rid of any old 3.2. AppVM's I had, and it did indeed help a lot of my issues.

What I did back when I upgraded, is as I initially mentioned above, not what I will recommend, because I lost some files doing that. Which is using file transfer between Qubes 3.2. and Qubes 4.0 AppVM's. Please be very careful if you do this. I'm not sure if this conflic has been fixed, since I no longer have any old 3.2. qubes on my Qubes 4 system.

Instead, I will recommend you put all your files on an external drive while still on Qubes 3.2., i.e. make a folder for each VM's files. Doing this while on Qubes 3.2. will ensure you don't encounter errors and avoid any conflicts.

After you did that, then just transfer the files back into each their respective VM on fresh new Qubes 4.0 VM's.

Also keep in mind that Qubes 4.0 has the qvm-usb widget, which makes passing USB to each VM quite easy and trivial. But be sure you update fully before you use it, as its had many updates since RC-3. Also be absolutely sure you disconnect from within the VM first when you want to stop using it, before you disconnect a drive from the widget itself. Just like you would do before unplugging an USB drive normally, instead, you do it twice. Once inside the VM, once outside the VM. Maybe this is improved in the future, but right now its important to do both steps to avoid data corruption.

You might know some of this already, but just in case. Qubes 4 has PV, HVM, and PVH states for VM's. As you know, PV is the one used in Qubes 3.2, and HVM was used in Qubes 4 for a while under development from RC-1 to RC-3. However recently PVH was made available too. PVH is pr. my understanding great for security, except, PCI passthrough does currently not work for any VM using PVH. So any template or AppVM, which does not have any PCI devices passed to them, you should remain PVH. sys-net should obviously be HVM (or even PV if HVM is not working). sys-usb should also be HVM. Windoes 7 should always use HVM. The rest can benefit from being PVH. You can change it in the VM-Settings preference GUI window for each VM, or instead via terminal by "qvm-prefs VM-name virt_mode" which prints the current state of the VM, either reporting PV, HVM or PVH.
To change the mode, just write "qvm-prefs VM-name virt_mode pvh", but remember to only use HVM for pass-through VM's and full HVM like Win7. Also right now, the preference window for each VM doesn't always show the correct PV/HVM/PVH. Use the qvm-prefs command to print the state if you want to be sure it's shown correct. This will probably be fixed soon.

Be mindful of that Qubes 4 can't simply re-naming VM's so easily like it does in Qubes 3.2. In Qubes 4, it will copy the entire VM under the new chosen name, and then delete the VM with the old name. Which requires not only a lot of extra disk space to pull off, it can also take a while if the VM is large. I've heard that there is a good reason for this, but I did not check the technical reason.

Some of this is a bit of a hassle, but other than that if you ask me, I'm quite enjoy Qubes 4, I'm personally quite happy on it. The issue with my old 3.2. AppVM's however did give me a bad start, so as long as you're mindful of this potential issue, and your hardware is supported (Qubes 4 is more hardware strict than 3.2.), then you should be okay.

Oh, also, be sure to read the Qubes news articles when a new RC-X version is released, because the Qubes developers will write if they recommend to re-install or not. For example between RC-2 and RC-3 it was said to be fine to just update as usual and carry on without re-install. But sometimes, it may be needed to re-install Qubes between RC-X releases, just be mindful of this. RC-4 is still due to be released, and it's still unknown if the current RC-3 can be updated, or if a re-install will be required.

My Windows 7 also works somewhat fine, for as long as it receives enough RAM. It seems a bit more critical of having enough RAM in Qubes 4 than Qubes 3.2., but I never got around to verify if that truely is the case. I just gave it 4GB and removed the dyanamic RAM allocation, and then it worked just fine ater that. Any less RAM, like 3GB or 3.5GB, and it just randomly crashed on me. But surprisingly, once over 4GB, it stayed stable. I did not verify if any recent update has fixed this, and perhaps its a hardware relared issue, so it might be different for you. Try it out and see if you can find your own RAM sweet-spot. Some Qubes features does not work in my Windows 7 that was installed originally on Qubes 3.2., while others do. For example I can transfer files between Win7 and other Linux VM's just fine, but there is no internet in Win7. I'm planning to re-install my Win7 under Qubes 4, but it was broken some months back. I believe it's been fixed now, but I need the time to get around and do it again. My guess is, that Win7 might work properly after a re-install, but I need to confirm it first.

Either way, I hope some of this was useful.

cooloutac

unread,
Jan 24, 2018, 8:49:12 PM1/24/18
to qubes-users
what about custom template vms, should I just make new ones from scratch?
Reply all
Reply to author
Forward
0 new messages