On 6 August 2013 23:06, Ian McLeod <imcl...@redhat.com> wrote: > The proof of concept approach is limited to full-virt hypervisors. It's > unclear to me if there's a way we can make this work for Xen-backed > installs without the kind of lower level access to the virt environment > that we'll get if we exist inside of Nova.
Xen does full virt, its how Windows runs. Xen works best with PV, and other tools, but its not required. Maybe I am missing something? > More generally, it's likely that we'll have more flexibility to behave > in a sane/optimized manner based on backing hypervisor if the code is > inside of Nova. For example, we've talked about improving our detection > of a failed install by monitoring disk IO. That could be a nice improvement, but its probably not a requirement. > On Tue, 2013-08-06 at 16:02 -0300, Monty Taylor wrote: >> On 08/06/2013 03:46 PM, Russell Bryant wrote: >> That said - if we did service-ify the tool, wouldn't glance be a more >> appropriate place for that sort of thing? > Possibly, though the proof of concept (and we hope our proposed > nova-based re-implementation) can build both glance images and cinder > volume backed images. If you want something to create you given parameters, and it produces you an image, it doesn't need to be part of Nova, and that makes total sense. However, this proposal is different: https://blueprints.launchpad.net/nova/+spec/xenapi-ipxe-iso-boot-support The idea here is quite simple, boot up into a PXE installer, via an ISO boot. The user access the server via VNC, and can interact with the installer as they required. If you use DHCP, you probably don't need anything in nova. However, in environments without DHCP (i.e. Rackspace Cloud Servers), you need to inject networking. Without the injection, the user would have to see what IP address nova has been given for the VM and enter that manually. So to avoid this, there is an XenAPI plugin that has been added that can inject that netwokring information into the ISO that is originally stored in glance, so the user is then free to continue with the install of the OS of their choice. Its not really possible to pass that info via kernel args or similar, so injecting into the ISO image seems the only way forward. In addition to the networking, the proposed blueprint also injects some other settings, which could be baked into the glance image, but happens to be injected the same way as networking, because its useful and means the glance image can be more general, and shared between different clouds and different cloud regions more easily. John _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
