[conspire] qemu-kvm, learning, scriptability, Ewey GUI?, virt-manager :-), ...

Michael Paoli Michael.Paoli at cal.berkeley.edu
Sun Oct 2 21:51:20 PDT 2016


> Date: Mon, 26 Sep 2016 09:29:12 -0700
> From: Tony Godshall <togo at of.net>
> To: Daniel Gimpelevich <daniel at gimpelevich.san-francisco.ca.us>
> Cc: conspire <conspire at linuxmafia.com>
> Subject: Re: [conspire] (forw) Re: (forw) Re: VirtualBox
>
> GNOME Boxes?  Hmmm...
>
> "Boxes is a GNOME application in Fedora that is used to create,
> manage, and run virtual machines. It was designed with simplicity and
> ease of use in mind, building upon the harder to use qemu-based
> virt-manager.Feb 2, 2015"
>
> KVM's not hard to use.  You use -hda to give is a filename for a hard
> drive and -cdrom to give it an iso file and -boot d to tell it to boot
> from the iso for your install, and omit those two arguments
> thereafter.  And you can also use other simple arguments to reserve it
> more memory or have it be VNC-connectable or whatever.  You do need a
> CPU with virtualization capability (and enabled in your BIOS), since
> KVM doesn't degrade to a poorly performing mode if it can't modprobe
> kvm.
> # man kvm
> # man kvm-qemu

Yes, definitely, qemu-kvm is *not* that hard to use.
Sure, there's a bit of a learning curve, but it's *not* that
hard/steep.  If you want a bit 'o Ewey GUI with qemu-kvm
virt-manager is quite nice, and more than suffices for that.
Not to mention, closely relatedness in package/source, it'll stay
well matched to the qemu-kvm stuff - whereas no guarantees that'll
be the case for other "wrapper" packages/software from other
projects.  And though I use virt-manager pretty darn rarely,
sometimes it is mighty nice.  So, well worth having on-hand ...
even if one only oh so very rarely ever actually uses it.
But it *is* a nice way to visually interact with, configure,
and represent the information, and see *many* of the settings and
configuration options without resorting to man pages and the like,
so, yeah, sometimes it is quite nice (& pretty) to have, and even,
in some ways, quite useful.  I've *never* found any need/reason for
anything more Ewey GUI beyond that for qemu-kvm.

> I'm not sure super easy to use point and click is good in beneficial
> for things like this.  You lose scriptability.

Oh yes, *lovely* scriptability!!!  Here's example of my favorite
qemu-kvm script I use quite highly frequently.  I have it named TEMPLATE,
I just copy (cp -p) it to a new name - generally what I want to call
a newly to be built virtual machine, edit it a wee bit (at least typically),
usually adjusting what (if anything) I want it to use for (virtual)
drive storage, what ISO I want it to boot from, or if I want to PXE
boot, and if I want it to permanently be a "live" image, or if I'm
doing an install.  Run my script copy, and, quickly and easily have my
new virtual machine built.  Anyway, here's what that script looks like:
# < TEMPLATE expand -t 4
#!/bin/sh

# these have defaults
NAME=
MiB=

# boot/install from this (if set and non-null)
# if unset or null use first --disk
PATHTOISO=
# default PATHTOISO:
PATHTOISO="${PATHTOISO:-$(awk '/^[  ]*#/  
{next;};{if($2=="/media/cdrom9"){print $1;exit;};}' /etc/fstab)}"

# set non-null for PXE boot
PXE=

# specify first disk (will boot if PATHTOISO and PXE both unset or null
# unset or null for none
DISK=
#DISK=/dev/tigger/LV,format=raw
#DISK=/dev/sr0,device=cdrom,bus=scsi,perms=ro
#DISK=/var/tmp/scratch/HD,format=raw,sparse=true

# set non-null to skip OS installation, build guest image around disk image
IMPORT=

# set non-null to configure permanently to boot from CDROM
LIVECD=

# unset or null for none
NETWORK=
NETWORK=network=default
#NETWORK=bridge=br0
#NETWORK=bridge=br0,mac=52:54:00:3f:c0:75

# set non-null for don't automatically reboot after install completes
NOREBOOT=

# minutes to wait for VM to install (-1 forever); null or unset for default
WAIT=
WAIT=-1

# autodetection attempted if unset or null, none for no autodetection
#OS_TYPE=
OS_TYPE=linux
#OS_TYPE=none

# autodetection attempted if unset or null, none for no autodetection
#OS_VARIANT=
OS_VARIANT=debianwheezy
#OS_VARIANT=fedora16
#OS_VARIANT=ubuntusaucy
#OS_VARIANT=none

# Request a non-native CPU architecture
# null or unset to use default
ARCH=
#ARCH=arm i386 i486 i586 i686 mips mipsel ppc sparc x86_64
#ARCH=486
#ARCH=athlon
#ARCH=core2duo
#ARCH=coreduo
#ARCH=kvm64
#ARCH=n270
#ARCH=pentium
#ARCH=pentium2
#ARCH=pentium3
#ARCH=phenom
#ARCH=qemu32
#ARCH=qemu64

### DEFAUTLTS ###
# default name:
NAME="${NAME:-$(basename $0)}"
# default MiB:
MiB="${MiB:-1024}"

# common options
#VIRTINSTALLOPTS='--virt-type qemu --hvm'
VIRTINSTALLOPTS='--virt-type kvm --hvm'
# virtualization type
# --virt-type kvm \
# full hardware virtualization
# --hvm \

if [ x"$DISK" = x ]; then
     DISKarg=--nodisks
else
     DISKarg=--disk="$DISK"
fi

if [ x"$NETWORK" = x ]; then
     NETWORKarg=--nonetworks
else
     NETWORKarg=--network="$NETWORK"
fi

DISPLAY="${DISPLAY:-:0.0}" export DISPLAY
XAUTHORITY="${XAUTHORITY:-/home/m/michael/.Xauthority}" export XAUTHORITY

virt-install \
     --name="$NAME" \
     ${PATHTOISO:+--cdrom="$PATHTOISO"} \
     ${PXE:+--pxe} \
     ${DISKarg:+"$DISKarg"} \
     ${IMPORT:+--import} \
     ${LIVECD:+--livecd} \
     ${NETWORKarg:+"$NETWORKarg"} \
     --ram="$MiB" \
     ${NOREBOOT:+--noreboot} \
     ${WAIT:+--wait="$WAIT"} \
     ${OS_TYPE:+--os-type="$OS_TYPE"} \
     ${OS_VARIANT:+--os-variant="$OS_VARIANT"} \
     ${ARCH:+--arch="$ARCH"} \
     $VIRTINSTALLOPTS
#

> On Sun, Sep 25, 2016 at 5:44 PM, Daniel Gimpelevich
> <daniel at gimpelevich.san-francisco.ca.us> wrote:
>>
>> If you want to run Windows under KVM, I repeat from my message on
>> Friday: Take a serious look at GNOME Boxes.





More information about the conspire mailing list