[Xen-users] Basic questions - numbered

[ted <thilts@xxxxxxxxxxxxxxxx>]

I know you guys are all very busy so I have numbered my questions. It's 
too much to expect one person to answer all these questions and 
comments. These questions are not directly related but they are my 
difficulties and comments associated with Xen and the LIVE CD. With SuSE 
planning to include Xen in a forthcoming distribution some of my 
difficulties and comments may be worth considering or even altering and 
included in a Wikki or FAQ section.
1. Beta2 Live CD-ROM -- boot issues

The greatest thing since sliced bread.

After over a month I got access to a high speed Internet connection and 
downloaded LIVE CD Beta2.
It appears to work so my problem is local to my LAN machines. Perhaps 
this problem should not be sent to the list.  I do so only because of 
the possibility that the LIVE CD (Beta2)  won't boot.and there might be 
a boot directive that will handle this problem. The problem is probably 
caused by a combination of CD drive and Bios and I don't expect any help 
with a hardware/firmware problem -- perhaps there is something I am 
overlooking.
I tried it (the CD) on 3 relatively modern machines running XP and XP 
Pro although that does not matter as it's a Live CD.  The Live CD ran 
okay as far as I used it (both in text and windows/graphic mode -- nice 
job).  Then I tried it on two Linux machines (again that does not matter 
as it's a Live CD).  But the Live CD would not boot.  Ouch!!! After 
several days of testing I discovered (even though the bios was properly 
set so the CD should boot) that even an OS independent Smart Boot could 
not force the CD to boot nor even detect it. Even a SuSE CD self booting 
installation would not boot.
However, using a SuSE installation floppy disk (self booting) I could 
launch a CD-ROM installation and the DVD and CD drives were operational. 
Logs on the existing Linux installation show they were correctly 
detected. In other words, this proved that the issue was confined to 
"booting" associated with CD and DVD drives and the drives work okay 
otherwise. On my machine these drives (DVD and CD)  are controlled from 
a Promise ultra 66 IDE extension card giving me a total of 8 drive slots 
on the Linux machine. Although they (DVD and CD drives) are connected on 
IDE slots as sr0 and sr1 (on the installed SuSE 6.4 system), they are 
classified as scsi and given channel, id, and lun as well as drive 
designations hdi and hdj.  I think this is the reason why your Live CD 
will not boot on my Linux system. It's the actual physical CD drive when 
called by the Bios that is not detected or refuses to boot. This problem 
is bound to reoccur many times once other's of my ilk and machinery get 
involved with Xen and products like the Live CD.  I'm only guessing, but 
I think the only answer is a floppy image that will boot specifically 
your Live CD (or behave in the manner of the SuSE installation floppy) 
having previously been given some kind of drive information in order to 
detect it or a modification to your Live CD boot process aimed at this 
kind of problem.
I don't know how the Live CD will ever boot if the CD drive somehow 
impairs that action -- if that is what is happening. If the SuSE 
installation boot floppy can detect and use the CD but the CD drive 
won't boot then we have to somehow chain boot from floppy to Live CD. 
Since I have this identical problem on 2 Linux machines (one with the 
Promise card and one without) I think perhaps the problem is in the boot 
directive when the bios turns execution control over to the CD drive. 
Both Linux machines seem to have the same Bios. If the Bios is the 
problem and not the CD or DVD drive then the problem may not be fixable 
and I will be unable to use either of these Linux machines. The XP 
machines have a different Bios. All machines have different makes of CD. 
Should I be replacing or relocating the CD drive??? Does it sound like a 
Bios problem??? I don't expect help on a hardware/firmware problem but 
can you give me any help (in the form of a boot directive) for this 
problem??? I will provide any details you request.
2. Machine application processing architecture.

Let's say (on the Linux machine with 8 hard drive slots where 2 are for 
the DVD and CD) I have taken one of these 6 hard drives, created a bunch 
of logical partitions with the target usage being Xen usage.  I am 
assuming here that I can place (in each of these logical partitions) a 
unique and unaltered Linux OS (like Mandrake, Gentoo, etc., as long as 
they have a kernel versions of GNU/Linux 2.6.x ) which can then be 
"virtualized" (as domains, 1, 2, 3, etc)  by the Xen-based system using 
the xm commands.
The reason I bring this up is that on this Linux machine I have SuSE 6.4 
(kernel 2.2.17 -- not suitable for Xen) and I want to keep this 
installation on the machine. The idea is to boot on the existing Linux 
or boot on a Xen-based installation (perhaps several).  I thought I 
would try putting SuSE 9.1 (kernels 2.6.x) in the first of these logical 
partitions on a dedicated hard drive. This would be the base OS to 
become an Xen system. So, to get started, I formated (ext3) one of the 6 
hard drives (that later I would partition into many logical ext3 
partitions). But first I would simply try to install SuSE 9.1 on the 
entire hard drive as a test of the installation process.  Good thing I 
tried this. To my surprise, the SuSE installation software package did 
not like the idea of residing on the same machine as an existing SuSE 
installation (it assumes one instance of the same SuSE installation -- 
not multiple instances) and all forced efforts on my part to do so 
appeared to be leading to the destruction of the original installation 
(even after going into the advanced manual steps of defining the 
partition for the installation but the software wanted to treat it as a 
change to a data partition).  I want to use the 9.1 (or 9.2 or 9.3) SuSE 
distribution to form my Domain 0 in the first of these partitions that I 
want to create.  

