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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2012-01-31 at 13:47 +0000, Stefano Stabellini wrote:
> On Tue, 31 Jan 2012, Tim Deegan wrote:
> > Hi, 
> > 
> > At 10:57 +0100 on 31 Jan (1328007457), Roger Pau Monn? wrote:
> > > 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.
> > 
> > You could attach to the disk image (using blkfront in dom0 and
> > blkback/tap/whatever in the driver domain), run pygrub and detach.
> > That's basically the same thing you have to do with a qcow image in a
> > traditional dom0.
> 
> this
> 
> 
> > Or you could use pvgrub to boot the domain, so dom0 code never has to
> > touch the guets-supplied disk image or kernel.  That seems much better
> > to me, but maybe it wouldn't work for some existing deployments?
> 
> It wouldn't work with guests that use grub2, I believe.

One of the grub2 developers posted about working on pv grub2 back in
November...

Ian.



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