Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #177919 > unrolled thread

Migrate Virtualbox

Back to article view | Back to linux.debian.user

Contents

  Migrate Virtualbox Mark Fletcher <mark27q1@gmail.com> - 2017-02-17 13:30 +0100
    Re: Migrate Virtualbox Hans <hans.ullrich@loop.de> - 2017-02-17 13:40 +0100
    Re: Migrate Virtualbox Georgi Naplatanov <gosho@oles.biz> - 2017-02-17 13:50 +0100
      Re: Migrate Virtualbox Peter Hillier-Brook <phb@hbsys.plus.com> - 2017-02-17 15:20 +0100
      Re: Migrate Virtualbox Mark Fletcher <mark27q1@gmail.com> - 2017-02-17 15:30 +0100
        Re: Migrate Virtualbox Darac Marjal <mailinglist@darac.org.uk> - 2017-02-17 18:30 +0100
    Re: Migrate Virtualbox Darac Marjal <mailinglist@darac.org.uk> - 2017-02-17 14:10 +0100
      Re: Migrate Virtualbox Mark Fletcher <mark27q1@gmail.com> - 2017-02-17 15:30 +0100
    Re: Migrate Virtualbox Teemu Likonen <tlikonen@iki.fi> - 2017-02-17 14:40 +0100
      Re: Migrate Virtualbox Teemu Likonen <tlikonen@iki.fi> - 2017-02-17 16:00 +0100
    Re: Migrate Virtualbox Kent West <westk@acu.edu> - 2017-02-17 20:10 +0100
      Re: Migrate Virtualbox Sven Hartge <sven@svenhartge.de> - 2017-02-17 20:20 +0100

#177919 — Migrate Virtualbox

Hello!

I have been reading from a couple of people on this list that Virtualbox 
is going away and will not be in stretch when it becomes the stable 
distro shortly.

I use Virtualbox for a couple of Windows machines to do the last task I 
cannot yet migrate to Debian (due to specialist software that is not made 
for Linux).

I am starting to contemplate migrating from Virtualbox to a different 
virtualisation solution that will be supported in Stretch.

My needs are fairly vanilla -- I have a 4-core-with-hyperthreading Intel 
Core i7 920 CPU, circa 2009, and 24GB or RAM in the host. I run 2 VMs, 
not all the time, which have 2 CPUs and 4GB of RAM each.

Access to physical optical drive, and virtual disks, is important. 
Shared folders with the host OS (which is currently Jessie and will be 
Stretch in the future) is important. 2D graphics is important, 3D less 
so. Ability to access physical USB equipment attached to the host would 
be nice but not a show-stopper. I have never got that working completely 
satisfactorily with my Virtualbox install, but suspect that is due more 
to insufficient time reading documentation than it is to limitations in 
the software (which should illustrate the importance of that element of 
things).

Minimal time futzing around to get the virtualisation solution working 
is important, as is not having to learn an entirely new paradigm to use 
the software. Stability of the result is also important.

And finally, a neat solution to migrate my Virtualbox machines to the 
new environment is very important -- I would infinitely prefer not to 
have to re-install from scratch into the new environment but would 
prefer to be able to migrate my Virtualbox disks to the new environment 
somehow, if anything supports that.

So my question is, is there an alternative solution in Debian that 
allows for that easy migration path -- any recommendations?

Thanks

Mark

[toc] | [next] | [standalone]

#177920

Am Freitag, 17. Februar 2017, 21:20:18 CET schrieb Mark Fletcher:
Hi Mark,

try KVM, my favourite, it is working great. Use AQEMU as management interface.
Maybe QEMU is also a solution. 

Good luck!

Hans

