Skip to contentSkip to conversation

KVM, iSCSI and High Availability

DISCUSSION Marcin M. Jessa 4 participants 7 messages Mar 25, 2011 – Mar 31, 2011 KVM

lore
Share & tools
lore
#0 lore raw

Hi.

Over the last several days I've been reading, asking questions, searching the Internet to find a viable HA stack for Ubuntu with KVM virtualization and shared iSCSI storage. And I'm nearly as confused as when I started.

Basically I'm trying to build a KVM enviroment with an iSCSI SAN and I'm not quite sure what approach to use for storing the virtual guests.
What I understand to get max speed I should install directly to iSCSI exported raw devices instead of backing disks.
I'm not sure creating many small LUNs, one for each of the guests is a good idea.
Would it be better to create just one big LUN and then use LVM to devide it and assign one "chunk" for each of the guests?
In the same setup I would also like to implement some kind of automatic failover so if one of the KVM hosts is down I could automatically move guests over to the other one. Or just perform live migration and move one of the guest over to a different host with spare capacity. What would be the best approach to implement a solution like that?

Thanks in advance.

Signature · 1 line
Marcin M. Jessa
#1 lore raw
Quoted 11 lines · Marcin M. Jessa

Hi.

Over the last several days I've been reading, asking questions, searching the Internet to find a viable HA stack for Ubuntu with KVM virtualization and shared iSCSI storage. And I'm nearly as confused as when I started.

Basically I'm trying to build a KVM enviroment with an iSCSI SAN and I'm not quite sure what approach to use for storing the virtual guests.
What I understand to get max speed I should install directly to iSCSI exported raw devices instead of backing disks.
I'm not sure creating many small LUNs, one for each of the guests is a good idea.
Would it be better to create just one big LUN and then use LVM to devide it and assign one "chunk" for each of the guests?
In the same setup I would also like to implement some kind of automatic failover so if one of the KVM hosts is down I could automatically move guests over to the other one. Or just perform live migration and move one of the guest over to a different host with spare capacity. What would be the best approach to implement a solution like that?

One LUN per image allows you to implement failover, LVM doesn't (but cluster-LVM does). I recommend using one LUN per image; it's much simpler.

Signature · 1 line
error compiling committee.c: too many arguments to function
#2 lore raw
Quoted 1 line · Avi Kivity

On 03/25/2011 10:26 PM, Marcin M. Jessa wrote:

[...]

Quoted 3 lines

One LUN per image allows you to implement failover, LVM doesn't (but cluster-LVM does). I recommend using one LUN per image; it's much simpler.

Some people say "Use one LUN, it's easier and use CLVM". Why is it easier to use CLVM and one LUN per virtual guest?

Signature · 1 line
Marcin M. Jessa
#3 lore raw

----- Original Message -----

Quoted 14 lines · Avi Kivity
Quoted 1 line · Marcin M. Jessa

[...]

Quoted 4 lines

One LUN per image allows you to implement failover, LVM doesn't (but cluster-LVM does). I recommend using one LUN per image; it's much simpler.

Some people say "Use one LUN, it's easier and use CLVM". Why is it easier to use CLVM and one LUN per virtual guest?

Quoted 7 lines

--

Marcin M. Jessa
--
To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

I find it easier because i can do:
lvcreate -n vm1 --size 40G iscsi_vg
then virt-install or whatever
If I were using 1 lun per vm then I would have to provision the lun, make ALL hosts aware of the lun, and finally screw with the multipath configs etc.

#4 lore raw

Am Monday 28 March 2011 schrieb David Martin:

Quoted 13 lines

----- Original Message -----

Quoted 10 lines · Avi Kivity
Quoted 1 line · Marcin M. Jessa

[...]

Quoted 3 lines

One LUN per image allows you to implement failover, LVM doesn't (but cluster-LVM does). I recommend using one LUN per image; it's much simpler.

Some people say "Use one LUN, it's easier and use CLVM". Why is it easier to use CLVM and one LUN per virtual guest?

Quoted 6 lines

I find it easier because i can do:
lvcreate -n vm1 --size 40G iscsi_vg
then virt-install or whatever
If I were using 1 lun per vm then I would have to provision the lun, make ALL hosts aware of the lun, and finally screw with the multipath configs etc.

Don't you have basically the same problem when using LVM in one LUN? You still have to make all the hosts aware of the new LV manually. I don't even know LVM even supports this, it wasn't exactly designed for a situation where multiple hosts might simultaneously read and write to a volume group, let alone create and destroy logical volumes while the VG is in use by any number of other hosts...

Guido

#5 lore raw

That's what CLVM is for, it propagates the volume changes to every member of the 'cluster'.

David Martin

----- Original Message -----

Quoted 38 lines

Am Monday 28 March 2011 schrieb David Martin:

Quoted 15 lines

----- Original Message -----

Quoted 12 lines · Avi Kivity
Quoted 1 line · Marcin M. Jessa

[...]

Quoted 5 lines

One LUN per image allows you to implement failover, LVM doesn't (but
cluster-LVM does). I recommend using one LUN per image; it's much
simpler.

Some people say "Use one LUN, it's easier and use CLVM". Why is it easier to use CLVM and one LUN per virtual guest?

Quoted 8 lines

I find it easier because i can do:
lvcreate -n vm1 --size 40G iscsi_vg
then virt-install or whatever
If I were using 1 lun per vm then I would have to provision the lun, make
ALL hosts aware of the lun, and finally screw with the multipath configs
etc.

Don't you have basically the same problem when using LVM in one LUN? You still
have to make all the hosts aware of the new LV manually. I don't even know LVM
even supports this, it wasn't exactly designed for a situation where multiple
hosts might simultaneously read and write to a volume group, let alone create
and destroy logical volumes while the VG is in use by any number of other
hosts...

Guido

#6 lore raw

Am Thursday 31 March 2011 schrieben Sie:

Quoted 2 lines

That's what CLVM is for, it propagates the volume changes to every member of the 'cluster'.

Oh, right. I didn't know about clvm until now.

It sounds very promising though, certainly better than working with the proprietary API of whoever your SAN-vendor is to create a new LUN for every VM. Also, the machine we have got here, a Dell PowerVault, appears to be limited to at most 255 LUNs. I don't if that's a limitation of iSCSI or just a problem of this particular array.

Guido