Convert live system to VM in Qube OS?

[szalony...@gmail.com]

Hi,
I am desktop end-user looking for additional security for my daily driver PC. I need to have access to all of the files on the system that I currently use for work - planning to fade it off, but at this time I was thinking I will try converting live system to a VM in Qube OS to use it when needed as I cannot afford re-configuring all of the software that I need on daily basis from scratch (time constraint).

What would be the best way to do that?

[szalony...@gmail.com]

I currently use dual boot Windows 7 and Debian 8.7 if it helps, but what I care about as a VM is Windows.

[Alex]

First, you may already have thought about it, but the simple
transposition of a work pc to a VM environment (be it qubes or not) does
not give you any additional security benefit. It only increases the
compatibility problems!

To actually benefit from the Qubes architecture a deep restructuring of
both your filesystem and your habits must be done. If you want to
benefit from multi-vm-isolation, then you will need to split your
software usage (thus, configurations) among several VM. If you want to
benefit from fake persistence of system files, you will need to try to
move as much software as possible in either the template (installing
with dnf) or in /usr/local/bin (if manually-compiled or direct binary
package).

TL: DR; it takes time to get used to the split-vm environment,
especially so if you come from a single-workstation (both personal and
work) mindset. It took me ~1 month, and a couple reinstallations, two
years ago.

For your actual question, there's no tool to assist in "converting" a
live system to a Qubes VM: since there would be so little benefit
there's no actual reason to make such a tool. Since linux PVM are just
Xen domains, you may try to move all the files in your home directory
into the /home directory into the private.img ext4 volume of an AppVM of
your choice. If you use custom systemd unit files for your automations,
you could either put them in the template or in ~/.config/systemd/user
and enable/start them as user units (I do that for syncthing, for example).

If you use Windows, since this OS is supported as HVM (a nearly standard
virtual machine), you would not be able to easily move things between
the live system and the HVM, since the easiest way to have it working is
to install Windows *in* the HVM, thus having its own registry and system
files. If your main programs are on Windows, you will need to
reconfigure them from scratch. Trying to mount an image of the live
system in the HVM, or trying to mount it as a separate disk, could lead
to way more time being spent in investigating poorly documented issues.
Not that a Windows HVM is that much documented itself...

Good luck
--
Alex

[Drew White]

Easiest way... Boot up the drive in the guest as attached for boot to allow it to install everything, after that, boot up using clonezilla or something and just do that.

Otherwise, DD the drive to an image with options set to allow qemu type. That is, allow it to be "thin".

Hope that makes sense.

[Jean-Philippe Ouellet]

On Sat, Feb 4, 2017 at 7:31 AM, Alex <alex...@gmx.com> wrote:
> First, you may already have thought about it, but the simple
> transposition of a work pc to a VM environment (be it qubes or not) does
> not give you any additional security benefit. It only increases the
> compatibility problems!

On the other hand, it allows one to start using qubes without suddenly
breaking your entire workflow, and allows one to gradually adopt the
Qubes model while still being able to get your work done. The
realistic alternative is likely not trying Qubes and continuing to use
your old system indefinitely because the perceived migration burden is
too great.

> If you want to
> benefit from fake persistence of system files, you will need to try to
> move as much software as possible in either the template (installing
> with dnf) or in /usr/local/bin (if manually-compiled or direct binary
> package).

/usr/local/bin is not "fake-persisted", it is persisted. All of
/usr/local is a symlink to /rw/usrlocal, which is persisted.

> For your actual question, there's no tool to assist in "converting" a
> live system to a Qubes VM: since there would be so little benefit
> there's no actual reason to make such a tool.

I disagree. I think a migration tool could be quite helpful, and I am
often asked if one exists while promoting Qubes to friends.
Unfortunately there are (and will likely always be) higher priority
things to implement.

[szalony...@gmail.com]

Thanks for all the responses!

I finally cloned the drive using dd, after few attempts it worked. It took me another 2 days to boot into it and am currently rebuilding my windows environment into separate DOMs on QubeOS.

[compu...@gmail.com]

Hi. Donyou mind sharing the steps you followed to accomplish this? I am also in the midst of migrating to qubes. And was wondering if I could migrate the existing windows live machine to an HVM.

Thanks

[Drew White]

On Monday, 11 June 2018 12:24:02 UTC+10, compu...@gmail.com wrote:
> Hi. Donyou mind sharing the steps you followed to accomplish this? I am also in the midst of migrating to qubes. And was wondering if I could migrate the existing windows live machine to an HVM.
>
> Thanks

One other way...

Create HVM, go to HVM directory..

qemu-img convert /dev/sdX root.img

There you will have the drive converted.
If you have another drive that is the data/private..

qemu-img convert /dev/sdY private.img

Boot it up and see how it goes.