<div dir="ltr">Assuming your farm is a production one, suspend to disk is rather rare, and by design, would probably not be a day-to-day process of the system. Anyhow - suspend to disk is an operation which is being performed on NFS SR as well, just the same (create file which contains memory dump of the VM).<div>
<br></div><div>NFS has other advantages, like LUN alignment and thin provisioning (assuming you did not purchase the "foundation for Citrix XenServer" package). Also - for real-life production systems I have seen that network communication over iSCSI, for about 50 VMs on 5 physical servers would not exceed the 200Mb/s at peak times. </div>
<div><br></div><div>Of course - specific applications can (and will) stress the storage and network, however, many common storage devices cannot maintain a high rate of random IO (common to DBs, like Oracle, MySQL, Exchange, MSSQL, etc). The disks would commonly be the bottleneck, and not the network/FCS transport.</div>
<div><br></div><div>Don't believe me? Check your virtual farm. See what throughput you get for your DRBD/central storage links. </div><div><br></div><div>Ez<br><br><div class="gmail_quote">On Mon, Mar 15, 2010 at 10:58 PM, Amos Shapira <span dir="ltr"><<a href="mailto:amos.shapira@gmail.com">amos.shapira@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">2010/3/16 Etzion Bar-Noy <<a href="mailto:ezaton@tournament.org.il">ezaton@tournament.org.il</a>>:<br>
<div><div></div><div class="h5">><br>
><br>
> On Mon, Mar 15, 2010 at 10:41 AM, Amos Shapira <<a href="mailto:amos.shapira@gmail.com">amos.shapira@gmail.com</a>><br>
> wrote:<br>
>><br>
>> 2010/3/12 Hetz Ben Hamo <<a href="mailto:hetzbh@gmail.com">hetzbh@gmail.com</a>>:<br>
>> > Hi,<br>
>> > I have taken 3 machines for a project: 2 machines will act as Xen<br>
>> > servers<br>
>> > and one machine will act as "storage".<br>
>> > The storage box is just a machine with few hard disks connected with a<br>
>> > RAID<br>
>> > controller.<br>
>> > What I would like to do is create few Xen VM's with the fastest possible<br>
>> > I/O<br>
>> > in terms of storage.<br>
>> > I have few options:<br>
>> > 1. I can create an LVM on the storage machine, create few Logical<br>
>> > Volumes<br>
>> > and export them as NFS to the Xen servers and configure each VM to some<br>
>> > file<br>
>> > images. Problem is, that file I/O with Xen is slower compared working<br>
>> > with<br>
>> > LVM's.<br>
>> > 2. I can create an LVM on the storage machine, create few Logical<br>
>> > Volumes,<br>
>> > and export those as iSCSI devices. I'm not sure whats the performance of<br>
>> > Xen<br>
>> > with iSCSI devices exported from the storage box.<br>
>> > 3. I can create few partitions on the storage machine, export them as<br>
>> > iSCSI<br>
>> > devices and do LVM on the Xen servers. Problem: I don't know how much<br>
>> > the<br>
>> > "penalty" doing LVM on the Xen machines.<br>
>> > My question: What is the best option?<br>
>> > Thanks,<br>
>> > Hetz<br>
>><br>
>> I don't have practical experience with hosting Xen images on SAN but<br>
>> when I researched the market for a SAN-based configuration of our<br>
>> production network (currently 20 Xen hosts hosting about 10 Xen guests<br>
>> each, doing DRBD between pairs of Xen guests and linux-ha for HA), at<br>
>> least one or two of the options I checked mentioned that if I store<br>
>> the Xen images on the SAN then it will require much higher bandwidth<br>
>> to it than if I use it just for plain data.<br>
><br>
> Why? Where does the secret IO arrive from?<br>
<br>
</div></div>I haven't dug into this but I figured it was around reading the<br>
program files from the storage to the iSCSI client which actually runs<br>
the Xen image and storing the Xen guest's state if you use xen's<br>
"suspend to disk" stuff.<br>
<font color="#888888"><br>
--Amos<br>
</font></blockquote></div><br></div></div>