Re: [Xen-devel] Driver domains and hotplug scripts, redux

[Roger Pau Monnà <roger.pau@xxxxxxxxxxxxx>]

Hello,

I've been thinking about this email for some time, but there are parts
that are still not clear, so I'm sorry to bother you again with
this...

2012/1/27 Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>:
> On Fri, 27 Jan 2012, Roger Pau MonnÃÂ wrote:
>> Hello,
>>
>> I have a question regarding driver domains and root hard disks, if the
>> root hard disk (the one containing the kernel and ramdisk) is on a
>> driver domain, how can we pass the kernel to the Dom0? libvchan seems
>> like a good option to pass the kernel and ramdisk from driver domains
>> to Dom0, but I would like to hear opinions about that.
>>
>> If kernel and ramdisk passing is not implemented, the only way to boot
>> from hard disk stored on driver domains is to extract the kernel and
>> ramdisk and store them on the Dom0.
>
> Let me describe in more details this scenario for you:
> we are using a storage driver domain (the storage controller is assigned
> to a domain other than dom0), and dom0 is still responsible for creating
> all the other VMs, including the storage driver domain.

Ok, you launch the Dom0 normally and then you launch another domain(s)
that will be the driver domains, that's ok. Every one of this drivers
domains should be running xenbackendd to react to device
creation/destruction.

>
> How can dom0 create the storage driver domain if the kernel and initrd
> of the storage driver domain are on the hard disk?
>
> A simple solution would be having the storage driver domain kernel and
> initrd inside dom0 initrd or passed to dom0 through multiboot by the
> bootloader as an additional payload (better).
> Dom0 should be capable of freeing the memory used this way after
> creating the storage driver domain.

That's what I don't get. Booting the driver domain should be no
problem, because you can also have a xenbackendd running in the Dom0
to boot the driver domain (or maybe you want to use both Dom0 and
another DomU as driver domains).

What I don't get is what you do when you have to boot a PV DomU which
root HDD is on the driver domain. Dom0 needs the kernel/initrd from
the HDD (usually extracted using pygrub). Since the HDD is inside the
driver domain, Dom0 doesn't have access to that image, so there's no
way to extract the kernel/initrd from the Dom0. What I through is that
the driver domain has to run pygrub, extract the kernel/initrd, and
pass both files to the Dom0, but how can we pass those files? libvchan
seems like the best option, but I would like to head others opinions
about this.

Currently I have a mostly working xenbackendd implementation with
libxl, that can handle vbd and vif interfaces, but I'm missing qdisk,
I still have to look into the Qemu stuff to be able to launch a device
model that only attaches a HDD.

Thanks, Roger.

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