[FUG-BR] Rede no FreeBSD rodando sobre o XEN no NetBSD.
Adiel de Lima Ribeiro
adiel.netadmin em gmail.com
Quarta Julho 31 10:18:16 BRT 2013
On Wed, 2013-07-31 at 01:37 -0300, Ricardo Ferreira wrote:
> Em 31-07-2013 01:06, Francisco Cardoso escreveu:
> > Em 30 de julho de 2013 22:49, Adiel de Lima Ribeiro
> > <adiel.netadmin em gmail.com> escreveu:
> >> Lista, boa noite.
> >> Pois bem, minha briga com o XEN continua.
> >> Em resumo o problema é, a placa de rede não funciona em meu Guest, que é
> >> um FreeBSD 9-1 amd64, estou utilizando a configuração em modo bridge.
> >>
> >> Instalei e configurei o NetBSD, recompilei o kernel.
> >> As opções relativas a rede em modo bridge são:
> >> pseudo-device tap # virtual Ethernet
> >> pseudo-device bridge # simple inter-network bridging
> >>
> >> Minha placa de rede é a bce0.
> >> Eu comentei as opções relativas a placa de rede no xend-config.sxp:
> >> #(network-script network-bridge)
> >> #(vif-script vif-bridge)
> >> #(vif-script vif-route)
> >> #(vif-script vif-nat)
> >>
> >> Criei o arquivo de configuração da placa de rede em modo
> >> bridge, /etc/ifconfig.brigde0:
> >> create
> >> !brconfig $int add bce0 up
> >>
> >> O ifconfig e o brctl mostram que está tudo certo com as interfaces
> >> quando o Guest está rodando.
> >> Interfaces:
> >> xvif2i0 flags=3<LEARNING,DISCOVER>
> >> port 7 priority 128
> >> tap0 flags=3<LEARNING,DISCOVER>
> >> port 6 priority 128
> >> bce0 flags=3<LEARNING,DISCOVER>
> >> port 1 priority 128
> >>
> >> Estou utilizando o libxl com o xl e não o xend com o xm.
> >> Estou utilizando HVM e não PV.
> >> Segue a parte relativa da configuração de rede da máquina virtual,
> >> freebsd-source.cfg:
> >>
> >> vif = [ 'bridge=bridge0, type=ioemu' ]
> >>
> >>
> >> Durante a instalação, o FreeBSD virtual até reconhece a placa de rede,
> >> como re0, mas não há comunicaçao com a rede real, mesmo com o kernel do
> >> NetBSD para o XEN, o resultado é o mesmo. O que estou fazendo de errado,
> >> esqueci de configurar o que?
> >> Obrigado.
> >>
> >>
> >> --
> >> att,
> >> Adiel de Lima Ribeiro
> >> facebook.com/sembr.dyndns.info
> >>
> >>
> >> -------------------------
> >> Histórico: http://www.fug.com.br/historico/html/freebsd/
> >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
> > Adiel:
> >
> > Não sou nenhum especialista em Xen mas o que faz você pensar que o
> > problema está no FreeBSD?
> >
> > Primeiro você deve garantir que o host está funcionando perfeitamente.
> > E uma maneira de fazer isso seria você tentar fazer o boot de outro
> > guest, por exemplo, Linux ou NetBSD, pra ver se funciona.
> >
> > --
> >
> > Francisco Ricardo
> > ___________________________________
> > Administrador de Redes e Sistemas Unix/Linux
> > Profissional Certificado RedHat | Entusiasta FreeBSD
> > -------------------------
> > Histórico: http://www.fug.com.br/historico/html/freebsd/
> > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
> >
> Caro Francisco...
>
> Concordo 100% pois sempre todos acham que o problema é com o guest e não
> com o sempre isento de bugs virtualizadores em geral...
> Veja o comentário que Theo de Raadt fez outro dia em uma discussão
> exatamente igual a esta que eu vou reproduzir aqui:
>
> On Mon, May 20, 2013 at 8:59 PM, Theo de Raadt<deraadt em cvs.openbsd.org> wrote:
>
> >> On Mon, May 20, 2013 at 8:42 PM, Mike Larkin<mlarkin em azathoth.net> wrote:
> >>> On Mon, May 20, 2013 at 05:11:35PM +0000, Alexey E. Suslikov wrote:
> >>>> Theo de Raadt <deraadt <at> cvs.openbsd.org> writes:
> >>>>
> >>>>> If these VM's are real VM's the should start emulating the machines
> >>>>> they claim to be emulating correctly, or they should start advertising
> >>>>> that they are something "different", so that we can isolate the bullshit
> >>>>> factor.
> >>>> Ok. I see.
> >>>>
> >>>> Could we trim that down to the following?
> >>>>
> >>>> --- sys/arch/amd64/amd64/identcpu.c.orig Mon May 20 19:58:06 2013
> >>>> +++ sys/arch/amd64/amd64/identcpu.c Mon May 20 20:01:08 2013
> >>>> @@ -127,6 +127,7 @@
> >>>> { CPUIDECX_AVX, "AVX" },
> >>>> { CPUIDECX_F16C, "F16C" },
> >>>> { CPUIDECX_RDRAND, "RDRAND" },
> >>>> + { CPUIDECX_HV, "HV" },
> >>>> }, cpu_ecpuid_ecxfeatures[] = {
> >>>> { CPUIDECX_LAHF, "LAHF" },
> >>>> { CPUIDECX_CMPLEG, "CMPLEG" },
> >>>> --- sys/arch/amd64/include/specialreg.h.orig Mon May 20 20:01:56 2013
> >>>> +++ sys/arch/amd64/include/specialreg.h Mon May 20 20:06:09 2013
> >>>> @@ -158,6 +158,7 @@
> >>>> #define CPUIDECX_AVX 0x10000000 /* Advanced Vector Extensions */
> >>>> #define CPUIDECX_F16C 0x20000000 /* 16bit fp conversion */
> >>>> #define CPUIDECX_RDRAND 0x40000000 /* RDRAND instruction */
> >>>> +#define CPUIDECX_HV 0x80000000 /* Hypervisor presence */
> >>>>
> >>>> /*
> >>>> * "Structured Extended Feature Flags Parameters" (CPUID function 0x7, leaf 0)
> >>>>
> >>> That's certainly less objectionable but I'm not sure what useful information
> >>> this diff provides.
> >> Seen in dmesg, HV flag will indicate operating system is run under hypervisor
> >> and weird things are possible while running kernel code which depends on CPU
> >> features.
> >>
> >> After all, it is kinda documented by AMD on page 570 of
> >> http://support.amd.com/us/Processor_TechDocs/24594_APM_v3.pdf
> >>
> >> (AMD named it RAZ, but I put meaningful name like in FreeBSD - should we
> >> put a reference to above mentioned document near the define?).
> > Your statements here are trying to convince us of something which is
> > false.
> >
> > AMD says "RAZ. Reserved for use by hypervisor to indicate guest status."
> >
> > That sentence does not translate to "The hypervisor is heavily broken
> > and fails to completely emulate the machine otherwise advertised by
> > the rest of the CPUID fields".
> >
> > It does not indicate that weird things are possible. If those weird
> > things are possible, it is not because the hardware is broken, but
> > because the*emulation of the hardware* by the VM is broken!
>
> You misunderstood my point.
>
> I'm not trying to convince, but avoid useless work/talk in the future:
>
> Yes you are. You have an agenda.
>
> You want to make us work around a bug, rather than talk to the
> originators of the problem.
>
>
>
> Sem querer flames mas certamente o problema não é no FreeBSD/NetBSD.
>
> Pra quem quiser acompanhar é só acompanhar a lista OpenBSD-bugs que desenvolvedores como Theo de Raadt costumeiramente faz observações inteligentes sobre os problemas camuflados das plataformas de virtualização.
>
>
>
>
> -------------------------
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Bom dia senhores, eu não quiz dizer que o problema está no FreeBSD, ele
apenas foi o primeiro host a ser virtualizado da lista.
Acontece com outros Guests também.
Gostei do comentário do Ricardo, vou analisar com calma.
Vic, em modo bridge não é necessário habilitar o forward.
Concordo que o problema não esta no NetBSD e nem no FreeBSD, por isso
recorri ao forum, é bem simples, estou fazendo algo de errado, nao?
--
att,
Adiel de Lima Ribeiro
facebook.com/sembr.dyndns.info
Mais detalhes sobre a lista de discussão freebsd