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

[Xen-users] Basic questions - numbered

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 on the LAN network. My gateways are and 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.
confused# route add default gw dev eth0
confused# route add default gw dev eth0
I'm not sure where Debian has this in a configuration file -- maybe /etc/route -- Debian is all new to me.

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



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