On Feb 7, 2013 5:20 PM, "Alex Huang" <[email protected]> wrote: > > > > > -----Original Message----- > > From: Marcus Sorensen [mailto:[email protected]] > > Sent: Thursday, February 07, 2013 3:29 PM > > To: Mike Tutkowski > > Cc: Edison Su; [email protected] > > Subject: Re: Supporting SolidFire QoS Before 4.2 > > > > He's saying that the VM can connect via iscsi directly to the > > solidfire device, rather than the host. You'd lose more performance > > that way and there's more overhead, but it would be a way to give > > individual VMs their own solidfire LUN. > > > Marcus, > > I'm interested in your comment here. Why do you think vm having direct iscsi access actually lose performance? I would think it's actually faster because there's nothing translating the raw LUN into a raw disk.
With iscsi to the host you have hardware nic and iscsi initiator software running on hardware CPU. Then disk is attached to VM. In VM you have paravirtualized nic (overhead) and iscsi initiator on virtual CPU (overhead). Virtual NICs are pretty fast these days but eat lots of CPU in doing so. I can easily eat a core on the host doing 3-4 gbit steady to a VM. The hardware nic optimizations designed to get around this are still unusable for cloud because they tie the VM to the hardware and disable live migration (io-srv). I see what you're saying, that the overhead of running the initiator on a vcpu and over a vnic is less than attaching a local disk to a VM, but from what I've seen that hasn't been the case. Then there's the idea of wanting the VM on a 1gbit pub connection, but maybe your storage is on a 10g private net. That's common, but it could be engineered around I suppose. > > --Alex
