On Mon, Jul 14, 2014 at 10:48:17AM +0100, Matthew Booth wrote: > > That's interesting. I didn't realise that other drivers had the same > limitations. Does anybody understand the original thinking which lead to > this design? The single VM approach seems intuitively correct to me, so > presumably at some point there was a good reason not to choose it.
I imagine it was just done for ease of implementation initially, and/or the rescue mode hasn't been updated as new features were added, so it fell behind. > I'm not sufficiently familiar with the libvirt driver to know what state > persists in the hypervisor, but in the vmware driver an attached volume > remains attached until detached. By re-using the original VM for rescue, > we wouldn't have to concern ourselves with volumes at all, because they > are all already attached. > > As for following the linked BP, I *think* we would achieve that 'for > free' with a single VM approach. Is there any semantic subtlety here > relating to actually attaching the volumes? i.e. Does it matter that we > wouldn't attach them, because they are already attached? > > I like the USB idea, and I'm fairly sure it should be achievable in the > VMware driver. Is it worth codifying it in a BP? Perhaps the same BP. It is in a gray area, you could probably argue both ways as to whether it could be slipped in as part of the existing BP :-) It has user visible change though, so might need a bit of bikeshedding in a BP to agree on best way to deal with the idea. eg perhaps opt-in to use of USB vs existing disk approach via an image property. > Incidentally, I hit an obvious problem when testing this with the Cirros > image, which mounts filesystems by label. If you have an image which > mounts by label, or has LVM volumes, and you use the same image as a > rescue disk, you are adding a second disk containing the same filesystem > labels and/or LVM volumes. Under these circumstances, the behaviour of > mount during the boot sequence is not well defined afaik. Consequently, > re-using the original image as a rescue image doesn't sound to me like a > good idea in general. I think that I'd probably say there is an expectation that the rescue image will be different from the primary image the OS was booted from. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
