The more I think about it, the more I dislike how the proposed driver also
"lies" about it using iso9660. That's definitely wrong:

        if CONF.config_drive_format in ['iso9660']:
            # cloud-init only support iso9660 and vfat, but in z/VM
            # implementation, can't link a disk to VM as iso9660 before it's
            # boot ,so create a tgz file then send to the VM deployed, and
            # during startup process, the tgz file will be extracted and
            # mounted as iso9660 format then cloud-init is able to consume
            raise exception.ConfigDriveUnknownFormat(


On Thu, Apr 12, 2018 at 9:28 AM, Dan Smith <> wrote:

> > is a z/VM patch which
> > introduces their support for config drive. They do this by attaching a
> > tarball to the instance, having pretended in the nova code that it is
> > an iso9660. This worries me.
> >
> > In the past we've been concerned about adding new filesystem formats
> > for config drives, and the long term support implications of that --
> > the filesystem formats for config drive that we use today were
> > carefully selected as being universally supported by our guest
> > operating systems.
> >
> > The previous example we've had of these issues is the parallels
> > driver, which had similar "my hypervisor doesn't support these
> > filesystem format" concerns. We worked around those concerns IIRC, and
> > certainly virt.configdrive still only supports iso9660 and vfat.
> Yeah, IIRC, the difference with the parallels driver was that it ends up
> mounted in the container automagically for the guest by
> behind the curtain. However, z/VM being much more VM-y I imagine that
> the guest is just expected to grab that blob and do something with it to
> extract it on local disk at runtime or something. That concerns me too.
> In the past I've likened adding filesystem (or format, in this case)
> options to configdrive as a guest ABI change. I think the stability of
> what we present to guests is second only to our external API in terms of
> importance. I know z/VM is "weird" or "different", but I wouldn't want a
> more conventional hypervisor exposing the configdrive as a tarball, so I
> don't really think it's a precedent we should set. Both vfat and iso9660
> are easily supportable by most everything on the planet so I don't think
> it's an unreasonable bar.
> --Dan
OpenStack Development Mailing List (not for usage questions)

Reply via email to