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
|