> Hello!
> 
> I have been reading from a couple of people on this list that Virtualbox
> is going away and will not be in stretch when it becomes the stable
> distro shortly.
> 
> I use Virtualbox for a couple of Windows machines to do the last task I
> cannot yet migrate to Debian (due to specialist software that is not made
> for Linux).
> 
> I am starting to contemplate migrating from Virtualbox to a different
> virtualisation solution that will be supported in Stretch.
> 
> My needs are fairly vanilla -- I have a 4-core-with-hyperthreading Intel
> Core i7 920 CPU, circa 2009, and 24GB or RAM in the host. I run 2 VMs,
> not all the time, which have 2 CPUs and 4GB of RAM each.
> 
> Access to physical optical drive, and virtual disks, is important.
> Shared folders with the host OS (which is currently Jessie and will be
> Stretch in the future) is important. 2D graphics is important, 3D less
> so. Ability to access physical USB equipment attached to the host would
> be nice but not a show-stopper. I have never got that working completely
> satisfactorily with my Virtualbox install, but suspect that is due more
> to insufficient time reading documentation than it is to limitations in
> the software (which should illustrate the importance of that element of
> things).
> 
> Minimal time futzing around to get the virtualisation solution working
> is important, as is not having to learn an entirely new paradigm to use
> the software. Stability of the result is also important.
> 
> And finally, a neat solution to migrate my Virtualbox machines to the
> new environment is very important -- I would infinitely prefer not to
> have to re-install from scratch into the new environment but would
> prefer to be able to migrate my Virtualbox disks to the new environment
> somehow, if anything supports that.
> 
> So my question is, is there an alternative solution in Debian that
> allows for that easy migration path -- any recommendations?
> 
> Thanks
> 
> Mark

[toc] | [prev] | [next] | [standalone]

#177922

On 02/17/2017 02:20 PM, Mark Fletcher wrote:
> Hello!
> 
> I have been reading from a couple of people on this list that Virtualbox 
> is going away and will not be in stretch when it becomes the stable 
> distro shortly.

Hi Mark,

if VurtualBox is not available in Stretch then you can use Vrtualboxe's
repository. The project provides their own repository for Debian.

 https://www.virtualbox.org/wiki/Linux_Downloads

HTH

Kind regards
Georgi

[toc] | [prev] | [next] | [standalone]

#177926

[Multipart message — attachments visible in raw view] — view raw

On 17/02/17 12:46, Georgi Naplatanov wrote:
> On 02/17/2017 02:20 PM, Mark Fletcher wrote:
>> Hello!
>>
>> I have been reading from a couple of people on this list that Virtualbox 
>> is going away and will not be in stretch when it becomes the stable 
>> distro shortly.
> 
> Hi Mark,
> 
> if VurtualBox is not available in Stretch then you can use Vrtualboxe's
> repository. The project provides their own repository for Debian.
> 
>  https://www.virtualbox.org/wiki/Linux_Downloads

I second this advice and my experience is that all recent iterations of
Windows (XP onwards at least) function within their capabilities under Vbox.

Peter HB

[toc] | [prev] | [next] | [standalone]

#177928

On Fri, Feb 17, 2017 at 02:46:32PM +0200, Georgi Naplatanov wrote:
> 
> Hi Mark,
> 
> if VurtualBox is not available in Stretch then you can use Vrtualboxe's
> repository. The project provides their own repository for Debian.
> 
>  https://www.virtualbox.org/wiki/Linux_Downloads
> 

Yeah, that's true. At least one other denizen of this list has gone that 
way, I believe. It's definitely a fallback option if I don't like what I 
see when I put my periscope up in QEMU-land. VirtualBox was a random, 
arbitrary choice when I first started using it, so no reason I should be 
married to it, especially if Darac's instructions to migrate the disks 
work as smoothly as they look like they should. But if I have trouble 
migrating this will be the way I go.

Anyone know _why_ Virtualbox is falling out of Debian, by the way?

Mark

[toc] | [prev] | [next] | [standalone]

#177935

