Re: [libvirt] Live migration sanity checks
On Wed, Sep 03, 2008 at 08:43:44AM -0400, Konrad Rzeszutek wrote:
> amount of host 'setup'. If a guest is using iSCSI as its
storage, then
> there is a step where the host has to login to the iSCSI target and create
> device nodes for the LUNs before the guest can be run. You don't want
> every single host to be logged into all your iSCSI targets all the time.
I am interested to know why you think this is a no-no. If you have a
set of hosts and you want to be able to migrate between all of them and your
shared storage is iSCSI why would it make a difference whether you had logged in
or logged in on the migrate on each host?
In the general case it is a needless scalability bottleneck. If you have 50
iSCSI targets exported on your iSCSI server, and 1000 hosts in the network,
you'll end up with 50,000 connections to your iSCSI server. If any given host
only needs 1 particular target at any time, the optimal usage would need
only 1000 connections to your iSCSI server.
Now in the non-general oVirt case, they have a concept of 'hardware pools'
and only migrate VMs within the scope of a pool. So they may well be fine
with having every machine in a pool connected to the requisite iSCSI
targets permanently, because each pool may only ever need 1 particular
target, rather than all 50.
So in the context of oVirt the question of iSCSI connectivity may be a
non-issue. In the context of libvirt, we cannot assume this because its
a policy decision of the admin / application using libvirt.
What about if the shared storage was Fibre Channel and it was zoned
so that
_all_ nodes saw the disk. Should you disconnect the block device when not in
usage?
The same principle applies - libvirt cannot make the assumption that all
nodes have all storage available. Higher level apps may be able to make
that assumption.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|