> I finally have access to a VT enabled box. What would be the best way
> to get the most out of Xen and VT? A number of questions here. Bear
> with me. They may seem simple but all I did previously was get the
> source code, study it a bit, read the README and build from source.
OK!
> Now that I have a dual-core machine how does Xen know how to split
> resources for the instances?
Virtual machines schedule their processes on VCPUs - virtual CPUs. This is
the abstraction Xen presents to them, for both HVM and PV guests.
If you think of a domain as like a "process", a VCPU is like a "thread". Xen
can schedule VCPUs concurrently across the logical processors (cores /
hyperthreads) in the system.
> Does one give any parameters to the dom0 to boot with to tell it to
> "use processor0"?
By default, dom0 will run on the first logical processor in the system. If
you have enough, it can be worth dedicating a logical processor to dom0 to
improve IO performance. But whether exclusively dedicating a logical
processor to dom0 is worth it does rather depend on your workload so you
might want to experiment.
Unless you're running a workload on it for some reason, I understand that dom0
doesn't generally need to have more than one VCPU.
> Any parameters for the domUs required?
You can set how many VCPUs they get (i.e. how many logical processors they can
concurrently run on at once - how much parallelism they're allowed), which
logical CPUs they can run on (could be useful to dedicate certain CPUs to
certain domains, or groups of domains) and how much CPU bandwidth they're
allowed in total across all VCPUs (in percent. 100% would be equivalent to
being running on one logical CPU for an entire time slice but if you have
multiple CPUs then it might be a 50:50 split between them, or some other
distribution. Similarly for other numbers of VCPUs).
> I've never bothered with X windows for the domUs before. If I wanted
> to would it be better to use vnc or SDL?
VNC is handy for remotely accessing the domains, although you'll want to
ensure that it's appropriately secured. You'll need some way, at least for
install, of accessing the graphics of an HVM domU.
> How about qemu, would that be good for a VT-enabled machine?
Vanilla Qemu can't take advantage of VT.
> Or why not just go the "simple" way and use kvm+qemu?
I should probably point out at this point that I do work for XenSource, so I
might be a bit biased ;-) I'm not so familiar with KVM, so I'm going largely
on what I've read about it.
KVM would leverage VT. It has some advantages in terms of simplicity: just
insmod kvm and go, virtual machines appear as conventional Linux processes,
etc. There certainly seems to be community enthusiasm for KVM so you could
count on it being developed more in the future.
KVM is possibly a bit less good in terms of performance (but I don't have
recent numbers so can't say for sure). If you want to use PV device drivers
in your HVM guest to improve IO performance then currently I think KVM
doesn't support that, whereas Xen does.
Currently, the fully paravirtualised high performance guests are also only
available under Xen. Work is underway to add some kind of paravirt interface
to KVM. Many distros provide a Xen kernel, plus Xen guest support is going
to be in the next mainline Linux release. Some non-Linux operating systems
are also available, or under development that use the Xen paravirt interface
directly.
Xen has had more distro support up until this point, but the distros seem to
be getting on with supporting KVM as well, so both will probably be well
supported in the future. Xen possibly has more comprehensive management
tools at the moment.
It shouldn't be too hard to import KVM virtual machines to Xen, and vice
versa, so at the end of the day you can probably try out both and switch to
the one you like mest.
Hope that helps you somewhat!
Cheers,
Mark
--
Dave: Just a question. What use is a unicyle with no seat? And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home