Upgraded yesterday (aptitude update&upgrade & rebooted server). Everything appears to be fine, however, 2 Solaris 10 guest each with an Ethernet interfaces (E1000 connected to vmbrX) which worked before now suddenly have no network connectivity, interfaces are there but no packets are going. Via console connected to the VM's and did snoop on the interfaces in the guest but I only see some arp request *from* the VM to determine the gateway but no packets from the host into the guest at all. Migrated one of the guest to another server still running on proxmox 3.0 and network works without any issue. Any clues ? Is there a simply recipe to downgrade to 3.0 to I can really confirm 100% this issue is due to upgrade ? Thx.
Solaris 10 Guest no network traffic after upgrade to proxmox 3.1
- Thread starter JimB
- Start date
Found some older versions of the packages under /var/cache/apt/archives and using dpkg / aptitude downgraded to pve-qemu-kvm_1.4-13_amd64.deb qemu-server_3.0-20_amd64.deb pve-manager_3.0-23_amd64.deb proxmox-ve-2.6.32_3.0-107_all.deb and network started working again.
So probably the kvm upgrade has broken solaris guest network/ethernet support.
So probably the kvm upgrade has broken solaris guest network/ethernet support.
Same here.
tcpdump on the TAP Interface shows ARP traffic in and out, but no package is recieved inside the Solaris 10 VM.
09:14:48.583479 ARP, Request who-has 10.1.30.1 (ff:ff:ff:ff:ff:ff) tell 10.1.30.10, length 46
09:14:48.590272 ARP, Reply 10.1.30.1 is-at 00:00:0c:07:ac:01, length 46
...tried with e1000 and rtl8139
tcpdump on the TAP Interface shows ARP traffic in and out, but no package is recieved inside the Solaris 10 VM.
09:14:48.583479 ARP, Request who-has 10.1.30.1 (ff:ff:ff:ff:ff:ff) tell 10.1.30.10, length 46
09:14:48.590272 ARP, Reply 10.1.30.1 is-at 00:00:0c:07:ac:01, length 46
...tried with e1000 and rtl8139
Hi,
I'm deeply disappointed from Proxmox Support in this forum - only some community members tried to help with this problem. No help from Proxmox itself.
To cut a long story short - I downloaded and installed VMWare VSphere 5.1 (never seen VMWare ESXi before) and after 3 hours I had a running system with pass-through and installed OmniOS without any erros.
Thanks for such a good VMWare Product.
I'm deeply disappointed from Proxmox Support in this forum - only some community members tried to help with this problem. No help from Proxmox itself.
To cut a long story short - I downloaded and installed VMWare VSphere 5.1 (never seen VMWare ESXi before) and after 3 hours I had a running system with pass-through and installed OmniOS without any erros.
Thanks for such a good VMWare Product.
The problem is more sophisticated. If you run tcpdump on another vm on the same subnet you see all traffic flowing out to the subnet from a solarisbased vm but the responses is never brought back to the solarisbased vm.
Code:
Sep 19 22:28:03 dhcp-srv-300 dhcpd: DHCPDISCOVER from 96:db:33:d9:ee:78 via eth0
Sep 19 22:28:04 dhcp-srv-300 dhcpd: DHCPOFFER on 192.168.3.101 to 96:db:33:d9:ee:78 via eth0
Sep 19 22:29:07 dhcp-srv-300 dhcpd: DHCPDISCOVER from 96:db:33:d9:ee:78 via eth0
Sep 19 22:29:08 dhcp-srv-300 dhcpd: DHCPOFFER on 192.168.3.101 to 96:db:33:d9:ee:78 via eth0I have just browsed the qemu-1.4.2 git repository and I don't find any changes related to qemu-1.4.2 (pve-qemu-kvm-1.4-17 - pve-3.1) <-> qemu-1.4.1 (pve-qemu-kvm-1.4-13 - pve-3.0) so it seems that one or more of the spice patches which are the difference between the two releases has introduced a regression.
Here goes:
Code:
root 974081 1 99 18:23 ? 00:01:33 /usr/bin/kvm -id 105 -chardev socket,id=qmp,path=/var/run/qemu-server/105.qmp,server,nowait -mon chardev=qmp,mode=control -vnc unix:/var/run/qemu-server/105.vnc,x509,password -pidfile /var/run/qemu-server/105.pid -daemonize -name omnios-15006 -smp sockets=1,cores=1 -nodefaults -boot menu=on -vga qxl -cpu qemu64,+x2apic -k da -spice tls-port=61003,addr=127.0.0.1,tls-ciphers=DES-CBC3-SHA,seamless-migration=on -device virtio-serial,id=spice,bus=pci.0,addr=0x9 -chardev spicevmc,id=vdagent,name=vdagent -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 -m 4096 -cpuunits 1000 -device piix3-usb-uhci,id=uhci,bus=pci.0,addr=0x1.0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 -drive file=/mnt/pve/omnios_nfs/images/105/vm-105-disk-1.raw,if=none,id=drive-ide0,format=raw,cache=writeback,aio=native -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0,id=ide0,bootindex=100 -drive file=/mnt/pve/omnios_nfs/images/105/vm-105-disk-2.raw,if=none,id=drive-ide1,format=raw,cache=writeback,aio=native -device ide-hd,bus=ide.0,unit=1,drive=drive-ide1,id=ide1 -drive file=/mnt/pve/qnap_nfs/template/iso/OmniOS_Text_bloody_20130208.iso,if=none,id=drive-ide2,media=cdrom,aio=native -device ide-cd,bus=ide.1,unit=0,drive=drive-ide2,id=ide2,bootindex=200 -netdev type=tap,id=net0,ifname=tap105i0,script=/var/lib/qemu-server/pve-bridge -device e1000,mac=98:DB:33:D9:EE:78,netdev=net0,bus=pci.0,addr=0x12,id=net0,bootindex=300ps -ef on the node after the guest is started, sorry about that.
Surprisingly in you email there is a --cpu=qemu64 which should have fixed this problem. On the oVirt ML I saw exact the same problem and after installing a pre-vm-start hook which removes the -cpu argument, a Solaris11 guest will heve networking.
I have just tried starting the vm leaving out all spice related, but no cigar:-\
What does this option to cpu mean? ,+x2apic
If a remove this option from the start command I have working network again
What does this option to cpu mean? ,+x2apic
If a remove this option from the start command I have working network again
Also removing +x2apic means no complains from the uhci driver as well as having SATA available for install disk . The SATA part is tested with latest Omnios Bloody (15007)