On Fri, Feb 17, 2017 at 11:28:34PM +0900, Mark Fletcher wrote:
>On Fri, Feb 17, 2017 at 02:46:32PM +0200, Georgi Naplatanov wrote:
>>
>> Hi Mark,
>>
>> if VurtualBox is not available in Stretch then you can use Vrtualboxe's
>> repository. The project provides their own repository for Debian.
>>
>>  https://www.virtualbox.org/wiki/Linux_Downloads
>>
>
>Yeah, that's true. At least one other denizen of this list has gone that
>way, I believe. It's definitely a fallback option if I don't like what I
>see when I put my periscope up in QEMU-land. VirtualBox was a random,
>arbitrary choice when I first started using it, so no reason I should be
>married to it, especially if Darac's instructions to migrate the disks
>work as smoothly as they look like they should. But if I have trouble
>migrating this will be the way I go.
>
>Anyone know _why_ Virtualbox is falling out of Debian, by the way?

I believe it's down to how the upstream (Oracle) package Virtualbox. One 
of Debian's core philosophies is that packages in stable can have 
security patches applied, while remaining at a fixed feature level (this 
is the point of stable - it's a stable platform on which you can build 
your own application).

However, Oracle are increasingly moving to the idea that "if you want a 
security update, use the latest version". This is making it hard for the 
maintainers to backport the fixes. To the point where they're kind of 
giving up on it 

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794466 for the 
full discussion.


>
>Mark
>

-- 
For more information, please reread.

[toc] | [prev] | [next] | [standalone]

#177923

On Fri, Feb 17, 2017 at 09:20:18PM +0900, Mark Fletcher wrote:
>Hello!
>
>I have been reading from a couple of people on this list that Virtualbox
>is going away and will not be in stretch when it becomes the stable
>distro shortly.
>
>I use Virtualbox for a couple of Windows machines to do the last task I
>cannot yet migrate to Debian (due to specialist software that is not made
>for Linux).
>
>I am starting to contemplate migrating from Virtualbox to a different
>virtualisation solution that will be supported in Stretch.
>
>My needs are fairly vanilla -- I have a 4-core-with-hyperthreading Intel
>Core i7 920 CPU, circa 2009, and 24GB or RAM in the host. I run 2 VMs,
>not all the time, which have 2 CPUs and 4GB of RAM each.
>
>Access to physical optical drive, and virtual disks, is important.
>Shared folders with the host OS (which is currently Jessie and will be
>Stretch in the future) is important. 2D graphics is important, 3D less
>so. Ability to access physical USB equipment attached to the host would
>be nice but not a show-stopper. I have never got that working completely
>satisfactorily with my Virtualbox install, but suspect that is due more
>to insufficient time reading documentation than it is to limitations in
>the software (which should illustrate the importance of that element of
>things).
>
>Minimal time futzing around to get the virtualisation solution working
>is important, as is not having to learn an entirely new paradigm to use
>the software. Stability of the result is also important.
>
>And finally, a neat solution to migrate my Virtualbox machines to the
>new environment is very important -- I would infinitely prefer not to
>have to re-install from scratch into the new environment but would
>prefer to be able to migrate my Virtualbox disks to the new environment
>somehow, if anything supports that.
>
>So my question is, is there an alternative solution in Debian that
>allows for that easy migration path -- any recommendations?

I have recently gone down this path myself. I chose qemu+kvm as my 
virtualisation platform of choice, as it seems the most 'natively Linux' 
option (that is, QEMU is FOSS and KVM is in the kernel, so no 
third-party bits needed).

I suggest installing the 'virt-manager', 'libvirt-daemon-system' and 
'qemu-kvm' packages (frontend, middleware and virtualisation, 
respectively). You should then be able to use the 'virt-manager' 
graphical interface to create, manage and interact with your Virtual 
Machines.

