On Wed, Jun 15, 2016 at 04:59:39PM -0700, Preston L. Bannister wrote: > QEMU has the ability to directly connect to iSCSI volumes. Running the > iSCSI connections through the nova-compute host *seems* somewhat > inefficient. > > There is a spec/blueprint and implementation that landed in Kilo: > > https://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/qemu-built-in-iscsi-initiator.html > https://blueprints.launchpad.net/nova/+spec/qemu-built-in-iscsi-initiator > > From looking at the OpenStack Nova sources ... I am not entirely clear on > when this behavior is invoked (just for Ceph?), and how it might change in > future. > > Looking for a general sense where this is headed. (If anyone knows...) > > If there is some problem with QEMU and directly attached iSCSI volumes, > that would explain why this is not the default. Or is this simple inertia? > > > I have a concrete concern. I work for a company (EMC) that offers backup > products, and we now have backup for instances in OpenStack. To make this > efficient, we need to collect changed-block information from instances. > > 1) We could put an intercept in the Linux kernel of the nova-compute host > to track writes at the block layer. This has the merit of working for > containers, and potentially bare-metal instance deployments. But is not > guaranteed for instances, if the iSCSI volumes are directly attached to > QEMU. > > 2) We could use the QEMU support for incremental backup (first bit landed > in QEMU 2.4). This has the merit of working with any storage, by only for > virtual machines under QEMU. > > As our customers are (so far) only asking about virtual machine backup. I > long ago settled on (2) as most promising. > > What I cannot clearly determine is where (1) will fail. Will all iSCSI > volumes connected to QEMU instances eventually become directly connected?
Our long term goal is that 100% of all network storage will be connected to directly by QEMU. We already have the ability to partially do this with iSCSI, but it is lacking support for multipath. As & when that gap is addressed though, we'll stop using the host OS for any iSCSI stuff. So if you're requiring access to host iSCSI volumes, it'll work in the short-medium term, but in the medium-long term we're not going to use that so plan accordingly. > Xiao's unanswered query (below) presents another question. Is this a > site-choice? Could I require my customers to configure their OpenStack > clouds to always route iSCSI connections through the nova-compute host? (I > am not a fan of this approach, but I have to ask.) In the short term that'll work, but long term we're not intending to support that once QEMU gains multi-path. There's no timeframe on when that will happen though. 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 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
