On Mon, 16 Apr 2018 14:56:06 +0800, Chen Ch Ji wrote:
>>>The "iso file" will not be inside the guest, but rather passed to
the guest as a block device, right?
Cloud init expects to find a config drive with following requirements
[1], in order to make cloud init able to consume config drive , we
should be able to prepare it,
in some hypervisor, you can define something like following to the VM
then VM startup is able to consume it
<source file="/var/log/cloud/new/abc.iso"/>
but for z/VM case it allows disk to be created during VM create (define
)stage but no disk format set, it's the operating system's
responsibility to define the purpose of the
disk, so what we do is
1) first when we build image ,we create a small AE like cloud-init but
only purpose is to get files from z/VM internal pipe and handle config
drive case
What does AE stand for? So, this means in order to use the z/VM driver,
users must have special images that will ensure the config drive will be
readable by cloud-init. They can't use standard cloud images.
2) During spawn we create config drive in nova-compute side then send
the file to z/VM through z/VM internal pipe (omit detail here)
3) During startup of the virtual machine, the small AE is able to mount
the file as loop device and then in turn cloud-init is able to handle it
because this is our special case, we don't want to upload to cloud-init
community because of uniqueness and as far as we can tell, no hook in
cloud-init mechanism allowed as well
to let us 'mount -o loop' ; also, from openstack point of view except
this small AE (which is documented well) no special thing and
inconsistent to other drivers
[1]https://github.com/number5/cloud-init/blob/master/cloudinit/sources/DataSourceConfigDrive.py#L225
Where is the AE documented? How do users obtain it? What tools are they
supposed to use to build images to use with the z/VM driver?
That aside, from what I can see, the z/VM driver behaves unlike any
other in-tree driver [0-5] in how it handles config drive. Drivers are
expected to create the config drive and present it to the guest in
iso9660 or vfat format without requirement of a custom image and the
existing drivers are doing that.
IMHO, if the z/VM driver can't be fixed to provide proper config drive
support, we won't be able to approve the implementation patches. I would
like to hear other opinions about it.
I propose that we remove the z/VM driver blueprint from the runway at
this time and place it back into the queue while work on the driver
continues. At a minimum, we need to see z/VM CI running with
[validation]run_validation = True in tempest.conf before we add the z/VM
driver blueprint back into a runway in the future.
Cheers,
-melanie
[0]
https://github.com/openstack/nova/blob/888cd51/nova/virt/hyperv/vmops.py#L661
[1]
https://github.com/openstack/nova/blob/888cd51/nova/virt/ironic/driver.py#L974
[2]
https://github.com/openstack/nova/blob/888cd51/nova/virt/libvirt/driver.py#L3595
[3]
https://github.com/openstack/nova/blob/888cd51/nova/virt/powervm/media.py#L120
[4]
https://github.com/openstack/nova/blob/888cd51/nova/virt/vmwareapi/vmops.py#L854
[5]
https://github.com/openstack/nova/blob/888cd51/nova/virt/xenapi/vm_utils.py#L1151
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