In terms of migrating from VirtualBox, the procedure seems to work as 
follows:
 * Uninstall the VirtualBox tools from the guest
 * Use VirtualBox to convert the VDI into a RAW disk (this will expand 
 it to the full size, so make sure you have enough space):
   VBoxManage clonehd /path/to/guest.vdi /path/to/guest.img --format raw
 * Use qemu-img to convert this into a compressed, expandable "QCOW2" 
 disk:
   qemu-img convert -f raw /path/to/guest.img -O qcow2 
   /var/lib/libvirt/images/guest.qcow2 -c -p
 * Now create a new virtual machine from scratch, using the guest.qcow2 
 image (There doesn't appear to be a way to automate converting the 
 VirtualBox definition to a libvirt one, so you'll need to redefine the 
 machine.

One more thing to note. The "Virtio" disk driver is more efficient than 
emulating AHCI, etc so it's best to use that. If your guest is Linux, 
then it should just pick up on the new drive as "/dev/vda". If you're 
using Windows, though, this seems to work:

 * Set the main drive as "AHCI", and create a second drive (any size) as 
 "VIRTIO".
 * Boot into the guest and install the virtio drivers from Fedora: 
 fedoraproject.org/wiki/Windows_Virtio_Drivers#ISO_contents
 * Windows should now know how to use Virtio (i.e. be able to see the 
 second disk)
 * Shut down the guest, change the main drive to use virtio, and restart 
 the guest.
 * Windows should now be able to boot from the main drive. You can 
 delete the second drive.

>
>Thanks
>
>Mark
>

-- 
For more information, please reread.

[toc] | [prev] | [next] | [standalone]

#177927

On Fri, Feb 17, 2017 at 01:00:11PM +0000, Darac Marjal wrote:
> 
> I have recently gone down this path myself. I chose qemu+kvm as my
> virtualisation platform of choice, as it seems the most 'natively Linux'
> option (that is, QEMU is FOSS and KVM is in the kernel, so no third-party
> bits needed).

Thanks very much Hans, Georgi, Darac and Teemu for the comprehensive, 
and super-quick help! This list rocks!

Sounds like the only thing that's less-than-perfect is the shared 
folders with the host, but I'll look into KVM / QEMU's documentation for 
what's possible for that. A Samba server feels sub-optimal to me (bad 
experiences with Samba at work, albeit I don't need a lot of speed for 
this use case here) but if that's the best option there is, it's doable.

Everything else looks perfect. Thanks Darac in particular for the 
step-by-step instructions on migrating the disks, and Teemu for pointing 
out I will need to get the new machines as close in spec as possible to 
the old ones so Windows doesn't barf. (Guests are Windows 7)

Much appreciated guys

Mark

[toc] | [prev] | [next] | [standalone]

#177924

[Multipart message — attachments visible in raw view] — view raw

Mark Fletcher [2017-02-17 21:20:18+09] wrote:

> My needs are fairly vanilla -- I have a 4-core-with-hyperthreading Intel 
> Core i7 920 CPU, circa 2009, and 24GB or RAM in the host.

I think Qemu fits to most of your needs.

> I run 2 VMs, not all the time, which have 2 CPUs and 4GB of RAM each.

Part of command line:

    qemu-system-x86_64 -enable-kvm -cpu host -smp cores=2 -m 4G

> Access to physical optical drive,

    -cdrom /dev/cdrom

> and virtual disks,

    -hda disk_image.img

> Shared folders with the host OS

Install samba server and use option like:

    -net user,smb=...

IP network access is also possible.

> 2D graphics is important, 3D less so.

