Mailing List Archive

Daniel Paquet wrote:
> If you wonder so much about the performance of the lvm then you can
> simply use "real" disk partitions.

I prefer not to, I need LVM for fs-snapshots, etc. This is not exactly
the kind of reply that would help me, anyway ;-)

I'm basically looking for some background information about the data
path between the disk (HW) and domU with LVM in dom0.
* Has the dom0 memory size effect on the performance (e.g.some caching)?
I.e. can I keep it as small as 64MB just for the basic functions of dom0
or should I increase it?
* What if I use real partitions - do the data go straight from domU to
the disk or will they traverse dom0 as well?
* And last question (the most promissing one) - can I tell xen (2.0.6)
to let domU see the _whole_ disks (e.g. hdb, hdc) and let domU handle
LVM itself?

Thanks!

Michal Ludvig
--
* Personal homepage: http://www.logix.cz/michal

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

> my Linux Xen domU machine have its filesystems on LVM volumes provided
> by dom0. I wonder what's the overhead of doing this. In my understanding
> all disk access must go through dom0 because only that knows about the
> LVM layout. Is that correct?

Yes. It's transparent to the guest how its data is being stored.

Block accesses will *always* have to go through dom0 unless you dedicate a
disk controller to the guest and give it a separate set of physical disks.

> Now I'm lookig for a way to optimize the IO performance for domU:
> - Should I allocate more memory in dom0 for it's disk buffers? Are they
> involved at all?

You shouldn't have any performance probs. LVM is an efficient backing storage
for guest block devices, as are partitions and whole disks. Using dom0 files
as guest disk storage is inefficient and should be avoided on high-throughput
systems.

> - Can I dedicate whole disks (hdb, hdc) to one domU and let it handle
> all disk access including LVM itself without involving dom0 at all?

You can give the guest a whole IDE controller and associated disks using the
PCI virtualisation stuff if you really want to - I doubt it's worth it
though. You shouldn't be seeing much (any?) noticeable disk overhead for
typical workloads.

HTH,
Mark

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

> * Has the dom0 memory size effect on the performance (e.g.some caching)?
> I.e. can I keep it as small as 64MB just for the basic functions of dom0
> or should I increase it?

The guest will do it's own caching, so this shouldn't matter. You don't want
to make dom0 too small but you'll probably get away with 64MB OK. 128MB
should certainly be OK if dom0 isn't running any high-load services.

> * What if I use real partitions - do the data go straight from domU to
> the disk or will they traverse dom0 as well?
> * And last question (the most promissing one) - can I tell xen (2.0.6)
> to let domU see the _whole_ disks (e.g. hdb, hdc) and let domU handle
> LVM itself?

You can't avoid going through dom0 unless you give control of an IDE
controller to a domU. I'd say it's pretty unlikely to be worthwhile, though
- you shouldn't have major performance issues with virtualising through dom0.

Cheers,
Mark

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

Mark Williamson wrote:

>>- Can I dedicate whole disks (hdb, hdc) to one domU and let it handle
>>all disk access including LVM itself without involving dom0 at all?
>
> You can give the guest a whole IDE controller and associated disks using the
> PCI virtualisation stuff if you really want to - I doubt it's worth it
> though. You shouldn't be seeing much (any?) noticeable disk overhead for
> typical workloads.

OK, thanks for explanation!

Michal Ludvig
--
* Personal homepage: http://www.logix.cz/michal



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