Public bug reported:
Hi,
Here is the context :
$ qemu -name A -m 1024 -net nic vlan=0,model=e1000 -net
socket,vlan=0,listen=127.0.0.1:7000
$ qemu -name B -m 1024 -net nic vlan=0,model=e1000 -net
socket,vlan=0,connect=127.0.0.1:7000
The bandwidth is really tiny :
. Iperf3 reports about 30
Public bug reported:
Hi,
Here is the problem.
I start an empty QEMU in monitor mode :
QEMU 1.1.2 monitor - type 'help' for more information
Warning: vlan 0 is not connected to host network
(qemu) info network
VLAN 0 devices:
e1000.0: type=nic,model=e1000,macaddr=a2:00:00:00:00:01
Devices not o
** Changed in: qemu
Status: New => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1003054
Title:
Socket not closed when a connection ends
Status in QEMU:
Fix Released
Bug des
This implies serious duplication problem in case of reboot :
A [192.168.0.1] <--> B [192.168.0.2]
A# ping 192.168.0.1
PING 192.168.0.1 56(84) bytes of data
64 bytes from 192.168.0.1: icmp_req=1 ttl=64 time=3.82 ms
64 bytes from 192.168.0.1: icmp_req=2 ttl=64 time=0.344 ms
64 bytes from 192.168.0
Public bug reported:
Hi,
I've noticed in the QEMU monitor that when a TCP connection between to
QEMU virtual machines is closed in one side, the other side is not
closed. Consequence is that the network behavior is completely messed up
in case of a reconnection.
For instance, we consider that we
Public bug reported:
Hi,
Let's consider the following lines:
$ qemu -enable-kvm -name opeth -hda debian1.img -k fr -localtime -m 512
-net user,vlan=0 -net nic,vlan=0,model=$model,macaddr=a2:00:00:00:00:10
-net socket,vlan=1,listen=127.0.0.1:5900 -net
nic,vlan=1,model=$model,macaddr=a2:00:00:00:0
Public bug reported:
Hi,
Let's consider the following line:
$ qemu -enable-kvm -name opeth -hda debian.img -k fr -localtime -m 512
-net user,vlan=0,net=192.160.0.0/24 -net
nic,vlan=0,model=$model,macaddr=a2:00:00:00:00:10
In my Guest Virtual Machine, I'm going to call the internal Slirp DHCP
Se
Hi,
No I don't try, i will :)
The probleme is not present with another NIC so I use another one for
the moment.
Vincent
Le 09/02/2012 20:05, Henrique Rodrigues a écrit :
> Vincent,
>
> Have you tried to change the mtu of the tbf qdisc? The traffic control should
> work well if you set it to 6
Hi,
The problem seems to come from the implementation of the Intel e1000
network cards (which is the default one used by QEMU).
If you use another one, the problem does not appear ;)
Vince
Le 29/01/2012 05:49, Henrique Rodrigues a écrit :
> Hi guys,
>
> I'm having the same problem with a ubuntu
.
Vincent
Le 15/12/2011 17:09, Stefan Hajnoczi a écrit :
> On Thu, Dec 15, 2011 at 3:03 PM, Vincent Autefage
> <899...@bugs.launchpad.net> wrote:
>> Ok,
>>
>> So the e1000.c and the e1000_hw.h have absolutely no difference between
>> the original and the ubuntu vers
_isa(nd);
else
-pci_nic_init_nofail(nd, "e1000", NULL);
+pci_nic_init_nofail(nd, "rtl8139", NULL);
}
if (drive_get_max_bus(IF_IDE) >= MAX_IDE_BUS) {
Vincent
Le 15/12/2011 09:07, Stefan Hajnoczi a écrit :
> On Wed, Dec 14, 2011 at 02:42:12PM -,
Ok so the *Intel e1000* seems the only card which is impacted by the
bug.
Vincent
Le 05/12/2011 12:11, Stefan Hajnoczi a écrit :
> On Mon, Dec 5, 2011 at 10:45 AM, Vincent Autefage
> <899...@bugs.launchpad.net> wrote:
>> So we have another problem...
>> The thing is
1 at 10:45 AM, Vincent Autefage
> <899...@bugs.launchpad.net> wrote:
>> So we have another problem...
>> The thing is that the 0.14.0 (and all 0.14.0 rc) built from GIT has the
>> same problem.
>> However, the package 0.14.0 from Ubuntu does not has this bug...
> Okay,
10:45 AM, Vincent Autefage
> <899...@bugs.launchpad.net> wrote:
>> So we have another problem...
>> The thing is that the 0.14.0 (and all 0.14.0 rc) built from GIT has the
>> same problem.
>> However, the package 0.14.0 from Ubuntu does not has this bug...
> Okay, that&
rate of 19mbit which is the desired rate.
Vincent
Le 05/12/2011 12:11, Stefan Hajnoczi a écrit :
> On Mon, Dec 5, 2011 at 10:45 AM, Vincent Autefage
> <899...@bugs.launchpad.net> wrote:
>> So we have another problem...
>> The thing is that the 0.14.0 (and all 0.14.0 rc)
Yes this is the package that seems to not include the bug.
I'm going to check sources of this package.
Vincent Autefage
Le 05/12/2011 12:11, Stefan Hajnoczi a écrit :
> On Mon, Dec 5, 2011 at 10:45 AM, Vincent Autefage
> <899...@bugs.launchpad.net> wrote:
>> So
Hi,
So we have another problem...
The thing is that the 0.14.0 (and all 0.14.0 rc) built from GIT has the
same problem.
However, the package 0.14.0 from Ubuntu does not has this bug...
Le 05/12/2011 09:26, Stefan Hajnoczi a écrit :
> On Sun, Dec 04, 2011 at 03:54:12PM -0000, Vincent Autef
TC is about 19.2 Mbit/s what is the desired result...
Vincent
Le 03/12/2011 19:48, Stefan Hajnoczi a écrit :
> On Fri, Dec 2, 2011 at 2:42 PM, Vincent Autefage
> <899...@bugs.launchpad.net> wrote:
>> *root@A# tc qdisc add dev eth0 root tbf rate 20mbit burst 20480 latency
>
Ok thanks a lot :)
Vincent Autefage
Le 03/12/2011 19:45, Stefan Hajnoczi a écrit :
> On Fri, Dec 2, 2011 at 2:45 PM, Vincent Autefage
> <899...@bugs.launchpad.net> wrote:
>> $ qemu-img create -f raw root.img 100GB
>> $ mkntfs -F root.img
>> $ qemu -name W -sdl -m
Hi,*
$ qemu-img create -f raw root.img 100GB
$ mkntfs -F root.img
$ qemu -name W -sdl -m 2048 -enable-kvm -localtime -k fr -hda root.img
-cdrom windows7.iso -boot d -net nic,macaddr=a0:00:00:00:00:01 -net
user,vlan=0
*
Vincent Autefage
Le 02/12/2011 14:35, Stefan Hajnoczi a écrit :
> On
Hi,
So, the host command lines are :
*$ qemu -name A -sdl -m 512 -enable-kvm -localtime -k fr -hda
debian1.img -net nic,macaddr=a0:00:00:00:00:01 -net
socket,mcast=230.0.0.1:7000*
The second is
*$ qemu -name B -sdl -m 512 -enable-kvm -localtime -k fr -hda
debian2.img -net nic,macaddr=a0:00:00:
** Description changed:
Hi,
- The two last main versions of QEMU (0.15 and 1.0) have an important problem
when running on a Linux distribution which running itself a Traffic Control
(TC) instance.
+ The last main versions of QEMU (0.14.1, 0.15 and 1.0) have an important
problem when runnin
Public bug reported:
Hi,
The installation process of Windows (XP/Vista/7) doesn’t seem to recognize a
raw img generated by qemu-img.
The installer does not see any hard drive...
The problem exists only with a raw img but not with a vmdk for instance.
Thanks
** Affects: qemu
Importance: U
Public bug reported:
Hi,
The two last main versions of QEMU (0.15 and 1.0) have an important problem
when running on a Linux distribution which running itself a Traffic Control
(TC) instance.
Indeed, when TC is configured with a Token Bucket Filter (TBF) with a
particular rate, the effective r
24 matches
Mail list logo