The Xen maual indicates we should simply install additional OS systems 
from the disk(s) that make up the distribution.  But if this problem 
described above can happen -- as it did with me -- one cannot assume 
that every effort to install another OS will be straight forward and it 
might be advantageous to come up with a different manner of doing this. 
SuSE support in any form (unless I buy the expensive Enterprise Server 
support package) does not extend to this kind of installation situation. 
Who needs problematic installations anyway.  So I could do the 
installations on another machine and "dd" that installation into the 
target partition and with a way  of booting up the Xen-based (SuSE). 
But to create the Xen-based (SuSE) Dom 0 I first need to have the SuSE 
installation bootable.  I am assuming here that not only can I use these 
logical partitions in this manner but I can move various Linux OS's into 
the empty logical partitions in the same way (using the Linux "dd" 
command).  If there were hardware differences (hard drives, NIC, etc.) I 
would have to change the appropriate config files.  Although on the SuSE 
list there was quite a discussion regarding how easy it was to move a 
distribution from one machine to another or change the CPU board and 
that sort of thing. Alternatively and probably desireable (this machine 
has pluggable hard drives) and I could by moving hard drives around and 
transfering the partition image by means of dd eliminate the 
discrepencies introduced by different machines and avoid any 
configuration discrepencies. This would necessitate a temporary hard 
drive configured with the same partitions and plugged into the same hard 
drive slot.
Are there important issues I have missed in considering the doing of 
this???
If this seems feasible (moving a pre built Linux installation into a 
logical partition for this purpose) could I have an example of a GRUB 
configuration file as a kind of template for a dedicated multiple 
logical partitions boot???
Is the "grub.conf" file associated with the LIVE CD a good example of 
what I am looking for and how do I discover it's contents??? I cannot 
easily check this out as the LIVE CD only runs on my XP production 
machines (as mentioned above) and I cannot bring them down right now.
3. Live CD as hard drive installed example.

Can I do the following?

"dd" the Live CD into one of these partitions mentioned above and boot 
to this "copy" on hard drive instead of CD???
If so does the partition need to be formatted (I assume the iso image 
copied contains all the bits associated with both file system 
construction as well as the installation existing within the file 
system) so when booted should run identical to the LIVE CD without any 
file system formatting (ext2, ext3, reiser, etc.)???
What would the GRUB boot file for this purpose look like -- could I 
chainloader (hdx,y) + 1 to it -- or is there a better way???
If it works, I think the above "hard drive as CD" should behave as a CD 
but much faster???
Is there a way of transforming the CD into an actual Xen-based hard 
drive application?  If it works, the above is simply an iso file 
executed as would be a CD.
4.  LIVE CD modifications:

The Live CD comes with its predefined IP addressing.  I would like to 
alter this so that the Dom0 and DomU virtualizations can access other 
machines on my LAN.  I have read both the development and user manuals 
as well as list chatter and FAQ and there is a lot of material  on this 
subject but I'm still missing something.
Is it possible for someone to provide  command lines relative to the 
Live CD for the following steps specific to what I am trying to do as 
the (well written) documentation is just a bit too vague for my level of 
insight???
First, I need to revise the IP addresses, routing and IP configuration 
for some of the Dom0 while leaving the Xen-based internal network 
(virtualizations) stuff as it is. I need to both change and add stuff 
and am somewhat confused regarding the specifics. From the literature I 
know I must provide a MAC bridge to join the internal LIVE CD internal 
network to the LAN network. That's how I read it. But this is where I am 
most confused because the Xen-based system has it's own bridge 
(assumedly to virtualize network connectivity) and I would think that 
each DomU or virtualization including Dom0 would also need a bridge to 
talk to my LAN machines or I've got this wrong and the bridges just join 
networks. (Sorry, but I am missing a bit of network insight here). It 
would have been nice if the Live CD could be extended to refer to 
another network (LAN even if not existing) using 192.168.x.x static 
and/or dynamically assigned.  All my LAN stuff is hand crafted STATIC IP 
addressing and DHCP is not allowed under 192.168.1.100 on the 
192.168.1.0 LAN network. My gateways are 192.168.1.70 and 192.168.1.6. 
The LAN has both Windoozzzz and Linux (yea,yea,yea) machines.  

Second, I need to define the gateways for Dom0 as well as the DomU 
instances.
FOR EACH_DOM  DO
confused# route add default gw 192.168.1.70 dev eth0
confused# route add default gw 192.168.1.6 dev eth0
I'm not sure where Debian has this in a configuration file -- maybe 
/etc/route -- Debian is all new to me.
ENDDO

Third, I need to change the /etc/host and other network related files so 
that these domains recognize the LAN machines.  In this regard -- are 
SAMBA servers and clients as well as NFS servers and clients present on 
the Live CD Dom0 and DomU entities.  If not, and assuming I can "plant" 
the Live CD onto hard drive as covered above, can I extend these 
entities with additional packages???
Can these kind of changes (adding packages) be done during 
virtualization  or would virtualization have to stop until the physical 
update installation is complete?  I think the latter but I'm asking. In 
this respect is DOM 0 updated differently than a DOMU.  Based on my 
short experience with the LIVE CD Xen seems to be always running and the 
DOM 0 Guest (Debian in the case of the LIVE CD) can be started and 
stopped.  I had previously thought that DOM 0 Guest might be an 
exception -- always virtualized?
It took me a while to understand the following -- I hope it's right??? 
If it's wrong even in the slightest will someone please correct it.
From a high level perspective, "Virtualization by Xen" is the 
controlled execution of kernels associated with physical installations 
of i86 based OSs.  But it is more. Xen is integrated with the modified 
kernel of a Linux i86 based OS installation -- the base installation 
(and therefore the physical resources hard drive, NIC, etc. of that base 
installation) which combination is called DOM 0. Xen is responsible for 
the sharing of these physical resources (associated with DOM 0) by means 
of time sliced (relatively concurrent) execution control of other 
installed Operating Systems called DOMU for user level (because they do 
not have certain privileges and permissions and when  needed Xen manages 
that need).  Xen provides interfaces and processes to accomplish this 
controlled execution of DOMU types of domains or even other Xen-based 
DOM 0 domains where a domain is a primary or logical partition having a  
file sytem (formatted as ext2, ext3 or other) and a OS  (distribution) 
as physical content. There is for every virtualizeable domain 
possibility a uniqe physical OS installation. Virtualization as defined 
here makes it possible to efficiently run many Operating Systems 
(concurrently or more correctly speaking -- in parallel) on the same 
machine. When applications in a domain (eg, domain 3) execute in 
conjunction with their associated kernel (kernel for domain 3) the Xen 
package (interfaces domain 0 Guest hardware and modifed kernel) -- (with 
domain 3 kernel) -- in order to control both the time duration of that 
execution (of domain 3 kernel)  as well as the access (shared) of 
domain 0 Guest physical block device resources (indirectly by domain 3 
kernel). Xen lives in memory and operates from memory as do the kernels 
of an OS installation being virutalized.  So called priviledged kernel 
calls from DOMU are interfaced to DOM 0 and memory is used  to contain 
memory device blocks of various types and sizes to facilitate this 
virtualization or controlled interfacing and associated executing 
processes between the DOM 0 and DOMU domains. The exact implementation 
details are in the code which is under constant change, debugging and 
enhancement. For example, a debate is now underway on the list regarding 
how best to design console or terminal usage associated with DOMU.
Thanks in advance for any help and comments -- Ted



_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users