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

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

Virtual Machines: Newbie / novice questions

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

Contents

  Virtual Machines: Newbie / novice questions rhkramer@gmail.com - 2017-05-14 14:00 +0200
    Re: Virtual Machines: Newbie / novice questions "Thomas Schmitt" <scdbackup@gmx.net> - 2017-05-14 16:30 +0200
      Re: Virtual Machines: Newbie / novice questions Ben Caradoc-Davies <ben@transient.nz> - 2017-05-14 23:30 +0200
    Re: Virtual Machines: Newbie / novice questions Patrick Bartek <nemommxiv@gmail.com> - 2017-05-14 17:20 +0200
    Re: Virtual Machines: Newbie / novice questions Ben Caradoc-Davies <ben@transient.nz> - 2017-05-14 23:50 +0200
    Re: Virtual Machines: Newbie / novice questions Kent West <westk@acu.edu> - 2017-05-15 07:20 +0200
    Re: Virtual Machines: Newbie / novice questions RavenLX <ravenlx@sitesplace.net> - 2017-05-17 15:10 +0200
      Re: Virtual Machines: Newbie / novice questions rhkramer@gmail.com - 2017-05-17 16:30 +0200
      Re: Virtual Machines: Newbie / novice questions craigswin <craigswin2016@gmail.com> - 2017-05-17 18:50 +0200
        Re: Virtual Machines: Newbie / novice questions RavenLX <ravenlx@sitesplace.net> - 2017-05-17 19:10 +0200
          Re: Virtual Machines: Newbie / novice questions Mark Fletcher <mark27q1@gmail.com> - 2017-05-18 15:40 +0200
            Re: Virtual Machines: Newbie / novice questions rhkramer@gmail.com - 2017-05-18 18:50 +0200
            Re: Virtual Machines: Newbie / novice questions deloptes <deloptes@gmail.com> - 2017-05-18 23:20 +0200
              Re: Virtual Machines: Newbie / novice questions Mark Fletcher <mark27q1@gmail.com> - 2017-05-20 07:20 +0200
                Re: Virtual Machines: Newbie / novice questions deloptes <deloptes@gmail.com> - 2017-05-20 13:00 +0200
                  Re: Virtual Machines: Newbie / novice questions Stefan Monnier <monnier@iro.umontreal.ca> - 2017-05-20 15:20 +0200
                Re: Virtual Machines: Newbie / novice questions Stefan Monnier <monnier@iro.umontreal.ca> - 2017-05-20 15:20 +0200
            Re: Virtual Machines: Newbie / novice questions RavenLX <ravenlx@sitesplace.net> - 2017-05-21 14:50 +0200
              Re: Virtual Machines: Newbie / novice questions Sven Hartge <sven@svenhartge.de> - 2017-05-21 18:20 +0200
                Re: Virtual Machines: Newbie / novice questions Stefan Monnier <monnier@iro.umontreal.ca> - 2017-05-21 19:10 +0200
                  Re: Virtual Machines: Newbie / novice questions Sven Hartge <sven@svenhartge.de> - 2017-05-21 22:30 +0200
                    Re: Virtual Machines: Newbie / novice questions Stefan Monnier <monnier@iro.umontreal.ca> - 2017-05-21 23:20 +0200
        Re: Virtual Machines: Newbie / novice questions deloptes <deloptes@gmail.com> - 2017-05-18 23:10 +0200
          Re: Virtual Machines: Newbie / novice questions Mark Fletcher <mark27q1@gmail.com> - 2017-05-20 07:20 +0200
            Re: Virtual Machines: Newbie / novice questions deloptes <deloptes@gmail.com> - 2017-05-20 13:10 +0200

Page 1 of 2  [1] 2  Next page →

#180998 — Virtual Machines: Newbie / novice questions

I've never used a VM but I wanted to ask some newbie questions about them.  

Currently, I don't see much use for one--I haven't had to run Windows in a 
very long time, which is a good thing--I used to have to occasionally run 
Windows to do something that, at the time, I couldn't do in Linux--oh, I guess 
I still have to update my Garmin maps in Windows, which I do very rarely--only 
before a long road trip or when I discover some discrepancies based on new 
road construction.

