RE: [Xen-users] a new server for Xen

["Petersson, Mats" <Mats.Petersson@xxxxxxx>]

> -----Original Message-----
> From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of xin
> Sent: 28 February 2007 07:02
> To: xen-users@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-users] a new server for Xen
> 
> 
> Thanks for that. What about a VT-supported cpu to do the 
> para-virtualization
> instead of full-virtualization? which one is better.

In the present form of hardware supported (full) virtualization, there's
one important feature of this technology that makes it "win" over
Para-virtualization: You can virtualize OS's that there's no publicly
available para-virtual support for, for example those OS's that don't
have source-code easily available, or where no one has spent the several
months of effort to make the para-virtualization work. 

Para-virtualization will almost always win over full-virtualization
where both are possible: The PV-model can package up requests so that
the hypervisor is called only once per block-request. For example, if a
process allocates 1MB of memory, that requires 256 writes to the
page-table. The PV-guest can send a list of 256 page-table entries to
the hypervisor and say "map these into my page-table X". In the
full-virtualization case, each one of those 256 page-table writes will
appear as individual writes, each one having to be intercepted,
"understood" and acted on by the hypevisor (in a 32-bit PAE-system, you
may even get 512 write operations to intercept, as each page-table entry
is 64 bits, but the processor is most likely using regular 32-bit store
operations). So the overhead for para-virtual operations is less than
full virtualization. 

Whether this is NOTICABLY less or just a few percent depends very much
on the type of application and how much of the operations in the guest
that needs intercepting. For example a big calculation effort may not
require more than a few intercepts per second, whilst something
creating/destroying (e.g. kernel compile in Linux) processes a lot will
be heavy on intercepts. Somewhere around the halfway mark, you get
Web-serving where the network access is quite intense (which requires
intercepting) and that uses memory quite dynamically. 

> 
> ps: just wondering, if I copy one guest system image file from one xen
> server to another xen server, does that work? VMware does, I 
> don't know xen
> could or not, cause it seems the drivers may be missing.

That should work fine. Drivers for the guest-domain should all be the
same anyways, all the drivers that you need for one setup should work on
the other system, as the "hardware" that the guest sees is all "virtual
hardware" that looks the same whatever the "real hardware" is (for
example, the guest will not know if you use IDE, SATA or SCSI
hard-disks, nor if you use 10Mbps, 100Mbps or 1Gbps network cards). This
applies both to para-virtualization and full-virtualization guest models
- although the virtual devices are somewhat different between the
models. 

Obviously, if you use the model of letting a guest-domain access REAL
hardware (which is possible, but not the common usage model), then
you'll have problems if your "old" machine and "new" machine have
different types of hardware, or even if the PCI device ID's are
different. But that's always the case if you move between REAL hardware
models - and that's exactly why virtual machines have a virtual device
layer: the virtual devices are the same whatever the REAL hardware, so
you don't have to worry about device drivers. 

Further to the "real hardware access from the guest-domain": You can
always add the drivers for the new hardware before you move the
image-file.

--
Mats
> 
> many thanks. sorry about my english
> xin 
> 
> 
> Jan Albrecht wrote:
> > 
> > Hi,
> > Xin Chen wrote:
> >> Hi all,
> >>
> >> Our company is going to buy a new server for Xen. We are gonna run
> >> Fedora 6 as the domain0, and put about 4-5 guests on it(it 
> may include
> >> window). Can anyone give me some advice about the hardware 
> for the new
> >> server, such as memory, vieo card, cpu, motherboard, and 
> harddisk(scsi
> >> raid???).
> >>From my point of view there are only two main parts for your server:
> > Memory and cpu. Use CPUs with Full virtualization and as 
> much as memory
> > as you can get. Memory will always your limiting factor.
> > Beside this maybe fast disks will be an enhancment to your 
> server, but
> > they matter the same than on a normal server.
> > 
> > Jan
> > 
> > _______________________________________________
> > Xen-users mailing list
> > Xen-users@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-users
> > 
> > 
> 
> -- 
> View this message in context: 
> http://www.nabble.com/a-new-server-for-Xen-tf3306769.html#a9198889
> Sent from the Xen - User mailing list archive at Nabble.com.
> 
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users
> 
> 
> 



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