[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Re: Little Howto for newbie - Installing FS for new domains in Xen1.2




"Yan-Ching CHU" <cs0u210a@xxxxxxxxxxxxxxx> writes:

>     I will maintain the most update version on 
> http://www.csc.liv.ac.uk/~u2ycc/xen/xen-install-domain-fs-howto.txt

Thanks - we should probably merge this with Jan's FAQ and check
it into the BK repository.

I've added a couple of comments:
  
> Preparation
> ===========
> We need the Xen 1.0 ISO image (xendemo-1.0.iso) from 
> 
> http://www.cl.cam.ac.uk/Research/SRG/netos/xen/downloads/

http://www.cl.cam.ac.uk/netos/xen/downloads/

The 1.2 CD will be released very soon, so we should probably talk
in terms of 1.2.

It's probably also worth stating that Xen 1.0 and 1.1 are
not under active development/maintenance. 
 
> and burn it into CD. It contains a working Redhat 9 distribution
> with that we can use it to populate a quick file system very easily
> without going through the installation procedure of those standard 
> Linux distributions. The Xen 1.2 ISO will be released soon but
> it may not match the description here.

I'm not sure that I'd recommend installing from the DemoCD, at
least not if if you've got some proper RedHat/SuSE/Debian/etc
CD's to hand. To get everything to fit on the CD I had to remove
important stuff such as the rpm database. This could probably be
rebuilt, but its easiest just to use the proper installation
CDs. After using the CDs to install a file system for domain0, I
just drop a suitable xen.gz, xenolinux.gz and /boot/grub/menu.lst
and I'm ready to go.

Installation of other domains can be achieved just by doing an
appropriate mkfs, mount, 'cp -a' etc.
> Copy "defaults" to another config file, for that you may want to refer
> to it later:
> # cd /etc/xc && cp defaults domain1.conf
> 
> Edit "domain1.conf" -

Rather than calling the file domain1, call it 'myvm1' or
something. [In our terminology, Virtual Machines run in domains,
and this VM could end up being assigned any domain id -- if the
VM reboots, it'll certainly get a different domain id.

We rather regret that we didn't just assign domain ids pseudo
randomly, just so people didn't write scripts that rely on
guessing the id.

> 
> Step 4 - You can leave it or if your ip address is public and don't want the
> new domain to use it. You may want to change to only local link address: 
> vfr_ipaddr  = [ XenoUtil.add_offset_to_ip('169.254.1.0',vmid) ]

....
 
> Now everything should be ready, create the new domain with "xc_dom_create.py"
> with your own config file overriding "defaults":
> # xc_dom_create.py -fdomain1.conf -Dvmid=1

If you're calling the file 'myvm1.conf', why take a parameter
called vmid?

You might as well have a separate fully specified config file for
each vm you want to start e.g. myvm_for_apache, myvm_for_imap
etc.

Being able to pass parameters into the config file is useful if
you're using it as a template for starting multiple similar
domains.
 
> SSH into the new domain by its IP, which is dynamic according to the actual 
> domain ID - it may not necessarily be the "vmid" you entered.
> ssh root@xxxxxxxxxxx

More domain id confusion here.

In your script you've given the VM an IP address based on the
vmid, so this will always work fine.



Thanks for your help!

Ian



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.