On Wed, Sep 03, 2008 at 09:22:50AM -0400, Konrad Rzeszutek wrote: > On Wed, Sep 03, 2008 at 01:53:44PM +0100, Daniel P. Berrange wrote: > > 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, > > 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. > > Sure. Isn't the code providing a GUID for the iSCSI pool so that before > a migrate, the nodes can compare their GUIDs to find a match? > > And if not, complain so that the admin would create a pool. Which is exactly the point I made in my first mail. If you're checking for migration compatability between 2 hosts, and then for some guest configurations (of which iSCSI is just one example), you've got an external setup dependancy there which the application doing migration has to deal with quite early on. 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 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list