Before going on to create the solaris HVM guest, we need first configure VNC. Facility svc will be used.
svccfg is used to configure the service
# svccfg -s xvm/xend setprop config/vncpasswd = astring: \"passwd\"
-s xvm/xend-s specifies the service
setprop config/vncpasswd = astring: \"passwd\"setprop specifies the command
Note: You can see that password is quoted by ""
Similiarly,
# svccfg -s xvm/xend setprop config/vnc-listen = astring: \"0.0.0.0\"This command is to specify the vnc-listen
Another one is svcadm, which is used to start or stop service. It can "enable", "disable", "refresh", and "restart" the service. refresh is to reload the configuration file.
Here the service is xend, which is in xvm/xend
# svcadm refresh xvm/xend; svcadm restart xvm/xendIt restarts the xen daemon xend.
OK~~~~~! Now, let's create the HVM solaris guest.
machine:root>#virt-install -n solarisH --hvm -r 1024 --vnc -f /solarisH.img -s 8 -c /export/home/newbie/sol-nv-b87.isoStill almost the same options as creating the paravirt solaris guest, -n solarisH specifies domain name, -r 1024 specifies ram size, -f /solarisH.img specifies guest image filename, -s 8 specifies the guest image size of 8G, -c /export/home/newbie/sol-nv-b87.iso indicates installing from ISO file.
The only differences are --hvm which specifies the guest works in HVM mode and --vnc which specifies the guest will have a VNC connection.
When you run the virt-install command, it will first prompt up a window asking VNC password which will be passwd as we have set up before. The rest installation process will look exactly like installing solaris on a real machine. The snapshot can be seen as below.
Note: The virt-install still has the problem with libvirt as below
libvir: Xen Daemon error : GET operation failed:
WARNING: virt-install doesn't create the configuration file for the guest image. It only creates an image with an OS system in it. The user himself needs to create the configuration file on their own. One simple configuration file can be as below:
A good reference is here: http://opensolaris.org/os/community/xen/docs/HVMdomains.htm
Once the installation is done, You can see the solaris HVM guest looks like below.
It will produce xml-format configuration file
#virsh dumpxml solarisH > solarisH.xml
Then we also need to use the facility virsh to boot the guest by xml configuration file
#virsh create solarisH.xml
Next is to connect to the VNC. We need to use the tool virt-manage.
#virt-manage
Then select the guest domain and press the button open who then will ask for the vnc password. Then a VNC window is popped up and the interface looks like below:
Another way is to manually create a configuration file as below whose name is solarisH.py and file type is python script.##########################################################
# -*- mode: python; -*-
#============================================================================
# Python configuration setup for 'xm create'.
# This script sets the parameters used when a domain is created using 'xm create'.
# You use a separate script for each domain you want to create, or
# you can set the parameters for the domain on the xm command line.
#============================================================================
import os, re
arch = os.uname()[4]
if re.search('64', arch):
arch_libdir = 'lib64'
else:
arch_libdir = 'lib'
#----------------------------------------------------------------------------
# Kernel image file.
kernel = "/usr/lib/xen/boot/hvmloader"
# The domain build function. HVM domain uses 'hvm'.
builder='hvm'
# Initial memory allocation (in megabytes) for the new domain.
#
# WARNING: Creating a domain with insufficient memory may cause out of
# memory errors. The domain needs enough memory to boot kernel
# and modules. Allocating less than 32MBs is not recommended.
memory = 1024
# Shadow pagetable memory for the domain, in MB.
# Should be at least 2KB per MB of domain memory, plus a few MB per vcpu.
shadow_memory = 8
# A name for your domain. All domains must have different names.
name = "solarisH"
# 128-bit UUID for the domain. The default behavior is to generate a new UUID
# on each call to 'xm create'.
#uuid = "06ed00fe-1162-4fc4-b5d8-11993ee4a8b9"
#-----------------------------------------------------------------------------
# the number of cpus guest platform has, default=1
vcpus=1
# enable/disable HVM guest PAE, default=0 (disabled)
#pae=0
# enable/disable HVM guest ACPI, default=0 (disabled)
#acpi=1
# enable/disable HVM guest APIC, default=0 (disabled)
#apic=1
# List of which CPUS this domain is allowed to use, default Xen picks
#cpus = "" # leave to Xen to pick
#cpus = "0" # all vcpus run on CPU0
#cpus = "0-3,5,^1" # run on cpus 0,2,3,5
# Optionally define mac and/or bridge for the network interfaces.
# Random MACs are assigned if not given.
vif = [ 'type=ioemu' ]
#----------------------------------------------------------------------------
# Define the disk devices you want the domain to have access to, and
# what you want them accessible as.
# Each disk entry is of the form phy:UNAME,DEV,MODE
# where UNAME is the device, DEV is the device name the domain will see,
# and MODE is r for read-only, w for read-write.
#disk = [ 'file:/export/home/mydisk.raw,hdc,w', 'file:/export/home/install.iso,hda:cdrom,r' ]
disk = [ 'file:/solarisH.img,hda,w']
#disk = [ 'phy:/dev/dsk/c1d0p0,hdc,w', 'file:/export/home/install.iso,hda:cdrom,r' ]
#disk = [ 'phy:/dev/zvol/dsk/mypool/mydisk,hdc,w', 'file:/export/home/install.iso,hda:cdrom,r' ]
#----------------------------------------------------------------------------
# Configure the behaviour when a domain exits. There are three 'reasons'
# for a domain to stop: poweroff, reboot, and crash. For each of these you
# may specify:
#
# "destroy", meaning that the domain is cleaned up as normal;
# "restart", meaning that a new domain is started in place of the old
# one;
# "preserve", meaning that no clean-up is done until the domain is
# manually destroyed (using xm destroy, for example); or
# "rename-restart", meaning that the old domain is not cleaned up, but is
# renamed and a new domain started in its place.
#
# The default is
#
# on_poweroff = 'destroy'
# on_reboot = 'restart'
# on_crash = 'restart'
#
# For backwards compatibility we also support the deprecated option restart
#
# restart = 'onreboot' means on_poweroff = 'destroy'
# on_reboot = 'restart'
# on_crash = 'destroy'
#
# restart = 'always' means on_poweroff = 'restart'
# on_reboot = 'restart'
# on_crash = 'restart'
#
# restart = 'never' means on_poweroff = 'destroy'
# on_reboot = 'destroy'
# on_crash = 'destroy'
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'preserve'
#============================================================================
# New stuff
device_model = '/usr/' + arch_libdir + '/xen/bin/qemu-dm'
#-----------------------------------------------------------------------------
# boot on floppy (a), hard disk (c) or CD-ROM (d)
# default: hard disk, cd-rom, floppy
boot="cda"
#boot='d'
#-----------------------------------------------------------------------------
# write to temporary files instead of disk image files
#snapshot=1
#----------------------------------------------------------------------------
# enable SDL library for graphics, default = 0
sdl=0
#----------------------------------------------------------------------------
# enable VNC library for graphics, default = 1
vnc=1
#----------------------------------------------------------------------------
# address that should be listened on for the VNC server if vnc is set.
# default is to use 'vnc-listen' setting from /etc/xen/xend-config.sxp
vnclisten="0.0.0.0"
#----------------------------------------------------------------------------
# set VNC display number, default = domid
#vncdisplay=1
#----------------------------------------------------------------------------
# try to find an unused port for the VNC server, default = 1
#vncunused=1
#----------------------------------------------------------------------------
# enable spawning vncviewer for domain's console
# (only valid when vnc=1), default = 0
vncconsole=1
vncpasswd=''
#----------------------------------------------------------------------------
# no graphics, use serial port
#nographic=0
#----------------------------------------------------------------------------
# enable stdvga, default = 0 (use cirrus logic device model)
stdvga=0
#-----------------------------------------------------------------------------
# serial port re-direct to pty deivce, /dev/pts/n
# then xm console or minicom can connect
serial='pty'
#serial='stdio'
#serial='file:/tmp/blah'
#serial='/dev/pts/0'
serial='null'
#-----------------------------------------------------------------------------
# enable sound card support, [sb16|es1370|all|..,..], default none
#soundhw='sb16'
#-----------------------------------------------------------------------------
# set the real time clock to local time [default=0 i.e. set to utc]
#localtime=1
#-----------------------------------------------------------------------------
# start in full screen
#full-screen=1
#-----------------------------------------------------------------------------
# Enable USB support (specific devices specified at runtime through the
# monitor window)
usb=1
# Enable USB mouse support (only enable one of the following, `mouse' for
# PS/2 protocol relative mouse, `tablet' for
# absolute mouse)
usbdevice='mouse'
usbdevice='tablet'
##########################################################
Note: two things in the script needs to be taken care of.
1) disk = [ 'file:/solarisH.img,hda,w']
Here you will see the disk is defined by file location, disk type, and access rights.
rather than in the pv one that you may see disk = [ 'file:/solarisH.img,0,w']
2) serial='null'
The console is none, which means when booting the guest, we cannot access by the console but we can use vnc.
Then we can boot the guest by the command
#xm create solarisH.xml
Note: here we didn't have the option -c for xm create. Neither can we use the command xm console to connect to the guest. VNC will be automatically called to display the graph of the guest.
References:
Here Sun provides a diversity of domUs ready for use: http://www.opensolaris.org/os/community/xen/How-To-8-15-06/install/AugDomUs/
Here Sun provides the sample of HOWTO make a HVM domU configuration file and HOWTO make a Solaris domU:
http://opensolaris.org/os/community/xen/docs/HVMdomains.htm
http://opensolaris.org/os/community/xen/docs/install-solaris-domu-iso.htm
http://blogs.sun.com/shalon/entry/a_summary_of_creation_of
--------------------------------------------------------ADDON-----------------------------------------------------------------------
How to choose VM ram and storage?
The machine I am using is
CPU
memory 4G
.....
When I am creating an solaris HVM guest, how much memory should it have and how much storage should be allocated for it?
Try 2G ram and 8G image
Problem 1: 2G memory is too much for a guest
it makes dom0 run slow.
Problem 2: 8G image is not enough for Solaris
when you installs Solaris express development edition, it automatically installs all the required packages and requires more than 8G, so I have installation failure. I guess it is because of running out of space.
Solution:
I choose 1G ram and 12G image for the guest, it works. You can see the working solaris guest as below:
No comments:
Post a Comment