>I'd rather say that XCP needs "shared" storage rather than "remote" storage.
I agree, it just has to be shared and that makes sense with what I've read.
However, since we're just starting out and 'remote shared' seems to be more
common and well supported, it seems simplest for us to go that route.
>I have tried this setup for XCP with DRBD primary-primary SR, and it works
>fine with live migration. From the point of view of xapi, the SR is kind of
>local (/dev/drbd0), but it still can be shared. This setup is not yet in
>production (not stress-tested yet), but up to now it works flawlessly.
This is really good to know about though, in case a design might require it
some form. Long term, it seems like breaking the dependency on outside storage
would be a good thing for virtualization, to further consolidate hardware.
>Agreed. There are a lot of things that need to be done from the xe cli. Remote
>itself isn't quite so important although I'd stress that one needs to think
>about layout first of course.
And once again, I totally agree with this point. No matter how or where storage
is presented, it doesn't change the rules about how many disks and in what RAID
level can support the level of I/O that your applications will generate.
What are some good options for configuring a redundant SAN using open standards
and commodity hardware? If we're going to convert from proprietary
virtualization software on expensive hardware, to open source virtualization on
commodity hardware (and I think we are), it would make sense to do the same for
the storage level. It doesn't eliminate our redundancy requirements though.
Brett Westover
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home