[FUG-BR] Rede no FreeBSD rodando sobre o XEN no NetBSD.
Ricardo Ferreira
ricardo.ferreira em sotechdatacenter.com.br
Quarta Julho 31 01:37:51 BRT 2013
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.
--
Cordialmente,
Ricardo Ferreira
Meios de Pagamento - Tecnologia IP
Telecom, Tecnologia e Segurança da Informação
-------------------------------------------------------------------
Sotech Soluções Tecnologicas
Rua da Alfazema, 761, 1o. andar - 102/103
41820-710 - Caminho das Árvores - Salvador-BA - Brasil
Tel : 55 71 3472.9400 Cel : 55 71 9138 4630
Email:ricardo.ferreira em sotech.com.br
Site: www.sotech.com.br
Esta mensagem é dirigida apenas ao seu destinatário e pode conter
informações confidenciais, não passíveis de divulgação nos termos da
legislação em vigor. Caso tenha recebido esta mensagem por engano,
solicitamos notificar a Sotech Soluções Tecnológicas e excluí-la de sua
caixa postal.
This message, including its attachments, may contain confidential
information. If you have improperly received this message, please delete
it from your system and notify immediately the sender. Any form of
utilization, reproduction, forward, alteration, distribution and/or
disclosure of this content in whole or in part, without the prior written
authorization of the sender, is strictly prohibited.
Thanks for your cooperation.
-------------- Próxima Parte ----------
Um anexo não texto foi limpo...
Nome : ricardo_ferreira.vcf
Tipo : text/x-vcard
Tam : 443 bytes
Descr.: não disponível
Url : http://www.fug.com.br/historico/html/freebsd/attachments/20130731/cae986fb/attachment.vcf
Mais detalhes sobre a lista de discussão freebsd