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.netad...@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<dera...@cvs.openbsd.org> > wrote: > > >> On Mon, May 20, 2013 at 8:42 PM, Mike Larkin<mlar...@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 ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd