WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] paravirtualized guest OS

To: Xen Developers <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] paravirtualized guest OS
From: rahul gundecha <rahoolgundecha@xxxxxxxxxxx>
Date: Tue, 13 Feb 2007 13:25:36 +0000 (GMT)
Cc: Daniel Stodden <stodden@xxxxxxxxxx>
Delivery-date: Tue, 13 Feb 2007 10:22:08 -0800
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=gpTmREN+C1YeYICgYT6hK5A4Uew4iFPyJjKRZ6l4x0nXwqVZaEKU21YK9P7UA5yfmBWA+5czKp+a/dN0HR+bozi6+RpbAt6VyABHIm/cOZE/ZvarSWbnOgVHEwDzfbq6nZWbT2OUwgtu1QocvI4XQBNH/H/MEb/DvITyPTRMW2o=;
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1171350486.17394.25.camel@xxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Tue, 2007-02-13 at 05:41 +0000, rahul gundecha wrote:
> hi,
>
> 1) When we install guest linux inside Xen using paravirtualization,
> how actually guest linux code is modified. Whats the actual process.

not sure whether i understand your question correctly, but it might be
me.

the passably witty answer would probably be 'manually'.

paravirtualization is based on the assumption that system virtualization
is well worth the effort of _modifying_ systems to suit a virtual
environment better. this leads to improved efficiency, and is thereby in
contrast to the more traditional (and technically challenging) method of
making unmodified operating systems think they actually _own_ the
hardware they operate on. which they don't. xen does now.

-- thanks alot for elobarating in simple language. but I was actually interested in
knowing actual process followed in SUSE 10.2 when we install a guest OS.
Because when we install a guest OS, we are just giving normal OS source/CD,
same as what we do in normal OS installation. So who does this
paravirtualization of guest OS?


--Also the reason why I am saying SUSE 10.2 is that it gives boot option of XEN.
Why there is need of another kernel ? Can't we accomodate VMM inside native
kernel. Uptil now whatever I read, there was nothing mentioned about the host OS
(domain 0 ), whether it should be paravirtualized or not.
Its mentioned everywhere that we install VMM inside domain-0.
Nothing more about domain-0.

the linux kernel is a very portable thing, and used to run on different
platforms since its earliest revisions. so there's x86, powerpc, mips
and so on. xen-linux is basically a port to yet another platform, with
the major difference being that this platform does not an interface
defined by hardware, but in software.

d'you know what a system call is? user programs you run on linux use
them to acquire resources (e.g. storage or IPC). xen is very similar in
that respect. a (comparatively small) set of well-defined functions
needed to supplement a whole bunch of operating systems on top of it.


> 2) I am using suse 10.2. After installing xen package which comes with
> it, the new boot menu "SUSE (XEN)" gets added up. What are the
> difference between the kernel which runs this SUSE-XEN & original
> kernel.

in the case of the kernel mentioned by your grub.conf, comparatively
small.

as you might have noticed you get to boot xen, and xen boots on into a
special VM commonly called 'dom0'. dom0 hosts a paravirtual kernel as
described above, but additionally armed with the typical set of device
drivers necessary to put your peripheral hardware work, and privileged
enough by xen to apply them.

additional guest systems booted are even different. they don't require
hardware device drivers, since the first one already does that. instead,
they communicate with dom0 for peripheral I/O.

xen maintains cpu(s) and memory. linux in dom0 almost anything else, so
xen does not have to (because writing device drivers is such an
expensive business).

I guess now my question is clear.
Anyways thanks for this prompt and elaborative reply,
it helped me clear out all the doubts I had other than above mentioned questions
Waiting for some more light on my questions.

Regards,
-Rahul


Here?s a new way to find what you're looking for - Yahoo! Answers
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>