Actually I have customers that still virtualize an OS/App even when the result is a 1:1:1 relationship.
Due to direct mapping advancements overhead from running on a hypervisor is very very small. Where the benefits of running an OS/App pair as a VM are many. For example 1.) Abstract an older OS like Windows NT that does not have drivers for current hardware. 2.) Ability to pause, clone, snapshot or rollback the VM. 3.) Ability to move the VM live from one hypervisor to another. Jon On Apr 22, 2013, at 12:36 AM, "Reith, Lothar" <[email protected]> wrote: > Hi Qin, > > I had read that a bare metal server is being used by people who do want to > eliminate the overhead introduced by the hypervisor to the performance of the > server. If the server runs only a single application - why introduce the > overhead of a hypervisor and suffer from the associated performance > degradation? > > Therefore I tend to disagree with the statement, that a bare metal server is > some kind of hypervisor. > > Lothar > > -----Ursprüngliche Nachricht----- > Von: Qin Wu [mailto:[email protected]] > Gesendet: Montag, 22. April 2013 03:59 > An: Reith, Lothar; Thomas Narten; Pat Thaler > Cc: [email protected] > Betreff: RE: [nvo3] vNICs and pNics in draft-wu-nvo3-nve2nve-04.txt > > Hi, Lothar: > Bare metal server is some kind of hypervisor. As I discussed with Larry on > the list before, usually hypervisor hosts multiple VMs. Each VM can be a > tenant system. So I think the case B doesn't stand. > > Regarding Case A and Case C, I think tenant system can be either physical > system or virtual system, as tenant system definition pointed out. > 1.If tenant system is physical system, this could be out of scope of NVO3 > since as Thomas mentioned, native connection to DC network is not necessary > to be in the scope of NOV3. I agree with this, since if tenant system is > physical system(e.g., physical network service appliance, the tenant system > doesn't need to be a VM) > > 2. If tenant system is virtual system, it has two categories: > Category (a) Tenant system plays host role > Category (b) Tenant system plays forwarding element role (I think it should > be virtual forwarding element, if the tenant system is a firewall, it should > be virtual firewall) > > Case A and Case C, in my understanding fall into these two categories. > > Regards! > -Qin > -----Original Message----- > From: Reith, Lothar [mailto:[email protected]] > Sent: Sunday, April 21, 2013 7:21 PM > To: Thomas Narten; Pat Thaler > Cc: [email protected]; Qin Wu > Subject: AW: [nvo3] vNICs and pNics in draft-wu-nvo3-nve2nve-04.txt > > Thomas, > > See below. I do not agree to the wording. > > And I suggest to change the definition of tenant system, which I identified > as being perhaps a root cause of confusion. > > Lothar > > -----Ursprüngliche Nachricht----- > Von: [email protected] [mailto:[email protected]] Im Auftrag von > Thomas Narten > Gesendet: Freitag, 19. April 2013 20:49 > An: Pat Thaler > Cc: [email protected]; Qin Wu > Betreff: Re: [nvo3] vNICs and pNics in draft-wu-nvo3-nve2nve-04.txt > > "Pat Thaler" <[email protected]> writes: > >> In addition to Thomas's point, we should not restrict the number of >> physical NICs that a tenant system can have. Some tenant systems >> will have more than one physical NIC. > > Agreed. > > Lothar: Disagree - Given the current definition of tenant system, one would > have to make a case differentiation throughout the document as follows: > > Case A: Tenant System is a VM > - In this case - which may be the most important one to many - above > statement is wrong, because then the tenant system has zero physical NICs. > > Case B: Tenant System is a bare metal server > - In this case above statement is true > > Case C: Tenant System is "according to current definition" a router or > firewall... > - in this case we start referring to router ports as NICs or pNICs, which may > further increase confusion. > >> We may describe some typical tenant systems as part of examining use >> cases, but NVO3 should define behavior in terms of the network >> interface, i.e. TSI, behavior and should not restrict tenant system >> architecture. > > Another way of looking at it is that the TSI is an attachement > point/interface to the TS. The point where the TSI attaches to the TS > has two sides. On the tenant facing side, it appears to be a NIC. It > looks like a NIC, behaves like a NIC, etc. On the side facing away > from the tenant (e.g., the hypervisor in the case of a virtualized > system) we call it a TSI. The TSI side will have attributes that are > specific to NVO3. > > Does that make sense? > > Thomas > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
