[Xen-users] linux stubdom

[Markus Hochholdinger <Markus@xxxxxxxxxxxxxxxxx>]

Hello list,

I'm reading a lot about xen stub-domains, but I'm wondering if I can use a 
linux stubdom to serve a "transformed" block device for the according domU. 
The wiki page(s) and the stubdom-directory in the source code leaves a lot of 
questions to me I'm hoping someone can answer me here.

So my question are:
* What are the requirements to run linux inside a stubdom? Is a current pvops
  kernel enough or has the linux kernel to be modified for a stubdom? If yes,
  I would prepare a kernel and a minimal rootfs within an initrd to setup my
  blockdevice for the domU.
* How can I offer a block device (created within the stubdom) from the stubdom
  to the domU? Are there any docs how to configure this?
* If the above is not possible, how could I offer a blockdevice from one domU
  to another domU as block device? Are there any docs how to do this?

What I'm trying to do:
* In my case, I make logical volumes available on all hosts with the same path
  on each host. So I can assemble a software raid1 where each device lives on
  a different server while not loosing the possibility of live migration.
* Configure a domU with two block devices, the according (linux) stubdomu
  assembles a software raid1 (linux md device) and presents this md device
  to the domU. So the domU hasn't to handle anything with the software raid1
  but has ONE redundant block device for its usage.
* I have two use cases, one is a HVM domU, where something like windows is
  running and because the lack of (good) software raid1 I use the software
  raid1 of linux for baking the block device inside the stubdom.
  The other use case is a PV domU where the admin of the virtualization
  environment is not the admin of the domU and therefore isn't able to manage
  the software raid1 inside the domU. So the stubdom could be used to manage
  the software raid1 without interfering within the domU.


-- 
greetings

eMHa

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users