I don't know about this. Qemu has these graphic cards (man qemu-system):


    -vga type
        Select type of VGA card to emulate. Valid values for type are

        cirrus
            Cirrus Logic GD5446 Video card. All Windows versions starting
            from Windows 95 should recognize and use this graphic card.
            For optimal performances, use 16 bit color depth in the guest
            and the host OS.  (This one is the default)

        std Standard VGA card with Bochs VBE extensions.  If your guest
            OS supports the VESA 2.0 VBE extensions (e.g. Windows XP) and
            if you want to use high resolution modes (>= 1280x1024x16)
            then you should use this option.

        vmware
            VMWare SVGA-II compatible adapter. Use it if you have
            sufficiently recent XFree86/XOrg server or Windows guest with
            a driver for this card.

        qxl QXL paravirtual graphic card.  It is VGA compatible
            (including VESA 2.0 VBE support).  Works best with qxl guest
            drivers installed though.  Recommended choice when using the
            spice protocol.

        tcx (sun4m only) Sun TCX framebuffer. This is the default
            framebuffer for sun4m machines and offers both 8-bit and
            24-bit colour depths at a fixed resolution of 1024x768.

        cg3 (sun4m only) Sun cgthree framebuffer. This is a simple 8-bit
            framebuffer for sun4m machines available in both 1024x768
            (OpenBIOS) and 1152x900 (OBP) resolutions aimed at people
            wishing to run older Solaris versions.

        none
            Disable VGA card.


> Ability to access physical USB equipment attached to the host would be
> nice but not a show-stopper.

Works in Qemu:

    -usb -usbdevice host:<vendor_id>:<product_id>

Check those ids with "lsusb" and ensure that the user has write access
to the device files, with an udev rule, for example:

/etc/udev/rules.d/qemu.rules:

    ATTR{idVendor}=="0000", ATTR{idProduct}=="1111", GROUP="qemu"

And add user to the "qemu" group.

> Minimal time futzing around to get the virtualisation solution working
> is important, as is not having to learn an entirely new paradigm to
> use the software. Stability of the result is also important.

Qemu is a command-line tool but Aqemu is a Virtualbox-like graphical
interface for it. Aqemu can show Qemu's command line so you'll learn
quickly what options are relevant to your machine.

> And finally, a neat solution to migrate my Virtualbox machines to the
> new environment is very important -- I would infinitely prefer not to
> have to re-install from scratch into the new environment

I don't know how Windows OS will handle the change of the underlying
machine but disk images should be easy to convert:

    qemu-img -O qcow2 source-image.vdi target-image.qcow2

-- 
/// Teemu Likonen   - .-..   <https://keybase.io/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///

[toc] | [prev] | [next] | [standalone]

#177929

[Multipart message — attachments visible in raw view] — view raw

Teemu Likonen [2017-02-17 15:35:28+02] wrote:

> I don't know how Windows OS will handle the change of the underlying
> machine but disk images should be easy to convert:
>
>     qemu-img -O qcow2 source-image.vdi target-image.qcow2

Must be:

    qemu-img convert -O qcow2 source-image.vdi target-image.qcow2


-- 
/// Teemu Likonen   - .-..   <https://keybase.io/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///

[toc] | [prev] | [next] | [standalone]

#177943

[Multipart message — attachments visible in raw view] — view raw

On Fri, Feb 17, 2017 at 6:20 AM, Mark Fletcher <mark27q1@gmail.com> wrote:

>
> ...Virtualbox is going away and will not be in stretch when it becomes the
> stable
> distro shortly.
>


Is this true? I've just spent 15 minutes googling for the answer, but
either my google-fu is failing me, or that info is not out there.

Thanks!

-- 
Kent

[toc] | [prev] | [next] | [standalone]

#177945

Kent West <westk@acu.edu> wrote:
> On Fri, Feb 17, 2017 at 6:20 AM, Mark Fletcher <mark27q1@gmail.com> wrote:

>> ...Virtualbox is going away and will not be in stretch when it
>> becomes the stable distro shortly.

> Is this true? I've just spent 15 minutes googling for the answer, but
> either my google-fu is failing me, or that info is not out there.

The first part of an answer is here:
https://tracker.debian.org/pkg/virtualbox 
(see, no Virtualbox in Testing, means no Virtualbox in Stretch)

And the second part is here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794466
and here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794466#93

As of right now, Virtualbox will not be allowed to be in Testing in the
future. And because it will never be in Testing, in can not be
backported to Stretch. Ever.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web