I often have parts to build all or most of my next machine around, and, 
sometimes (as now) that machine is built and has the next generation of 
software on it for "testing and tuning" (as now, I have a 2nd machine running 
Jessie while my everyday "user" is running Wheezy.

I have some assumptions / guesses about the answers to these questions, and I 
could google for answers, but maybe somebody will indulge me with answers.

   * Is it right to consider that there is somehow a base OS and the other VMs 
somehow are set up on top of it--you boot into that base OS first, and then 
have the ability to switch to another VM.  OK, I'm thinking that is not the 
case--I think I've heard of things like a hypervisor (??), and now I'm 
guessing that the machine boots first into the hypervisor and then from there 
boot into any of one or more VMS, one of which would contain what I consider 
my main or base OS?

   * I know (or I'm 99.9% sure) that the software for a VM is on separate 
partitions (except maybe some are or could be shared between the VM and the 
"base" machine, such as for my documents and such (things that I'd want to be 
accessible from any of the VMs).  

   * Can I keep a VM in a running state for instant switching to it?  (I 
presume that in that case, it will be using RAM, on the other hand, it could 
be in a non-running (either non-booted or suspended-to-disk) and not be using 
RAM?

   * I presume that booting a VM takes  about the same amount of time, maybe a 
little longer than booting the base machine /  OS (well, unless the OS in the 
VM is significantly "smaller" in terms of footprint and services started at 
boot)?

   * Can I C&P between (applicatons in) different VMs and/or the base OS?

Thanks!

[toc] | [next] | [standalone]

#181003

Hi,

rhkramer@gmail.com wrote:
>  * Is it right to consider that there is somehow a base OS

Normally there is a single real computer with its OS that runs virtual
computers as "guests".
(The Cloud might have its own habits to host VMs.)


> I'm guessing that the machine boots first into the hypervisor and then from
> there boot into any of one or more VMS, one of which would contain what I
> consider my main or base OS?

I use my real machine with its Debian 8 as my home system and have several
VMs for various development purposes. I operate them via SSH from terminal
windows of the host system.

The VMs are normal processes on the host OS which may have a host graphics
window to show their own graphics screen and to get user input. They may
have access to some hardware components of the host system (e.g. a DVD drive).
Most important is their connection to the host system and the internet
via a virtual network card.


> * I know (or I'm 99.9% sure) that the software for a VM is on separate 
> partitions

It is typically on virtual disks which on the host system are data files
or disk partitions. Sharing of files may e.g. be done via services over
the virtual network.


>    * Can I keep a VM in a running state for instant switching to it?

Yes. As long as your real machine has enough memory to serve all processes
of the host OS and as long as you don't need a piece of hardware which
the VM uses exclusively.


> I presume that in that case, it will be using RAM, on the other hand,
> it could be in a non-running (either non-booted or suspended-to-disk)
> and not be using RAM?

If the real RAM of the host system does not suffice, then swapping will
begin. If the swap space is exhausted, processes will die.


>    * I presume that booting a VM takes  about the same amount of time, maybe
> a little longer than booting the base machine

If the VM has the same CPU type as the host system and can use kvm, then
it is not supposed to compute much slower than on real hardware. Access to
virtual disks might be slow compared to the disk speed on the host system.


>    * Can I C&P between (applicatons in) different VMs and/or the base OS?

Afaik, the graphics windows of VM do not show text but rather mindless
pixels. So no copy+paste.
But you may use the display of your host system as X terminal which starts
applications on the VMs. (As said, the virtual network is essential in most
use cases.)

-------------------------------------------------------------------------

Try it.

For example, on a modern 64 bit machine with 8 GiB of RAM, get one of the
ISOs at
  https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/
(let's say: debian-live-8.8.0-amd64-xfce-desktop.iso )
and start qemu+kvm with 4 GiB of RAM by

  qemu-system-x86_64 -enable-kvm -m 4096 -cdrom debian-live-8.8.0-amd64-xfce-desktop.iso  

A graphics window should pop up and show you the boot menu.

If you create a file for a virtual disk by command qemu-img

  qemu-img create vm_64gb_disk.qemu 64G

you may attach it to the starting VM by

  qemu-system-x86_64 ... \
                     -hda vm_64gb_disk.qemu

For my VMs which shall be operated without graphics screen, i let qemu
forward a host port (here 4567) to port 22 of the guest, where a SSH
server will be set up by installation to offer login:

  qemu-system-x86_64 ... \
                     -net nic -net user,hostfwd=tcp::4567-:22 

When the system is installed, i add option -nographic and access the
then headless system by

  ssh -p 4567 my_user@localhost

The option -cdrom and the ISO image are then not used any more.


There are VM control tools by which one can create and manage VMs.
But i have no experience with them.


Have a nice day :)

Thomas

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

#181007

On 15/05/17 02:27, Thomas Schmitt wrote:
> For my VMs which shall be operated without graphics screen, i let qemu
> forward a host port (here 4567) to port 22 of the guest, where a SSH
> server will be set up by installation to offer login:
>   qemu-system-x86_64 ... \
>                      -net nic -net user,hostfwd=tcp::4567-:22

And if you want QEMU to listen only on localhost and not allow remote 
network connections, this becomes:

qemu-system-x86_64 ...
     -net nic -net user,hostfwd=tcp:127.0.0.1:4567-:22

Kind regards,

-- 
Ben Caradoc-Davies <ben@transient.nz>
Director
Transient Software Limited <http://transient.nz/>
New Zealand

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

#181004

On Sun, 14 May 2017 07:51:18 -0400 rhkramer@gmail.com wrote:

> I've never used a VM but I wanted to ask some newbie questions about
> them.  

Then first you should read the manual and the FAQs.  Here's the link to
the Documentation page for VirtualBox, one of the more popular and
easy to set up VMs.

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

B

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

#181009

On 14/05/17 23:51, rhkramer@gmail.com wrote:
> * Can I C&P between (applicatons in) different VMs and/or the base OS?

While you can do this in emulators like VMWare Player, QEMU does not 
support it. A popular solution for QEMU is Spice 
<https://www.spice-space.org/spice-user-manual.html>. A simpler but less 
feature-rich solution is connecting with ssh, as described earlier in 
this thread.

Kind regards,

-- 
Ben Caradoc-Davies <ben@transient.nz>
Director
Transient Software Limited <http://transient.nz/>
New Zealand

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

#181014

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

On May 14, 2017 06:51, <rhkramer@gmail.com> wrote:


   * Is it right to consider that there is somehow a base OS and the other
VMs somehow are set up on top of it--you boot into that base OS first, and
then have the ability to switch to another VM.  OK, I'm thinking that is
not the case--I think I've heard of things like a hypervisor (??), and now
I'm guessing that the machine boots first into the hypervisor and then from
there boot into any of one or more VMS, one of which would contain what I
consider my main or base OS?


I'm unsure about the hypervisor route, but in my case, I'm running Debian
Sid on a 12 MiB Dell with a TB SSD. Then on top of that I'm running
VirtualBox (aptitude install virtualbox). Within that app, I've created
several virtual machines (4 GiB RAM, 120 GiB drive, 64M video RAM, etc).
For each one, you turn it on, and it's just like turning on a physical PC
(with a VirtualBox firmware (BIOS/UEFI) instead of a Dell firnware). The
firmware splashscreen comes up, and complains that it can't find an OS to
boot. I then load a Windows7 or 10 or XP or DOS or Debian netinstall or etc
.ISO (or similar) file into the virtual machine's virtual CD drive (or a
real CD into the real drive, mapping that to the VB's virtual CD drive),
and boot and install that OS. Now I can boot into that OS at will, in a
window (or full-screen), and have a fully-functioning second (or third, or
tenth, with enough resources) sitting on top of my Debian Sid base. I can
leave those VMs running, or shut them down, or suspend them, as I wish.
With VirtualBox I can share a folder/partition, and/or the clipboard for
cut/paste, either direction.


   * I know (or I'm 99.9% sure) that the software for a VM is on separate
partitions (except maybe some are or could be shared between the VM and the
"base" machine, such as for my documents and such (things that I'd want to
be
accessible from any of the VMs).


Not necessarily a separate partition. The virtual machine is really just a
few files, but the main file is essentially the entire VM. You can move it
to a separate partition, but no need. You can copy/move/backup that file to
copy/move/restore the entire virtual machine, even to another physical box.


   * Can I keep a VM in a running state for instant switching to it?  (I
presume that in that case, it will be using RAM, on the other hand, it could
be in a non-running (either non-booted or suspended-to-disk) and not be
using
RAM?


Yes.


   * I presume that booting a VM takes  about the same amount of time,
maybe a
little longer than booting the base machine /  OS (well, unless the OS in
the
VM is significantly "smaller" in terms of footprint and services started at
boot)?


Pretty close to the same amount of time as physical hardware, with a little
bit of overhead.


   * Can I C&P between (applicatons in) different VMs and/or the base OS?


With VirtualBox, yes. VMWare, also, if I recall correctly. I'm not sure
about other vm apps, like Qemu.


Thanks!


Lots of RAM and a roomy SSD make virtual machines handy to have around. A
lack of those resources might present you with a miserable experience.

-- 
Kent

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

#181053

On 05/14/2017 07:51 AM, rhkramer@gmail.com wrote:
> I've never used a VM but I wanted to ask some newbie questions about them.
<snip>

I regularly use Virtual Machines quite a lot for testing purposes. I'll 
be glad to cover your questions. For these questions, I'll be answering 
them based on using VirtualBox.

>     * Is it right to consider that there is somehow a base OS and the other VMs
> somehow are set up on top of it--you boot into that base OS first, and then
> have the ability to switch to another VM.  OK, I'm thinking that is not the
> case--I think I've heard of things like a hypervisor (??), and now I'm
> guessing that the machine boots first into the hypervisor and then from there
> boot into any of one or more VMS, one of which would contain what I consider
> my main or base OS?

Basically VirtualBox is a program you install into your computer. It's 
much like any other program you have. You run it and from there you can 
create new virtual machines you can launch from within VirtualBox (or 
right click on a machine and create a desktop shortcut for easy access 
to just the machine without running the VirtualBox program itself). So 
yes, you "base OS" as you call it (which is called a "host" in Virtual 
Machine language) is the operating system you boot into. Each Virtual 
Machine you create is called a "guest" machine.

>     * I know (or I'm 99.9% sure) that the software for a VM is on separate
> partitions (except maybe some are or could be shared between the VM and the
> "base" machine, such as for my documents and such (things that I'd want to be
> accessible from any of the VMs).

Actually no. The software for the VM are stored in machine files. In 
VirtualBox you can even determine where to save these machine files on 
your hard drive. These machine files can also be exported (which I do 
after each update) so that you can keep them backed up on a USB stick, 
SD card, what have you. If something goes wrong you can then import that 
machine (from the exported file) and go back to work. I usually do this 
but any time I go to use a machine, I clone it first, then I use it, and 
destroy it when done. This way I don't use the original virtual machine 
and it's handy if I should need an identical one for testing something 
(which I often do). I only use the original one to do software updates 
on that machine.

As for shared documents, yes you can specify a folder on your hard drive 
(one or more, actually) and read (and even select settings to write to) 
that shared folder. This is the only way I know of to share files 
between the "host" and "guest" machines. For this, you have to use the 
Device menu to insert a "Guest Additions CD" (which is labeled in the 
Device menu for easy access). Then know the right command lines to mount 
that CD if it doesn't mount automatically, and finally you can move to 
that CD in the guest machine and run the appropriate program to install 
the guest additions. NOTE: In Linux you need gcc and build-essentials 
installed *first* before doing this. Also some updates may render the 
guest additions inoperable so you'll want to re-install them (especially 
if VirtualBox itself went through an update). Guest Additions will work 
on most Windows and Linux OSs. They do NOT work if you are using an 
Android "guest" machine as there aren't any built (that I know of) for 
an Android OS.

>     * Can I keep a VM in a running state for instant switching to it?  (I

Absolutely. You can even close the main VirtualBox window and keep the 
virtual machine running.

> presume that in that case, it will be using RAM, on the other hand, it could
> be in a non-running (either non-booted or suspended-to-disk) and not be using
> RAM?

Yes, it uses ram. You could also take a "snapshot" or pause it and go 
unpause it later, I believe. I'm not 100% sure on this because I 
personally never had to use such a feature. However, I have kept VMs 
running and then even suspended my whole computer (ie. the host machine 
or as you call it "base OS") and then when I came back and took the 
machine out of suspended or sleep mode, the virtual machine also was 
awakened and running instantly.

>     * I presume that booting a VM takes  about the same amount of time, maybe a
> little longer than booting the base machine /  OS (well, unless the OS in the
> VM is significantly "smaller" in terms of footprint and services started at
> boot)?

Yes, it would depend on the machine. But I don't find it is all that 
slow. In fact, sometimes it is about as fast as booting it via hardware. 
It depends on how fast your computer is, and also how much RAM, and CPUs 
you have set up for the virtual machine when you first put it together. 
There may even be other settings that might help with this, including 
hardware virtualization (which you should make sure your host (ie. 
"base") machine's BIOS supports and that it is turned on/activated. It 
might not always be necessary - but it depends on the type of virtual 
machine you need to use. For good measure, I have mine turned on and I 
don't notice any overall performance hit on my computer as a whole as a 
result.

>     * Can I C&P between (applicatons in) different VMs and/or the base OS?

Yes. With the Guest Additions installed, you can (see above). Each VM 
must have the Guest Additions installed in order for you to use this 
function.

I hope this helps. I find using Virtual Machines very useful for 
testing, development and also for trying out new linux distributions. I 
keep a Windows one handy just in case I need to test something or do 
something. Those Windows VMs though are a pain. Just warning you. If you 
don't absolutely NEED one, I'd advise not even bothering. I'm seriously 
considering just deleting mine. Some Windows programs might be runnable 
in WINE rather than in a Windows VM.

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

#181061

Raven,

Thanks!

Randy Kramer

On Wednesday, May 17, 2017 09:03:51 AM RavenLX wrote:
--< good stuff snipped >--

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

#181068

On 05/17/2017 06:03 AM, RavenLX wrote:
> Those Windows VMs though are a pain. Just warning you. If you don't 
> absolutely NEED one, I'd advise not even bothering. I'm seriously 
> considering just deleting mine. 

Can you expand on that?  New to VMs, considering them as an alternative 
to dualboot, with Stretch as host and Win7 as a guest to run Vectorworks.

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

#181071

On 05/17/2017 12:42 PM, craigswin wrote:
> 
> 
> On 05/17/2017 06:03 AM, RavenLX wrote:
>> Those Windows VMs though are a pain. Just warning you. If you don't 
>> absolutely NEED one, I'd advise not even bothering. I'm seriously 
>> considering just deleting mine. 
> 
> Can you expand on that?  New to VMs, considering them as an alternative 
> to dualboot, with Stretch as host and Win7 as a guest to run Vectorworks.

I am not a fan of windows, no how, no way. So I admit I may be (a little 
more than) a tad biased.

But booting into a Windows VM is hard. You can't back up/export without 
losing your license and having to call MS (which is why I don't even 
bother) to have them 'fix' it. And updates take forever. My laptop is 
kinda old so it also bogs down the machine sometimes. In addition, the 
internet part doesn't always work. Sometimes it stalls and you have to 
reboot the windows VM to get it working again (maybe something not set 
right, who knows).

My normal workflow includes doing updates on the base VM (which take a 
long time), then doing a disk cleanup, then sdelete to zero out the 
unused areas. Next I would clone (at the command line) the VM disk file 
so that it is fully compressed. Then I export. Not doing this to 
compress it as much as possible results in a huge exported backup file.

I rather back up the exported machine, and then clone it if I need to 
use a Windows VM. This saves "messing up" windows and having to take 
half a day or more to reinstall everything, including programs, etc. and 
updates, etc. etc.

Windows 10, at least, is very slow with updates on a virtual machine.

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

#181094

On Wed, May 17, 2017 at 12:57:57PM -0400, RavenLX wrote:
> On 05/17/2017 12:42 PM, craigswin wrote:
> >
> >
> >On 05/17/2017 06:03 AM, RavenLX wrote:
> 
> But booting into a Windows VM is hard. You can't back up/export without
> losing your license and having to call MS (which is why I don't even bother)
> to have them 'fix' it. And updates take forever. My laptop is kinda old so
> it also bogs down the machine sometimes. In addition, the internet part
> doesn't always work. Sometimes it stalls and you have to reboot the windows
> VM to get it working again (maybe something not set right, who knows).
> 
> My normal workflow includes doing updates on the base VM (which take a long
> time), then doing a disk cleanup, then sdelete to zero out the unused areas.
> Next I would clone (at the command line) the VM disk file so that it is
> fully compressed. Then I export. Not doing this to compress it as much as
> possible results in a huge exported backup file.
> 
> I rather back up the exported machine, and then clone it if I need to use a
> Windows VM. This saves "messing up" windows and having to take half a day or
> more to reinstall everything, including programs, etc. and updates, etc.
> etc.
> 
> Windows 10, at least, is very slow with updates on a virtual machine.
> 

This is the most unbelievable overkill. Windows VMs work just fine in 
VirtualBox. When it comes to backup, I have my backup scripts check the 
machines are down and if they are, include the virtual disks in the main 
system backup, and if not, skip them for that night. There is no 
Windows-level backup, it's all done at the host level.

For this to work it has to be OK to down the Windows machines in order 
to back them up,otherwise you risk Windows deciding to do a pointless 
disk write in the middle of your backup and invalidate it. That isn't a 
problem for me; if it were, I would either schedule a maintenance window 
and back them up then, or look into Windows-level backup solutions 
(which _still_ have no need for the nuclear-warhead-to-slice-a-banana 
approach described above).

Restore is smooth, and no license issues -- the Windows machine never 
knows anything happened.

Mark

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

#181097

On Thursday, May 18, 2017 09:35:48 AM Mark Fletcher wrote:
> This is the most unbelievable overkill. Windows VMs work just fine in
> VirtualBox. When it comes to backup, I have my backup scripts check the
> machines are down and if they are, include the virtual disks in the main
> system backup, and if not, skip them for that night. There is no
> Windows-level backup, it's all done at the host level.
> 
> For this to work it has to be OK to down the Windows machines in order
> to back them up,otherwise you risk Windows deciding to do a pointless
> disk write in the middle of your backup and invalidate it. That isn't a
> problem for me; if it were, I would either schedule a maintenance window
> and back them up then, or look into Windows-level backup solutions
> (which _still_ have no need for the nuclear-warhead-to-slice-a-banana
> approach described above).
> 
> Restore is smooth, and no license issues -- the Windows machine never
> knows anything happened.

I'd like to understand your answer a little better, in particular, why you 
have no issues with Windows licensing.

As background, I remember when (although I'm pretty sure I had already 
switched to LInux), Microsoft started the policy of making it difficult to 
upgrade a system without possibly buying a new Windows license.  I never did 
it (under that policy), but iir/uc, if you did certain upgrades to a system, 
your Windows would stop working, and you'd have to call them to get some kind 
of code or whatever, or, they might tell you that they consider that so much 
of an upgrade that they'd insist you buy a new copy of Windows.

As to those certain things, I don't recall that either, but could include 
things like disk, video card, processor and / or mother board upgrades.

So that is what I'm concerned about.

Maybe I should ask, how did you get Windows on the system you are discussing--
I mean, did you buy the machine with Windows on it, and then add Debian to it, 
setting it up so that Debian is the host system for the VM system, and somehow 
converted Windows to work in a VM?  

Or maybe you obtained a system without Windows, then bought a license and 
installed Windows in a VM?  (I'm not sure there is any difference between this 
scenario and the previous one as far as Windows is concerned.)

I guess in either case, have you made hardware upgrades that, perhaps in other 
circumstances, might have "triggered" the need for upgrade permission (or a 
new license) from Microsoft?

If so, did having Windows in a VM avoid that problem?

Oh, (on more careful reading) you're talking about a restore rather than a 
hardware upgrade--hmm, I don't remember (maybe I never knew) whether a similar 
Microsoft policy had to do with restores?

Or, am I totally confused???  (Well, I probably am, if not about this, lots of 
other things ;-)

regards,
Randy Kramer

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

#181107

Mark Fletcher wrote:

> On Wed, May 17, 2017 at 12:57:57PM -0400, RavenLX wrote:
>> On 05/17/2017 12:42 PM, craigswin wrote:
>> >
>> >
>> >On 05/17/2017 06:03 AM, RavenLX wrote:
>> 
>> But booting into a Windows VM is hard. You can't back up/export without
>> losing your license and having to call MS (which is why I don't even
>> bother) to have them 'fix' it. And updates take forever. My laptop is
>> kinda old so it also bogs down the machine sometimes. In addition, the
>> internet part doesn't always work. Sometimes it stalls and you have to
>> reboot the windows VM to get it working again (maybe something not set
>> right, who knows).
>> 
>> My normal workflow includes doing updates on the base VM (which take a
>> long time), then doing a disk cleanup, then sdelete to zero out the
>> unused areas. Next I would clone (at the command line) the VM disk file
>> so that it is fully compressed. Then I export. Not doing this to compress
>> it as much as possible results in a huge exported backup file.
>> 
>> I rather back up the exported machine, and then clone it if I need to use
>> a Windows VM. This saves "messing up" windows and having to take half a
>> day or more to reinstall everything, including programs, etc. and
>> updates, etc. etc.
>> 
>> Windows 10, at least, is very slow with updates on a virtual machine.
>> 
> 
> This is the most unbelievable overkill. Windows VMs work just fine in
> VirtualBox. When it comes to backup, I have my backup scripts check the
> machines are down and if they are, include the virtual disks in the main
> system backup, and if not, skip them for that night. There is no
> Windows-level backup, it's all done at the host level.
> 
> For this to work it has to be OK to down the Windows machines in order
> to back them up,otherwise you risk Windows deciding to do a pointless
> disk write in the middle of your backup and invalidate it. That isn't a
> problem for me; if it were, I would either schedule a maintenance window
> and back them up then, or look into Windows-level backup solutions
> (which _still_ have no need for the nuclear-warhead-to-slice-a-banana
> approach described above).
> 
> Restore is smooth, and no license issues -- the Windows machine never
> knows anything happened.
> 
> Mark

There are the so called snapshots, which you can make and then include in
your back up.  No need to down the VM.

There is also generally no problem with licenses after reinstall as soon as
you have your activation key or the OEMs disks/dvds. On most computers sold
with windows the key is a sticker somewhere at the back, bottom or
whatever.

regards

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

#181129

On Thu, May 18, 2017 at 11:10:00PM +0200, deloptes wrote:
> Mark Fletcher wrote:
> 
> > On Wed, May 17, 2017 at 12:57:57PM -0400, RavenLX wrote:
> >> On 05/17/2017 12:42 PM, craigswin wrote:
> >> >
> >> >
> >> >On 05/17/2017 06:03 AM, RavenLX wrote:
> >> 
> 
> There are the so called snapshots, which you can make and then include in
> your back up.  No need to down the VM.
> 
> There is also generally no problem with licenses after reinstall as soon as
> you have your activation key or the OEMs disks/dvds. On most computers sold
> with windows the key is a sticker somewhere at the back, bottom or
> whatever.
> 

I may be wrong but I don't think snapshots can be scheduled, but rather 
must be initiated -- so not really suitable for an automated backup 
solution. And as the conventional wisdom goes, if a backup isn't 
automated, you're not doing a backup.

Maybe you could use a scheduled vboxmanage command to do the snapshot, I 
suppose. But what happens to concurent changes the guest makes to itself 
while it is being snapshotted -- the snapshot presumably takes a finite 
amount of time?

Mark

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

#181136

Mark Fletcher wrote:

> I may be wrong but I don't think snapshots can be scheduled, but rather
> must be initiated -- so not really suitable for an automated backup
> solution. And as the conventional wisdom goes, if a backup isn't
> automated, you're not doing a backup.
> 

Yes for VM it is possible only if you use ESX server and licensed VM Ware
not the VM Player, but honestly if you do not change anything in the VM,
why would you need a backup. I would design the backup to pull everything
that is placed in a specific directory and is fresher as 1 day. When you
need to backup a VM, pull a snap shot into this directory and it will be in
the backup. A Win 7 VM has about 60G ... I don't know how you guys backup,
but space at private level is not that cheep.

> Maybe you could use a scheduled vboxmanage command to do the snapshot, I
> suppose. But what happens to concurent changes the guest makes to itself
> while it is being snapshotted -- the snapshot presumably takes a finite
> amount of time?

This is solved by the client. The VM or VBox will first do the snapshot and
than propagate the changes done during the time of the snapshot.
No need to worry about this.

regards

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

#181140

> Yes for VM it is possible only if you use ESX server and licensed VM Ware

Then better use Free Software, such as kvm, VirtualBox, ...


        Stefan

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

#181141

>> There are the so called snapshots, which you can make and then include in
>> your back up.  No need to down the VM.
[...]
> I may be wrong but I don't think snapshots can be scheduled, but rather 
> must be initiated

I have no idea what that means.  The way it normally works is that you
have a backup script run from cron and that script starts by creating
a snapshot (e.g. with `lvcreate -s`), backup that snapshot, then destroy
the snapshot.  As long as your backup script runs as root this is
very straightforward.


        Stefan

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

#181184

On 05/18/2017 09:35 AM, Mark Fletcher wrote:
> This is the most unbelievable overkill. Windows VMs work just fine in
> VirtualBox. When it comes to backup, I have my backup scripts check the
> machines are down and if they are, include the virtual disks in the main
> system backup, and if not, skip them for that night. There is no
> Windows-level backup, it's all done at the host level.

My backups are done in the host too. Thing is, I want to back up the 
settings (ie. shared directory settings, machine settings, etc.) as 
well. I can't remember all the settings to the VMs I use. Exporting will 
back up everything in one neat package.

> For this to work it has to be OK to down the Windows machines in order
> to back them up,otherwise you risk Windows deciding to do a pointless
> disk write in the middle of your backup and invalidate it. That isn't a
> problem for me; if it were, I would either schedule a maintenance window
> and back them up then, or look into Windows-level backup solutions
> (which _still_ have no need for the nuclear-warhead-to-slice-a-banana
> approach described above).

I shut down virtual machines so they aren't running during the export 
process.

> Restore is smooth, and no license issues -- the Windows machine never
> knows anything happened.

However, the virtual hard disk is a pretty large size. My method 
compresses it further so that the size of the backup is much smaller.

This has been the easiest and most effective way I have found so far. 
However, I might take a closer look at backing up only the virtual 
machine's hard drive along with a text file describing the machine's 
settings, then try to re-create the machine and see if it will lose the 
licensing or not.

Right now I have a lot on my plate so what I'm doing is still going to 
have to be the process until I find time to dig deeper into this.

Thank you for your reply and info.

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

#181199

RavenLX <ravenlx@sitesplace.net> wrote:

> However, the virtual hard disk is a pretty large size. My method
> compresses it further so that the size of the backup is much smaller.

Have a look at "borg". It is ideal to backup VMs (or anything using
large files with only marginal changes inside) and I have been using it
for my Virtualbox VMs for a very long time.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

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

#181201

>> However, the virtual hard disk is a pretty large size. My method
>> compresses it further so that the size of the backup is much smaller.
> Have a look at "borg". It is ideal to backup VMs (or anything using
> large files with only marginal changes inside) and I have been using it
> for my Virtualbox VMs for a very long time.

You might also like `bup` which does the same kind of deduplication, so
can also be used on large files that change only in small parts.


        Stefan

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web