[meta-virtualization] [PATCH 2/2] Created new target:kvm-image-minimal

Bruce Ashfield bruce.ashfield at gmail.com
Fri Jan 11 13:19:09 PST 2013


On Wed, Jan 9, 2013 at 2:57 PM, Prica, Mihai <mihai.prica at intel.com> wrote:

> -----Original Message-----
> From: McClintock Matthew-B29882 [mailto:B29882 at freescale.com]
> Sent: Monday, January 07, 2013 10:27 PM
> To: Bruce Ashfield
> Cc: Prica, Mihai; meta-virtualization at yoctoproject.org
> Subject: Re: [meta-virtualization] [PATCH 2/2] Created new
> target:kvm-image-minimal
>
> On Mon, Jan 7, 2013 at 7:47 AM, Bruce Ashfield <bruce.ashfield at gmail.com>
> wrote:
> >
> >
> >
> > On Mon, Jan 7, 2013 at 7:08 AM, Mihai Prica <mihai.prica at intel.com>
> wrote:
> >>
> >> Signed-off-by: Mihai Prica <mihai.prica at intel.com>
> >> ---
> >>  recipes-extended/images/kvm-image-minimal.bb |   22
> >> ++++++++++++++++++++++
> >>  1 file changed, 22 insertions(+)
> >>  create mode 100644 recipes-extended/images/kvm-image-minimal.bb
> >>
> >> diff --git a/recipes-extended/images/kvm-image-minimal.bb
> >> b/recipes-extended/images/kvm-image-minimal.bb
> >> new file mode 100644
> >> index 0000000..486cd9c
> >> --- /dev/null
> >> +++ b/recipes-extended/images/kvm-image-minimal.bb
> >> @@ -0,0 +1,22 @@
> >> +DESCRIPTION = "A minimal kvm image"
> >> +
> >> +IMAGE_INSTALL = " \
> >> +    packagegroup-core-boot \
> >
> >
> > Have you thought about an image variant that isn't actually bootable ?
> > There are quite a few use cases where having the build not depend on a
> > kernel, but instead simply creates a userspace that can be booted via
> > feeding an external kernel directly to qemu on the command line.
> >
> > Not having the kernel decadency turns out to be quite useful when you
> > want to build a KVM host and KVM guest kernel with different
> > configurations, in a single build.
>
> I don't exactly understand what you mean by " an image variant that isn't
> actually bootable ?". I just used core-image-minimal as a starting point.
> Using this recipe you just get the ext3 and the kernel, you don't get an
> hddimg..
>
>
What I mean is that a "bootable" image typically depends on virtual/kernel
to configure
and build a kernel, and then possibly assemble parts of the kernel output
into the image
itself.

We often want to build a rootfs, but have no kernel build as part of that
rootfs, since the
kernel is built separately and then passed to qemu-kvm during the launch
phase. Not
having that dependency means that you can just build userspace, assemble a
rootfs and
then launch the guest.

If you have a dependency on virtual/kernel it turns out that you can end up
with a circular
dependency if you use a method like Matthew showed, the nested rootfs
depend has
it's own kernel dependency, and you have an image that depends on a kernel,
that depends
on an image that depends on a kernel .. etc, and you continue looping.

Having an image that doesn't depend on virtual/kernel at any point, breaks
that loop.

Cheers,

Bruce


> > I've shared this with Bruce before so I thought I would share on this
> list also. It's hacky and possibly not the way to go but we have been doing
> this in a kvm image. Not the depends, and the post process addition.
> >
> > fsl-image-kvm.bb:
> >
> > #
> > # Copyright (C) 2007 OpenedHand Ltd.
> > #
> > IMAGE_INSTALL = "packagegroup-core-boot ${ROOTFS_PKGMANAGE_BOOTSTRAP}
> u-boot"
> > IMAGE_LINGUAS = " "
> >
> > PR = "r1"
> >
> > LICENSE = "MIT"
> >
> > inherit core-image
> >
> > IMAGE_ROOTFS_SIZE = "8192"
> >
> > # remove not needed ipkg informations
> > ROOTFS_POSTPROCESS_COMMAND += "remove_packaging_data_files ; mkdir
> ${IMAGE_ROOTFS}/images; cp
> ${DEPLOY_DIR_IMAGE}/fsl-image-minimal-${MACHINE}.ext2.gz.u-boot
> > ${IMAGE_ROOTFS}/images"
> >
> > IMAGE_FSTYPES = "tar.gz ext2.gz.u-boot"
> >
> > # pkgconfig is here for qemu, and it's not in DEPENDS because of
> multilib # build issues. to fix later IMAGE_INSTALL += "pkgconfig qemu
> kernel-image"
> >
> > do_rootfs[depends] += "fsl-image-minimal:do_rootfs"
>
> Thanks for the recipe. I'll see what I can use from it.
>
>
> Mihai
> >
> >
> > Cheers,
> >
> > Bruce
> >
> >>
> >> +    ${ROOTFS_PKGMANAGE_BOOTSTRAP} \
> >> +    qemu \
> >> +    libvirt \
> >> +    libvirt-libvirtd \
> >> +    libvirt-virsh \
> >> +    "
> >> +
> >> +IMAGE_FEATURES += "ssh-server-openssh"
> >> +
> >> +IMAGE_LINGUAS = " "
> >> +
> >> +LICENSE = "MIT"
> >> +
> >> +inherit core-image
> >> +
> >> +IMAGE_ROOTFS_SIZE = "8192"
> >> +
> >> +ROOTFS_POSTPROCESS_COMMAND += "remove_packaging_data_files ; "
> >> --
> >> 1.7.9.5
> >>
> >> _______________________________________________
> >> meta-virtualization mailing list
> >> meta-virtualization at yoctoproject.org
> >> https://lists.yoctoproject.org/listinfo/meta-virtualization
> >
> >
> >
> >
> > --
> > "Thou shalt not follow the NULL pointer, for chaos and madness await
> > thee at its end"
> >
> > _______________________________________________
> > meta-virtualization mailing list
> > meta-virtualization at yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/meta-virtualization
> >
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-virtualization/attachments/20130111/cc980e01/attachment.html>


More information about the meta-virtualization mailing list