[Qemu-devel] Re: [Bug 595438] Re: KVM segmentation fault, using SCSI+writeback and linux 2.4 guest
Fedora1? Seriously? :-P -- KVM segmentation fault, using SCSI+writeback and linux 2.4 guest https://bugs.launchpad.net/bugs/595438 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in Kernel Virtual Machine: Confirmed Status in QEMU: Fix Committed Status in qemu-kvm: Fix Released Status in “qemu-kvm” package in Ubuntu: Fix Released Status in “qemu-kvm” source package in Lucid: Fix Committed Status in “qemu-kvm” package in Debian: Fix Released Bug description: I Use Ubuntu 32 bit 10.04 with standard KVM. I have Intel E7600 @ 3.06GHz processor with VMX In this system I Run: LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -M pc-0.12 -enable-kvm -m 256 -smp 1 -name spamsender -uuid b9cacd5e-08f7-41fd-78c8-89cec59af881 -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/spamsender.monitor,server,nowait -monitor chardev:monitor -boot d -drive file=/mnt/megadiff/cdiso_400_130.iso,if=ide,media=cdrom,index=2 -drive file=/home/mmarkk/spamsender2.img,if=scsi,index=0,format=qcow2,cache=writeback -net nic,macaddr=00:00:00:00:00:00,vlan=0,name=nic.0 -net tap,vlan=0,name=tap.0 -chardev pty,id=serial0 -serial chardev:serial0 -parallel none -usb -vnc 127.0.0.1:0 -vga cirrus .iso image contain custom distro of 2.4-linux kernel based system. During install process (when .tar.gz actively unpacked), kvm dead with segmentation fault. And ONLY when I choose scsi virtual disk and writeback simultaneously. But, writeback+ide, writethrough+scsi works OK. I use qcow2. It seems, that qcow does not have such problems. Virtual machine get down at random time during file copy. It seems, when qcow2 file size need to be expanded. IMPACT: kvm used with scsi virtual disk and writeback dies with segfault. FIX: is the inclusion of a patch cherry-picked from upstream which dequeues requests before invoking callbacks. It is at http://bazaar.launchpad.net/~serge-hallyn/ubuntu/lucid/qemu-kvm/fix-scsi-writeback/revision/70 TO REPRODUCE: See the command above. REGRESSION POTENTIAL: this is cherry-picked from upstream, and has been tested by the bug reporter with no ill effects.
[Qemu-devel] [Bug 532733] Re: apt/dpkg in qemu-system-arm hangs if a big task is installed
** Changed in: qemu-kvm (Ubuntu) Assignee: Dustin Kirkland (kirkland) => (unassigned) ** Changed in: qemu-kvm (Ubuntu Lucid) Assignee: Dustin Kirkland (kirkland) => (unassigned) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/532733 Title: apt/dpkg in qemu-system-arm hangs if a big task is installed Status in QEMU: Invalid Status in “qemu-kvm” package in Ubuntu: Incomplete Status in “qemu-kvm” source package in Lucid: Incomplete Bug description: Binary package hint: qemu-kvm running rootstock and installing ubuntu-netbook^ makes the VM hang in "unpacking iso-codes" this is reproducable every time in rootstock as well as in a standard qemu-system-arm vm that contains a minimal ubuntu with running apt-get install ubuntu-netbook
[Qemu-devel] Re: 8 NIC limit
On Tue, Oct 5, 2010 at 7:48 AM, wrote: > Hello list: > > I'm working on a project that calls for the creation of a firewall in > KVM. > While adding a 20-interface trunk of virtio adapters to bring in a dual > 10GB bond, I've discovered an 8 NIC limit in QEMU. > > I found the following thread in the list archives detailing a similar > problem: > http://kerneltrap.org/mailarchive/linux-kvm/2009/1/29/4848304 > > It includes a patch for the file qemu/net.h to allow 24 NICs: > https://bugs.launchpad.net/ubuntu/+source/qemu-kvm";>qemu-kvm/+bug/595873/+attachment/1429544/+files/max_nics.patch > > In my case I want to attach 29, and have simply changed line 8 to 30 > from 24. > > This will be the first patch I've ever had to do, and so far my internet > search yields results that don't seem to apply. > > Would someone like to recommend a pertinent tutorial? Hi there, I commented on the original bug in Launchpad. We're willing and able to carry the patch against qemu-kvm in Ubuntu, I just asked that the reporter at least submit the patch upstream for discussion. I don't see where that has happened yet. It's a trivial patch to submit. Please note in that bug a pointer to the mailing list thread, if you start one. To your specific question, different communities have different requirements on patch submission, so you do need to consult each community. A good place to start might be the Documentation/SubmittingPatches how-to in the kernel tree: * http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/SubmittingPatches;hb=HEAD In this case, I think you're going to want to send your patch to the qemu-devel (on CC) mailing list (perhaps in addition to sending it here, to the kvm list). :-Dustin
[Qemu-devel] [Bug 697197] Re: Empty password allows access to VNC in libvirt
** Also affects: libvirt (Ubuntu Maverick) Importance: Undecided Status: New ** Also affects: qemu-kvm (Ubuntu Maverick) Importance: Undecided Status: New ** Also affects: libvirt (Ubuntu Natty) Importance: High Assignee: Serge Hallyn (serge-hallyn) Status: Invalid ** Also affects: qemu-kvm (Ubuntu Natty) Importance: Medium Assignee: Dustin Kirkland (kirkland) Status: In Progress -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/697197 Title: Empty password allows access to VNC in libvirt Status in libvirt virtualization API: Unknown Status in QEMU: Confirmed Status in qemu-kvm: Unknown Status in “libvirt” package in Ubuntu: Invalid Status in “qemu-kvm” package in Ubuntu: In Progress Status in “libvirt” source package in Maverick: New Status in “qemu-kvm” source package in Maverick: In Progress Status in “libvirt” source package in Natty: Invalid Status in “qemu-kvm” source package in Natty: In Progress Bug description: The help in the /etc/libvirt/qemu.conf states "To allow access without passwords, leave this commented out. An empty string will still enable passwords, but be rejected by QEMU effectively preventing any use of VNC." yet setting: vnc_password="" allows access to the vnc console without any password prompt just as if it is hashed out completely. ProblemType: Bug DistroRelease: Ubuntu 10.10 Package: libvirt-bin 0.8.3-1ubuntu14 ProcVersionSignature: Ubuntu 2.6.35-24.42-server 2.6.35.8 Uname: Linux 2.6.35-24-server x86_64 Architecture: amd64 Date: Tue Jan 4 12:18:35 2011 InstallationMedia: Ubuntu-Server 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.2) ProcEnviron: LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: libvirt
[Qemu-devel] [Bug 697197] Re: Empty password allows access to VNC in libvirt
Uploading to Natty now... ** Also affects: libvirt (Ubuntu Lucid) Importance: Undecided Status: New ** Also affects: qemu-kvm (Ubuntu Lucid) Importance: Undecided Status: New ** Changed in: qemu-kvm (Ubuntu Lucid) Importance: Undecided => Medium ** Changed in: qemu-kvm (Ubuntu Lucid) Status: New => In Progress ** Changed in: qemu-kvm (Ubuntu Lucid) Assignee: (unassigned) => Dustin Kirkland (kirkland) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/697197 Title: Empty password allows access to VNC in libvirt Status in libvirt virtualization API: Unknown Status in QEMU: Confirmed Status in qemu-kvm: Unknown Status in “libvirt” package in Ubuntu: Invalid Status in “qemu-kvm” package in Ubuntu: Fix Released Status in “libvirt” source package in Lucid: New Status in “qemu-kvm” source package in Lucid: In Progress Status in “libvirt” source package in Maverick: Invalid Status in “qemu-kvm” source package in Maverick: In Progress Status in “libvirt” source package in Natty: Invalid Status in “qemu-kvm” source package in Natty: Fix Released Bug description: The help in the /etc/libvirt/qemu.conf states "To allow access without passwords, leave this commented out. An empty string will still enable passwords, but be rejected by QEMU effectively preventing any use of VNC." yet setting: vnc_password="" allows access to the vnc console without any password prompt just as if it is hashed out completely. ProblemType: Bug DistroRelease: Ubuntu 10.10 Package: libvirt-bin 0.8.3-1ubuntu14 ProcVersionSignature: Ubuntu 2.6.35-24.42-server 2.6.35.8 Uname: Linux 2.6.35-24-server x86_64 Architecture: amd64 Date: Tue Jan 4 12:18:35 2011 InstallationMedia: Ubuntu-Server 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.2) ProcEnviron: LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: libvirt
[Qemu-devel] [Bug 697197] Re: Empty password allows access to VNC in libvirt
Attaching Lucid debdiff. ** Patch added: "697197.lucid.debdiff" https://bugs.launchpad.net/ubuntu/lucid/+source/qemu-kvm/+bug/697197/+attachment/1843553/+files/697197.lucid.debdiff ** Changed in: qemu-kvm (Ubuntu Lucid) Assignee: Dustin Kirkland (kirkland) => Ubuntu Security Team (ubuntu-security) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/697197 Title: Empty password allows access to VNC in libvirt Status in libvirt virtualization API: Unknown Status in QEMU: Confirmed Status in qemu-kvm: Unknown Status in “libvirt” package in Ubuntu: Invalid Status in “qemu-kvm” package in Ubuntu: Fix Released Status in “libvirt” source package in Lucid: New Status in “qemu-kvm” source package in Lucid: In Progress Status in “libvirt” source package in Maverick: Invalid Status in “qemu-kvm” source package in Maverick: In Progress Status in “libvirt” source package in Natty: Invalid Status in “qemu-kvm” source package in Natty: Fix Released Bug description: The help in the /etc/libvirt/qemu.conf states "To allow access without passwords, leave this commented out. An empty string will still enable passwords, but be rejected by QEMU effectively preventing any use of VNC." yet setting: vnc_password="" allows access to the vnc console without any password prompt just as if it is hashed out completely. ProblemType: Bug DistroRelease: Ubuntu 10.10 Package: libvirt-bin 0.8.3-1ubuntu14 ProcVersionSignature: Ubuntu 2.6.35-24.42-server 2.6.35.8 Uname: Linux 2.6.35-24-server x86_64 Architecture: amd64 Date: Tue Jan 4 12:18:35 2011 InstallationMedia: Ubuntu-Server 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.2) ProcEnviron: LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: libvirt
[Qemu-devel] [Bug 697197] Re: Empty password allows access to VNC in libvirt
Marking the libvirt tasks "invalid", as upstream libvirt has correctly pointed out that this bug is in qemu, and not libvirt: * https://bugzilla.redhat.com/show_bug.cgi?id=667097 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/697197 Title: Empty password allows access to VNC in libvirt Status in libvirt virtualization API: Unknown Status in QEMU: Confirmed Status in qemu-kvm: Unknown Status in “libvirt” package in Ubuntu: Invalid Status in “qemu-kvm” package in Ubuntu: Fix Released Status in “libvirt” source package in Lucid: New Status in “qemu-kvm” source package in Lucid: In Progress Status in “libvirt” source package in Maverick: Invalid Status in “qemu-kvm” source package in Maverick: In Progress Status in “libvirt” source package in Natty: Invalid Status in “qemu-kvm” source package in Natty: Fix Released Bug description: The help in the /etc/libvirt/qemu.conf states "To allow access without passwords, leave this commented out. An empty string will still enable passwords, but be rejected by QEMU effectively preventing any use of VNC." yet setting: vnc_password="" allows access to the vnc console without any password prompt just as if it is hashed out completely. ProblemType: Bug DistroRelease: Ubuntu 10.10 Package: libvirt-bin 0.8.3-1ubuntu14 ProcVersionSignature: Ubuntu 2.6.35-24.42-server 2.6.35.8 Uname: Linux 2.6.35-24-server x86_64 Architecture: amd64 Date: Tue Jan 4 12:18:35 2011 InstallationMedia: Ubuntu-Server 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.2) ProcEnviron: LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: libvirt
[Qemu-devel] [Bug 697197] Re: Empty password allows access to VNC in libvirt
Looks good, thanks for doing this, Neil.
I'm going to update it just slightly, as this debdiff will need to go
through the security queue, since there's an associated CVE. I'll prep
that upload and the security team will sponsor it into maverick-
security.
I'll get it uploaded to natty now.
The last thing I need you to do is to email your patch to the qemu-devel
mailing list. The maintainers do not accept patches solely attached to
bugs in Launchpad. Their processes require that you email the patch to
the mailing list. Sorry for the run-around. Cheers!
** Changed in: qemu-kvm (Ubuntu Maverick)
Importance: Undecided => Medium
** Changed in: qemu-kvm (Ubuntu Maverick)
Status: New => In Progress
** Changed in: qemu-kvm (Ubuntu Maverick)
Milestone: None => maverick-updates
** Changed in: qemu-kvm (Ubuntu Maverick)
Assignee: (unassigned) => Dustin Kirkland (kirkland)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/697197
Title:
Empty password allows access to VNC in libvirt
Status in libvirt virtualization API:
Unknown
Status in QEMU:
Confirmed
Status in qemu-kvm:
Unknown
Status in “libvirt” package in Ubuntu:
Invalid
Status in “qemu-kvm” package in Ubuntu:
In Progress
Status in “libvirt” source package in Maverick:
Invalid
Status in “qemu-kvm” source package in Maverick:
In Progress
Status in “libvirt” source package in Natty:
Invalid
Status in “qemu-kvm” source package in Natty:
In Progress
Bug description:
The help in the /etc/libvirt/qemu.conf states
"To allow access without passwords, leave this commented out. An empty
string will still enable passwords, but be rejected by QEMU
effectively preventing any use of VNC."
yet setting:
vnc_password=""
allows access to the vnc console without any password prompt just as
if it is hashed out completely.
ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: libvirt-bin 0.8.3-1ubuntu14
ProcVersionSignature: Ubuntu 2.6.35-24.42-server 2.6.35.8
Uname: Linux 2.6.35-24-server x86_64
Architecture: amd64
Date: Tue Jan 4 12:18:35 2011
InstallationMedia: Ubuntu-Server 10.04.1 LTS "Lucid Lynx" - Release amd64
(20100816.2)
ProcEnviron:
LANG=en_GB.UTF-8
SHELL=/bin/bash
SourcePackage: libvirt
[Qemu-devel] [Bug 697197] Re: Empty password allows access to VNC in libvirt
Confirmed that the affected code is also in Lucid. Adding a task for that, and attaching a debdiff for lucid-security too. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/697197 Title: Empty password allows access to VNC in libvirt Status in libvirt virtualization API: Unknown Status in QEMU: Confirmed Status in qemu-kvm: Unknown Status in “libvirt” package in Ubuntu: Invalid Status in “qemu-kvm” package in Ubuntu: Fix Released Status in “libvirt” source package in Lucid: New Status in “qemu-kvm” source package in Lucid: In Progress Status in “libvirt” source package in Maverick: Invalid Status in “qemu-kvm” source package in Maverick: In Progress Status in “libvirt” source package in Natty: Invalid Status in “qemu-kvm” source package in Natty: Fix Released Bug description: The help in the /etc/libvirt/qemu.conf states "To allow access without passwords, leave this commented out. An empty string will still enable passwords, but be rejected by QEMU effectively preventing any use of VNC." yet setting: vnc_password="" allows access to the vnc console without any password prompt just as if it is hashed out completely. ProblemType: Bug DistroRelease: Ubuntu 10.10 Package: libvirt-bin 0.8.3-1ubuntu14 ProcVersionSignature: Ubuntu 2.6.35-24.42-server 2.6.35.8 Uname: Linux 2.6.35-24-server x86_64 Architecture: amd64 Date: Tue Jan 4 12:18:35 2011 InstallationMedia: Ubuntu-Server 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.2) ProcEnviron: LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: libvirt
[Qemu-devel] [Bug 697197] Re: Empty password allows access to VNC in libvirt
** Changed in: qemu-kvm (Ubuntu) Importance: Undecided => Medium ** Changed in: qemu-kvm (Ubuntu) Status: Confirmed => In Progress ** Changed in: qemu-kvm (Ubuntu) Assignee: (unassigned) => Dustin Kirkland (kirkland) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/697197 Title: Empty password allows access to VNC in libvirt Status in libvirt virtualization API: Unknown Status in QEMU: Confirmed Status in qemu-kvm: Unknown Status in “libvirt” package in Ubuntu: Invalid Status in “qemu-kvm” package in Ubuntu: In Progress Status in “libvirt” source package in Maverick: New Status in “qemu-kvm” source package in Maverick: New Status in “libvirt” source package in Natty: Invalid Status in “qemu-kvm” source package in Natty: In Progress Bug description: The help in the /etc/libvirt/qemu.conf states "To allow access without passwords, leave this commented out. An empty string will still enable passwords, but be rejected by QEMU effectively preventing any use of VNC." yet setting: vnc_password="" allows access to the vnc console without any password prompt just as if it is hashed out completely. ProblemType: Bug DistroRelease: Ubuntu 10.10 Package: libvirt-bin 0.8.3-1ubuntu14 ProcVersionSignature: Ubuntu 2.6.35-24.42-server 2.6.35.8 Uname: Linux 2.6.35-24-server x86_64 Architecture: amd64 Date: Tue Jan 4 12:18:35 2011 InstallationMedia: Ubuntu-Server 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.2) ProcEnviron: LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: libvirt
[Qemu-devel] [Bug 697197] Re: Empty password allows access to VNC in libvirt
@security team, Could you please sponsor this to the maverick-security queue? Thanks! ** Patch added: "697197.debdiff" https://bugs.launchpad.net/ubuntu/maverick/+source/qemu-kvm/+bug/697197/+attachment/1843528/+files/697197.debdiff ** Changed in: qemu-kvm (Ubuntu Maverick) Assignee: Dustin Kirkland (kirkland) => Ubuntu Security Team (ubuntu-security) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/697197 Title: Empty password allows access to VNC in libvirt Status in libvirt virtualization API: Unknown Status in QEMU: Confirmed Status in qemu-kvm: Unknown Status in “libvirt” package in Ubuntu: Invalid Status in “qemu-kvm” package in Ubuntu: In Progress Status in “libvirt” source package in Maverick: Invalid Status in “qemu-kvm” source package in Maverick: In Progress Status in “libvirt” source package in Natty: Invalid Status in “qemu-kvm” source package in Natty: In Progress Bug description: The help in the /etc/libvirt/qemu.conf states "To allow access without passwords, leave this commented out. An empty string will still enable passwords, but be rejected by QEMU effectively preventing any use of VNC." yet setting: vnc_password="" allows access to the vnc console without any password prompt just as if it is hashed out completely. ProblemType: Bug DistroRelease: Ubuntu 10.10 Package: libvirt-bin 0.8.3-1ubuntu14 ProcVersionSignature: Ubuntu 2.6.35-24.42-server 2.6.35.8 Uname: Linux 2.6.35-24-server x86_64 Architecture: amd64 Date: Tue Jan 4 12:18:35 2011 InstallationMedia: Ubuntu-Server 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.2) ProcEnviron: LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: libvirt
[Qemu-devel] [Bug 697197] Re: Empty password allows access to VNC in libvirt
** Changed in: libvirt (Ubuntu Maverick) Status: New => Invalid -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/697197 Title: Empty password allows access to VNC in libvirt Status in libvirt virtualization API: Unknown Status in QEMU: Confirmed Status in qemu-kvm: Unknown Status in “libvirt” package in Ubuntu: Invalid Status in “qemu-kvm” package in Ubuntu: Fix Released Status in “libvirt” source package in Lucid: New Status in “qemu-kvm” source package in Lucid: In Progress Status in “libvirt” source package in Maverick: Invalid Status in “qemu-kvm” source package in Maverick: In Progress Status in “libvirt” source package in Natty: Invalid Status in “qemu-kvm” source package in Natty: Fix Released Bug description: The help in the /etc/libvirt/qemu.conf states "To allow access without passwords, leave this commented out. An empty string will still enable passwords, but be rejected by QEMU effectively preventing any use of VNC." yet setting: vnc_password="" allows access to the vnc console without any password prompt just as if it is hashed out completely. ProblemType: Bug DistroRelease: Ubuntu 10.10 Package: libvirt-bin 0.8.3-1ubuntu14 ProcVersionSignature: Ubuntu 2.6.35-24.42-server 2.6.35.8 Uname: Linux 2.6.35-24-server x86_64 Architecture: amd64 Date: Tue Jan 4 12:18:35 2011 InstallationMedia: Ubuntu-Server 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.2) ProcEnviron: LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: libvirt
[Qemu-devel] [Bug 604872] Re: qemu-system-arm segfaults emulating versatile machine after running debootstrap --second-stage inside vm
Moving this bug over to the qemu-linaro package, which now provides qemu-system-arm ** Package changed: qemu-kvm (Ubuntu) => qemu-linaro (Ubuntu) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/604872 Title: qemu-system-arm segfaults emulating versatile machine after running debootstrap --second-stage inside vm Status in QEMU: Fix Committed Status in “qemu-linaro” package in Ubuntu: Triaged Bug description: Binary package hint: qemu-kvm As I'm now implementing the support for creating a rootstock rootfs without requiring root, I need to run the deboostrap' second stage inside a VM, to correctly install the packages into the rootfs. qemu-system-arm fails right after debootstrap finish the second stage, giving a segmentation fault. Command: qemu-system-arm -M versatilepb -cpu cortex-a8 -kernel vmlinuz -no-reboot -nographic -drive file=qemu-armel-201007122016.img,aio=native,cache=none -m 256 -append 'console=ttyAMA0,115200n8 root=/dev/sda rw mem=256M devtmpfs.mount=0 init=/bin/installer' Uncompressing Linux. done, booting the kernel. [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 2.6.32-21-versatile (buildd@cushaw) (gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) ) #32-Ubuntu Fri Apr 16 08:14:53 UTC 2010 (Ubuntu 2.6.32-21.32-versatile 2.6.32.11+drm33.2) ... I: Base system installed successfully. I: Starting basic services in VM Segmentation fault (core dumped) [492816.197352] qemu-system-arm[16024]: segfault at cf6ba8fc ip cf6ba8fc sp 7fffd0e68680 error 14 Image: * rootfs: http://rsalveti.net/pub/ubuntu/rootstock/qemu-armel-201007122016.img (md5 1d063ac8a65c798bb004cd1c4c7970c5) * kernel: http://ports.ubuntu.com/ubuntu-ports/dists/lucid/main/installer-armel/current/images/versatile/netboot/vmlinuz I'm able to reproduce the bug on Maverick (amd64) and Lucid (x86). Maverick qemu-kvm-extras: 0.12.4+noroms-0ubuntu4 Lucid qemu-kvm-extras: 0.12.3+noroms-0ubuntu9.2 ProblemType: Bug DistroRelease: Ubuntu 10.10 Package: qemu-kvm-extras 0.12.4+noroms-0ubuntu4 ProcVersionSignature: Ubuntu 2.6.35-6.9-generic 2.6.35-rc3 Uname: Linux 2.6.35-6-generic x86_64 Architecture: amd64 Date: Mon Jul 12 18:55:35 2010 InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release amd64 (20100427.1) KvmCmdLine: Error: command ['ps', '-C', 'kvm', '-F'] failed with exit code 1: UIDPID PPID CSZ RSS PSR STIME TTY TIME CMD MachineType: LENOVO 2764CTO PccardctlIdent: Socket 0: no product info available PccardctlStatus: Socket 0: no card ProcCmdLine: BOOT_IMAGE=/vmlinuz-2.6.35-6-generic root=/dev/mapper/primary-root ro crashkernel=384M-2G:64M,2G-:128M quiet splash ProcEnviron: LANG=en_US.utf8 SHELL=/bin/bash SourcePackage: qemu-kvm dmi.bios.date: 04/19/2010 dmi.bios.vendor: LENOVO dmi.bios.version: 7UET86WW (3.16 ) dmi.board.name: 2764CTO dmi.board.vendor: LENOVO dmi.board.version: Not Available dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Not Available dmi.modalias: dmi:bvnLENOVO:bvr7UET86WW(3.16):bd04/19/2010:svnLENOVO:pn2764CTO:pvrThinkPadT400:rvnLENOVO:rn2764CTO:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable: dmi.product.name: 2764CTO dmi.product.version: ThinkPad T400 dmi.sys.vendor: LENOVO
[Qemu-devel] [Bug 532733] Re: apt/dpkg in qemu-system-arm hangs if a big task is installed
Moving this bug over to the qemu-linaro package, which now provides qemu-system-arm ** Package changed: qemu-kvm (Ubuntu) => qemu-linaro (Ubuntu) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/532733 Title: apt/dpkg in qemu-system-arm hangs if a big task is installed Status in QEMU: Invalid Status in “qemu-linaro” package in Ubuntu: Incomplete Status in “qemu-linaro” source package in Lucid: Incomplete Bug description: Binary package hint: qemu-kvm running rootstock and installing ubuntu-netbook^ makes the VM hang in "unpacking iso-codes" this is reproducable every time in rootstock as well as in a standard qemu-system-arm vm that contains a minimal ubuntu with running apt-get install ubuntu-netbook
[Qemu-devel] [Bug 697197] Re: Empty password allows access to VNC in libvirt
Attaching debdiff for karmic. ** Patch added: "697197.karmic.debdiff" https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/697197/+attachment/1844267/+files/697197.karmic.debdiff -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/697197 Title: Empty password allows access to VNC in libvirt Status in libvirt virtualization API: Unknown Status in QEMU: Confirmed Status in qemu-kvm: Unknown Status in “libvirt” package in Ubuntu: Invalid Status in “qemu-kvm” package in Ubuntu: Fix Released Status in “libvirt” source package in Lucid: Invalid Status in “qemu-kvm” source package in Lucid: In Progress Status in “libvirt” source package in Maverick: Invalid Status in “qemu-kvm” source package in Maverick: In Progress Status in “libvirt” source package in Natty: Invalid Status in “qemu-kvm” source package in Natty: Fix Released Status in “libvirt” source package in Karmic: Invalid Status in “qemu-kvm” source package in Karmic: In Progress Bug description: The help in the /etc/libvirt/qemu.conf states "To allow access without passwords, leave this commented out. An empty string will still enable passwords, but be rejected by QEMU effectively preventing any use of VNC." yet setting: vnc_password="" allows access to the vnc console without any password prompt just as if it is hashed out completely. ProblemType: Bug DistroRelease: Ubuntu 10.10 Package: libvirt-bin 0.8.3-1ubuntu14 ProcVersionSignature: Ubuntu 2.6.35-24.42-server 2.6.35.8 Uname: Linux 2.6.35-24-server x86_64 Architecture: amd64 Date: Tue Jan 4 12:18:35 2011 InstallationMedia: Ubuntu-Server 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.2) ProcEnviron: LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: libvirt
[Qemu-devel] Re: [ANNOUNCE] qemu-kvm-0.12.0-rc2 released
On Mon, Dec 14, 2009 at 12:33 PM, Avi Kivity wrote: > qemu-kvm-0.12.0-rc2 is now available. This release is is based on the > upstream qemu 0.12.0-rc2, plus kvm-specific enhancements. Please see the > original qemu 0.12.0-rc2 release announcement for details. > > This release can be used with the kvm kernel modules provided by your > distribution kernel, or by the modules in the kvm-kmod package, such as > kvm-kmod-2.6.32. > > Please give test this release out so we can enjoy a stable 0.12.0 final > release. Hi Avi/Anthony- I'm working on the packaging updates for Ubuntu Lucid, and I'm having trouble with the BIOS bits of qemu-kvm. It seems that a fair amount of the BIOS submodules are missing. The roms/ tree is basically empty. I see some of the necessary bits in pc-bios/ and in kvm/vgabios/, but not enough here to build a usable qemu-kvm-0.12.0~rc2 package yet. :-Dustin
[Qemu-devel] Re: [ANNOUNCE] qemu-kvm-0.12.0-rc2 released
On Tue, 2009-12-15 at 11:10 +0200, Avi Kivity wrote: > Well, binaries are shipped, but I guess you'd like to build from source. Right, sorry I was ambiguous. > We have several options: ... > - fetch the submodules and include them in the tarball ... I think this option would help keep us all on the same page. But I could live with pointers to the submodules, since packaging a new release only happens a couple of times per year. :-Dustin signature.asc Description: This is a digitally signed message part
[Qemu-devel] Re: [ANNOUNCE] qemu-kvm-0.12.0-rc2 released
On Sun, Dec 20, 2009 at 10:25 AM, Avi Kivity wrote: > On 12/15/2009 05:21 PM, Dustin Kirkland wrote: >> >>> - fetch the submodules and include them in the tarball >>> >> >> ... >> >> I think this option would help keep us all on the same page. But I >> could live with pointers to the submodules, since packaging a new >> release only happens a couple of times per year. >> >> > > Due to time constraints I went for the simpler option of adding a generated > EXTERNAL_DEPENDENCIES file. Patches for including the source are welcome. Fair enough. It's straightforward by hand, and I only really package twice a year. What about the qemu-system-arm build break I also mentioned? That's currently blocking my packaging. Thanks, :-Dustin
[Qemu-devel] Re: KVM developer call minutes (Jan 19)
mon.h"
+#include "cpu-uname.h"
+
+/* return highest utsname machine name for emulated instruction set
+ *
+ * NB: the default emulated CPU ("any") might not match any existing CPU, e.g.
+ * on ARM it has all features turned on, so there is no perfect arch string to
+ * return here */
+const char *cpu_to_uname_machine(void *cpu_env)
+{
+#ifdef TARGET_ARM
+/* utsname machine name on linux arm is CPU arch name + endianness, e.g.
+ * armv7l; to get a list of CPU arch names from the linux source, use:
+ * grep arch_name: -A1 linux/arch/arm/mm/proc-*.S
+ * see arch/arm/kernel/setup.c: setup_processor()
+ *
+ * to test by CPU id, compare cpu_env->cp15.c0_cpuid to ARM_CPUID_*
+ * defines and to test by CPU feature, use arm_feature(cpu_env,
+ * ARM_FEATURE_*) */
+
+/* in theory, endianness is configurable on some ARM CPUs, but this isn't
+ * used in user mode emulation */
+#ifdef TARGET_WORDS_BIGENDIAN
+#define utsname_suffix "b"
+#else
+#define utsname_suffix "l"
+#endif
+if (arm_feature(cpu_env, ARM_FEATURE_V7))
+return "armv7" utsname_suffix;
+if (arm_feature(cpu_env, ARM_FEATURE_V6))
+return "armv6" utsname_suffix;
+/* earliest emulated CPU is ARMv5TE; qemu can emulate the 1026, but not its
+ * Jazelle support */
+return "armv5te" utsname_suffix;
+#elif defined(TARGET_X86_64)
+return "x86-64";
+#elif defined(TARGET_I386)
+/* see arch/x86/kernel/cpu/bugs.c: check_bugs(), 386, 486, 586, 686 */
+uint32_t cpuid_version = ((CPUX86State *)cpu_env)->cpuid_version;
+int family = ((cpuid_version >> 8) & 0x0f) + ((cpuid_version >> 20) & 0xff);
+if (family == 4)
+return "i486";
+if (family == 5)
+return "i586";
+return "i686";
+#else
+/* default is #define-d in each arch/ subdir */
+return UNAME_MACHINE;
+#endif
+}
diff --git a/linux-user/cpu-uname.h b/linux-user/cpu-uname.h
new file mode 100644
index 000..32492de
--- /dev/null
+++ b/linux-user/cpu-uname.h
@@ -0,0 +1 @@
+const char *cpu_to_uname_machine(void *cpu_env);
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index f2dd39e..9fb493f 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -82,6 +82,7 @@
#include
#include
#include "linux_loop.h"
+#include "cpu-uname.h"
#include "qemu.h"
#include "qemu-common.h"
@@ -5739,7 +5740,7 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1,
if (!is_error(ret)) {
/* Overrite the native machine name with whatever is being
emulated. */
-strcpy (buf->machine, UNAME_MACHINE);
+strcpy (buf->machine, cpu_to_uname_machine(cpu_env));
/* Allow the user to override the reported release. */
if (qemu_uname_release && *qemu_uname_release)
strcpy (buf->release, qemu_uname_release);
--
1.6.5
qemu-img: improve error reporting
Use strerror to provide a better error message when qemu-img fails.
https://bugs.edge.launchpad.net/ubuntu/+source/qemu-kvm/+bug/418112
Signed-off-by: Dustin Kirkland
diff -uprN qemu-kvm-0.11.0~rc2/qemu-img.c qemu-kvm-0.11.0~rc2.new/qemu-img.c
--- qemu-kvm-0.11.0~rc2/qemu-img.c 2009-08-30 04:10:59.0 -0500
+++ qemu-kvm-0.11.0~rc2.new/qemu-img.c 2009-09-10 22:30:32.572211443 -0500
@@ -368,7 +368,7 @@ static int img_create(int argc, char **a
} else if (ret == -EFBIG) {
error("The image size is too large for file format '%s'", fmt);
} else {
-error("Error while formatting");
+error("Error while formatting (%s)", strerror(-ret));
}
}
return 0;
[Qemu-devel] [Bug 393430] Re: kvm: use PulseAudio instead of ALSA
Hmm, I think upstream does prioritize pa over alsa. Marking incomplete, need to check that. ** Changed in: qemu Status: New => Incomplete -- kvm: use PulseAudio instead of ALSA https://bugs.launchpad.net/bugs/393430 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: Incomplete Status in “kvm” package in Ubuntu: Incomplete Status in “kvm” package in Debian: Fix Released Bug description: Binary package hint: kvm kvm in jaunty prefers to use OSS drivers rather than ALSA: # dpkg -l | grep kvm ii kvm1:84+dfsg-0ubuntu11Full virtualization on i386 and amd64 hardwa # kvm -audio-help | grep ^Name Name: oss Name: alsa Name: sdl Name: pa Name: none Name: wav # Because of that, once a virtual machine with working audio card starts, the kvm grabs the audio card entirely for itself. Any subsequent operations on audio card either from the host machine, or from the other audio-enabled virtual machines lock up (apparently awaiting on on access to the audio card). The bug is echo of the corresponding debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508018
[Qemu-devel] [Bug 393430] Re: kvm: use PulseAudio instead of ALSA
Hmm, I think upstream does prioritize pa over alsa. Marking incomplete, need to check that. -- kvm: use PulseAudio instead of ALSA https://bugs.launchpad.net/bugs/393430 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: Incomplete Status in “kvm” package in Ubuntu: Incomplete Status in “kvm” package in Debian: Fix Released Bug description: Binary package hint: kvm kvm in jaunty prefers to use OSS drivers rather than ALSA: # dpkg -l | grep kvm ii kvm1:84+dfsg-0ubuntu11Full virtualization on i386 and amd64 hardwa # kvm -audio-help | grep ^Name Name: oss Name: alsa Name: sdl Name: pa Name: none Name: wav # Because of that, once a virtual machine with working audio card starts, the kvm grabs the audio card entirely for itself. Any subsequent operations on audio card either from the host machine, or from the other audio-enabled virtual machines lock up (apparently awaiting on on access to the audio card). The bug is echo of the corresponding debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508018
Re: [Qemu-devel] [Bug 391879] Re: migrate exec ignores exit status
On Thu, May 20, 2010 at 12:11 PM, Daniel P. Berrange wrote: > This bug appears to be filed against the Ubuntu qemu component, > rather than the upstream qemu component. Are we supposed to be > getting notifications for all Ubuntu distro qemu bugs too, rather > than just usptream bug reports ? This bug is filed as affecting both the qemu-kvm package in Ubuntu, as well as the QEMU project (upstream). Activity in the bug is sent to subscribed parties of both the affected package, and the affected project. :-Dustin
[Qemu-devel] Re: [Bug 513273] Re: kvm with -vga std is broken since karmic
@Claus- Other than the error message, are you seeing incorrect behavior? If so, what specifically? -- kvm with -vga std is broken since karmic https://bugs.launchpad.net/bugs/513273 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: Invalid Status in “qemu-kvm” package in Ubuntu: Invalid Status in “seabios” package in Ubuntu: Invalid Status in “vgabios” package in Ubuntu: Fix Released Status in “qemu-kvm” source package in Lucid: Invalid Status in “seabios” source package in Lucid: Invalid Status in “vgabios” source package in Lucid: Fix Released Bug description: Binary package hint: qemu-kvm it works with -vga cirrus, with -vga std I got: BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters And driver do not work properly (I can not set screen resolution) ... virtual machine almost works, only screen problem in winxp guest ProblemType: Bug Architecture: amd64 Date: Wed Jan 27 15:15:49 2010 DistroRelease: Ubuntu 10.04 KvmCmdLine: Error: command ['ps', '-C', 'kvm', '-F'] failed with exit code 1: UIDPID PPID CSZ RSS PSR STIME TTY TIME CMD MachineType: Acer Aspire 9300 NonfreeKernelModules: nvidia Package: qemu-kvm 0.12.2-0ubuntu1 PccardctlIdent: Socket 0: no product info available PccardctlStatus: Socket 0: no card ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.32-11-generic root=UUID=793246ac-c5ff-421b-a508-052d57cca90c ro rootfstype=ext4 quiet splash
[Qemu-devel] [Bug 595117] Re: qemu-nbd slow and missing "writeback" cache option
Stephane-
Could you please send that patch to the qemu-devel@ mailing list?
Thanks!
--
qemu-nbd slow and missing "writeback" cache option
https://bugs.launchpad.net/bugs/595117
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Status in QEMU: Invalid
Status in “qemu-kvm” package in Ubuntu: Incomplete
Bug description:
Binary package hint: qemu-kvm
dpkg -l | grep qemu
ii kvm
1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9dummy transitional
pacakge from kvm to qemu-
ii qemu 0.12.3+noroms-0ubuntu9
dummy transitional pacakge from qemu to qemu
ii qemu-common 0.12.3+noroms-0ubuntu9
qemu common functionality (bios, documentati
ii qemu-kvm 0.12.3+noroms-0ubuntu9
Full virtualization on i386 and amd64 hardwa
ii qemu-kvm-extras 0.12.3+noroms-0ubuntu9
fast processor emulator binaries for non-x86
ii qemu-launcher1.7.4-1ubuntu2
GTK+ front-end to QEMU computer emulator
ii qemuctl 0.2-2
controlling GUI for qemu
lucid amd64.
qemu-nbd is a lot slower when writing to disk than say nbd-server.
It appears it is because by default the disk image it serves is open with
O_SYNC. The --nocache option, unintuitively, makes matters a bit better because
it causes the image to be open with O_DIRECT instead of O_SYNC.
The qemu code allows an image to be open without any of those flags, but
unfortunately qemu-nbd doesn't have the option to do that (qemu doesn't allow
the image to be open with both O_SYNC and O_DIRECT though).
The default of qemu-img (of using O_SYNC) is not very sensible because anyway,
the client (the kernel) uses caches (write-back), (and "qemu-nbd -d" doesn't
flush those by the way). So if for instance qemu-nbd is killed, regardless of
whether qemu-nbd uses O_SYNC, O_DIRECT or not, the data in the image will not
be consistent anyway, unless "syncs" are done by the client (like fsync on the
nbd device or sync mount option), and with qemu-nbd's O_SYNC mode, those
"sync"s will be extremely slow.
Attached is a patch that adds a --cache={off,none,writethrough,writeback}
option to qemu-nbd.
--cache=off is the same as --nocache (that is use O_DIRECT), writethrough is
using O_SYNC and is still the default so this patch doesn't change the
functionality. writeback is none of those flags, so is the addition of this
patch. The patch also does an fsync upon "qemu-nbd -d" to make sure data is
flushed to the image before removing the nbd.
Consider this test scenario:
dd bs=1M count=100 of=a < /dev/null
qemu-nbd --cache= -c /dev/nbd0 a
cp /dev/zero /dev/nbd0
time perl -MIO::Handle -e 'STDOUT->sync or die$!' 1<> /dev/nbd0
With cache=writethrough (the default), it takes over 10 minutes to write those
100MB worth of zeroes. Running a strace, we see the recvfrom and sentos delayed
by each 1kb write(2)s to disk (10 to 30 ms per write).
With cache=off, it takes about 30 seconds.
With cache=writeback, it takes about 3 seconds, which is similar to the
performance you get with nbd-server
Note that the cp command runs instantly as the data is buffered by the client
(the kernel), and not sent to qemu-nbd until the fsync(2) is called.
[Qemu-devel] Re: [Bug 595117] Re: qemu-nbd slow and missing "writeback" cache option
Stephane-
I understand your plight. However, according to the rules and
policies of the QEMU project, you must submit the patch on the
qemu-devel@ mailing list, in addition to (or instead of) in the bug
tracker. It's not my project, not my policy. I'm just trying to make
sure you get your patch in front of the right audience such that it
can be discussed and accepted.
--
qemu-nbd slow and missing "writeback" cache option
https://bugs.launchpad.net/bugs/595117
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Status in QEMU: Invalid
Status in “qemu-kvm” package in Ubuntu: Incomplete
Bug description:
Binary package hint: qemu-kvm
dpkg -l | grep qemu
ii kvm
1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9dummy transitional
pacakge from kvm to qemu-
ii qemu 0.12.3+noroms-0ubuntu9
dummy transitional pacakge from qemu to qemu
ii qemu-common 0.12.3+noroms-0ubuntu9
qemu common functionality (bios, documentati
ii qemu-kvm 0.12.3+noroms-0ubuntu9
Full virtualization on i386 and amd64 hardwa
ii qemu-kvm-extras 0.12.3+noroms-0ubuntu9
fast processor emulator binaries for non-x86
ii qemu-launcher1.7.4-1ubuntu2
GTK+ front-end to QEMU computer emulator
ii qemuctl 0.2-2
controlling GUI for qemu
lucid amd64.
qemu-nbd is a lot slower when writing to disk than say nbd-server.
It appears it is because by default the disk image it serves is open with
O_SYNC. The --nocache option, unintuitively, makes matters a bit better because
it causes the image to be open with O_DIRECT instead of O_SYNC.
The qemu code allows an image to be open without any of those flags, but
unfortunately qemu-nbd doesn't have the option to do that (qemu doesn't allow
the image to be open with both O_SYNC and O_DIRECT though).
The default of qemu-img (of using O_SYNC) is not very sensible because anyway,
the client (the kernel) uses caches (write-back), (and "qemu-nbd -d" doesn't
flush those by the way). So if for instance qemu-nbd is killed, regardless of
whether qemu-nbd uses O_SYNC, O_DIRECT or not, the data in the image will not
be consistent anyway, unless "syncs" are done by the client (like fsync on the
nbd device or sync mount option), and with qemu-nbd's O_SYNC mode, those
"sync"s will be extremely slow.
Attached is a patch that adds a --cache={off,none,writethrough,writeback}
option to qemu-nbd.
--cache=off is the same as --nocache (that is use O_DIRECT), writethrough is
using O_SYNC and is still the default so this patch doesn't change the
functionality. writeback is none of those flags, so is the addition of this
patch. The patch also does an fsync upon "qemu-nbd -d" to make sure data is
flushed to the image before removing the nbd.
Consider this test scenario:
dd bs=1M count=100 of=a < /dev/null
qemu-nbd --cache= -c /dev/nbd0 a
cp /dev/zero /dev/nbd0
time perl -MIO::Handle -e 'STDOUT->sync or die$!' 1<> /dev/nbd0
With cache=writethrough (the default), it takes over 10 minutes to write those
100MB worth of zeroes. Running a strace, we see the recvfrom and sentos delayed
by each 1kb write(2)s to disk (10 to 30 ms per write).
With cache=off, it takes about 30 seconds.
With cache=writeback, it takes about 3 seconds, which is similar to the
performance you get with nbd-server
Note that the cp command runs instantly as the data is buffered by the client
(the kernel), and not sent to qemu-nbd until the fsync(2) is called.
Re: [Qemu-devel] Re: Qemu does not pass pressed caps lock to client
On Fri, 2010-02-12 at 12:44 -0600, Anthony Liguori wrote: > On 02/12/2010 12:17 PM, Paolo Bonzini wrote: > > On 02/12/2010 04:15 PM, Anthony Liguori wrote: > >> > >> So basically, Debian carries a hacked version of SDL that changes the > >> key press behaviour? > > > > Yes, the patch was submitted to not change the default but the > > maintainer thought he knew better. Or confused an == with a != more > > likely. > > > >> That's a Debian/Ubuntu bug. Shame on them for changing the behaviour of > >> a library API like that. > > > > Indeed. Maybe the Debian/Ubuntu maintainers for QEMU and KVM will > > read this thread and make a fuss. > > I've already updated the bug report appropriately. Dustin, the ball's > in your court :-) I looked at the original Debian Bug, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=317010 The libsdl1.2 package in Ubuntu is no longer carrying that patch, debian/patches/005_lock_keys.diff. So I don't think that's quite the cause of this. As for reproducing the bug, eventually, I was able to get my host and guest caps-lock keys out of sync, if I went back and forth, between guest and host, toggling caps-lock. What's the desired behavior here? I don't have much of an opinion (other than that the caps-lock key is a waste of valuable keyboard real estate, that I never actually use on purpose, only ever hitting it accidentally and causing problems :-) :-Dustin signature.asc Description: This is a digitally signed message part
Re: [Qemu-devel] Patches in bug tracker also sent to mailing list?
On Thu, Apr 22, 2010 at 9:44 AM, Kraai, Matt wrote: > I’ve submitted two trivial patches against QEMU in its bug tracker: > > https://bugs.launchpad.net/qemu/+bug/568053 > https://bugs.launchpad.net/qemu/+bug/568442 > > Is this sufficient or should I also submit them to the mailing list? Anthony has said that he can only accept patches sent to the mailing list, with a Signed-off-by line. Patches can land in Launchpad for discussion within the bug report, but he really must have the patches on the mailing list in order to be accepted upstream. :-Dustin
[Qemu-devel] qemu-kvm-0.11 regression, crashes on older guests with virtio network
I believe that we have identified a regression in qemu-kvm-0.11.0. The kvm process crashes for older guests with virtio networking, when the guest's incoming network connection is saturated. The subject guest is Ubuntu 8.04 Hardy, 2.6.24 kernel with virtio backports. For your convenience, I have uploaded a stock, ~260MB Ubuntu 8.04 disk image (user/pw = ubuntu) that I'm using to reproduce the problem at: * http://rookery.canonical.com/~kirkland/hardy.img.bz2 The command line is: * sudo /usr/bin/kvm -m 512 -net nic,model=virtio -net tap,script=/home/kirkland/bin/bridge.sh -drive file=hardy.img,if=virtio,index=0,boot=on The bridge script is: * http://rookery.canonical.com/~kirkland/bridge.sh I'm saturating the guest's incoming network connection, with: u...@guest$ nc -lp 1234 > /dev/null and u...@host$ cat /dev/urandom | nc -w 3 guest_ip 1234 In less than a second of sending, the vm crashes with: virtio-net truncating packet I have strace logs, if that's helpful. I have not reproduced the problem: a) by saturating the guest's outgoing network b) with newer guests ( >= 2.6.27 ) c) on kvm-84 on the host We're tracking this issue at: * https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/458521 I'll gladly review and test patches, or take pointers on where I might look to solve this issue. -- :-Dustin
[Qemu-devel] Re: qemu-kvm-0.11 regression, crashes on older guests with virtio network
On Wed, Oct 28, 2009 at 2:22 PM, Dustin Kirkland wrote: > I have not reproduced the problem: > a) by saturating the guest's outgoing network > b) with newer guests ( >= 2.6.27 ) > c) on kvm-84 on the host d) or by using e1000, or rtl8139 NIC models. :-Dustin
Re: [Qemu-devel] qemu-kvm-0.11 regression, crashes on older guests with virtio network
On Thu, 2009-10-29 at 14:25 +, Mark McLoughlin wrote: > On Thu, 2009-10-29 at 09:11 -0500, Anthony Liguori wrote: > > Mark McLoughlin wrote: > > > > > >> tap_set_offload(csum: 1, tso4: 1, tso6: 1, ecn: 1) > > >> being called and get an mtu of 1500 on virbr0 using his birdge.sh script. > > >> > > >> virtio_net_receive2 was trying to transfer a 1534 byte packet (1524 > > >> 'size' + 10 'virtio_net_hdr') > > >> and the guest only had 1524 bytes of space in its input descriptors. > > >> > > > > > > Okay, that sounds like a bug in Dustin's version of the guest virtio-net > > > driver - if it is only supplying 1524 byte buffers, it should not be > > > saying it supports the VIRTIO_NET_F_GUEST_TSO4 feature > > > > > > > See: > > > > commit 8eca6b1bc770982595db2f7207c65051572436cb > > Author: aliguori > > Date: Sun Apr 5 17:40:08 2009 + > > > > Fix oops on 2.6.25 guest (Rusty Russell) > > > > I believe this is behind the following: > > https://bugs.edge.launchpad.net/ubuntu/jaunty/+source/linux/+bug/331128 > > > > virtio_pci in 2.6.25 didn't do feature negotiation correctly: it > > acked every > > bit. Fortunately, we can detect this. > > > > Signed-off-by: Rusty Russell > > Signed-off-by: Anthony Liguori > > > > It looks like Rusty's fix wasn't enough. If I change virtio-net to only > > advertise F_MAC, we don't run into this problem. > > If it's not acking VBAD_FEATURE, then it doesn't sound like the same > issue > > It's also not acking e.g. MRG_RXBUF, which suggests that it is > selectively acking features, and choosing to ack TSO4 > > A quick look through the guest driver code should clear up the > confusion. Dustion, got a pointer? Hi Mark, I'm currently testing Scott's patch above. In the mean time, Hardy's kernel is in git here: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=summary Thanks, :-Dustin signature.asc Description: This is a digitally signed message part
Re: [Qemu-devel] qemu-kvm-0.11 regression, crashes on older guests with virtio network
On Thu, 2009-10-29 at 20:00 +0800, Scott Tsai wrote: > Excerpts from Mark McLoughlin's message of Thu Oct 29 17:16:43 +0800 2009: > > Assuming this is something like the virtio-net in 2.6.26, there was no > > receivable buffers support so (as Scott points out) it must be that > > we've read a packet from the tap device which is >1514 bytes (or >1524 > > bytes with IFF_VNET_HDR) but the guest has not supplied buffers which > > are large enough to take it > > > One thing to check is that the tap device is being initialized by > > qemu-kvm using TUNSETOFFLOAD with either zero or TUN_F_CSUM - i.e. GSO > > should not be enabled, because the guest cannot handle large GSO packets > > > Another possibility is that the MTU on the bridge in the host is too > > large and that's what's causing the large packets to be sent > > Using Dustin's image, I see: > virtio_net_set_features(features: 0x0930) > tap_set_offload(csum: 1, tso4: 1, tso6: 1, ecn: 1) > being called and get an mtu of 1500 on virbr0 using his birdge.sh script. > > virtio_net_receive2 was trying to transfer a 1534 byte packet (1524 'size' + > 10 'virtio_net_hdr') > and the guest only had 1524 bytes of space in its input descriptors. > > BTW, I can also reproduce this running Dustin's image inside Fedora 11's > qemu-0.10.6-9.fc11.x86_64. > > The patch I posted earlier actually only applies to the 0.10 branch, here's a > patch that compiles for 0.11: Hi Scott, Thanks for this. Testing this, kvm doesn't crash. And the guest has working network connectivity, until I saturate the network connection with nc. At that point, the guest loses network connectivity all together. So the fix is not quite ideal, yet. :-Dustin signature.asc Description: This is a digitally signed message part
Re: [Qemu-devel] qemu-kvm-0.11 regression, crashes on older guests with virtio network
On Thu, 2009-10-29 at 09:16 +, Mark McLoughlin wrote:
> Hi Dustin,
>
> On Wed, 2009-10-28 at 14:22 -0500, Dustin Kirkland wrote:
> > I believe that we have identified a regression in qemu-kvm-0.11.0.
>
> Regression versus which previous version of qemu-kvm?
Okay, sorry for the ambiguity. I actually had to clarify this for
myself. The regression is as compared to the kvm-84 package that the
previous version of Ubuntu (9.04 Jaunty) carried.
In this package, we carried the attached patch from Anthony Liguori.
I had incorrectly assumed that this patch made it into the upstream
tree. As Anthony stated in his earlier email, a different
implementation of the fix from Rusty was committed instead. The fix as
committed doesn't quite solve the problem as we're experiencing it.
:-Dustin
Work around broken virtio drivers in 2.6.26
Signed-off-by: Anthony Liguori
diff --git a/qemu/hw/virtio-net.c b/qemu/hw/virtio-net.c
index 9bce3a0..5b615f9 100644
--- a/qemu/hw/virtio-net.c
+++ b/qemu/hw/virtio-net.c
@@ -120,6 +120,9 @@ static uint32_t virtio_net_get_features(VirtIODevice *vdev)
if (tap_has_vnet_hdr(host)) {
tap_using_vnet_hdr(host, 1);
+#if 0
+/* Stop advertising advanced features until we work around the fact
+ * that this is totally broken in 2.6.26 kernels */
features |= (1 << VIRTIO_NET_F_CSUM);
features |= (1 << VIRTIO_NET_F_GUEST_CSUM);
features |= (1 << VIRTIO_NET_F_GUEST_TSO4);
@@ -130,6 +133,7 @@ static uint32_t virtio_net_get_features(VirtIODevice *vdev)
features |= (1 << VIRTIO_NET_F_HOST_ECN);
features |= (1 << VIRTIO_NET_F_MRG_RXBUF);
/* Kernel can't actually handle UFO in software currently. */
+#endif
}
#endif
@@ -374,8 +378,14 @@ static int receive_header(VirtIONet *n, struct iovec *iov, int iovcnt,
struct virtio_net_hdr *hdr = iov[0].iov_base;
int offset = 0;
+#if 0
hdr->flags = 0;
hdr->gso_type = VIRTIO_NET_HDR_GSO_NONE;
+#else
+/* we need to clear out the whole header, including any garbage that may be
+ */
+memset(hdr, 0, sizeof(*hdr));
+#endif
#ifdef TAP_VNET_HDR
if (tap_has_vnet_hdr(n->vc->vlan->first_client)) {
signature.asc
Description: This is a digitally signed message part
Re: [Qemu-devel] qemu-kvm-0.11 regression, crashes on older guests with virtio network
On Thu, 2009-10-29 at 09:34 -0500, Dustin Kirkland wrote: > In the mean time, Hardy's kernel is in git here: > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=summary I'll save you a few clicks... http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=blob;f=drivers/net/virtio_net.c;h=d1a200ff5fd266c05e9a876e5e4e550737f77d84;hb=HEAD :-dustin signature.asc Description: This is a digitally signed message part
Re: [Qemu-devel] qemu-kvm-0.11 regression, crashes on older guests with virtio network
On Thu, 2009-10-29 at 14:48 +, Mark McLoughlin wrote: > Ah, it all makes sense now. > > I was getting confused between HOST_* and GUEST_* > > this should have been: > > features |= (1 << VIRTIO_NET_F_MAC); > features |= (1 << VIRTIO_NET_F_HOST_CSUM); > features |= (1 << VIRTIO_NET_F_HOST_TSO4); > features |= (1 << VIRTIO_NET_F_HOST_TSO6); > features |= (1 << VIRTIO_NET_F_HOST_ECN); > > Could you try that Dustin? Hmm, not sure I'm doing this correctly... I tried changing the following, but looks like I might also have to define these as well, since: /tmp/qemu-kvm/qemu-kvm/hw/virtio-net.c:167: error: ‘VIRTIO_NET_F_HOST_CSUM’ undeclared (first use in this function) diff --git a/hw/virtio-net.c b/hw/virtio-net.c index ce8e6cb..6582e69 100644 --- a/hw/virtio-net.c +++ b/hw/virtio-net.c @@ -164,10 +164,10 @@ static uint32_t virtio_net_bad_features(VirtIODevice *vdev) /* Linux kernel 2.6.25. It understood MAC (as everyone must), * but also these: */ features |= (1 << VIRTIO_NET_F_MAC); -features |= (1 << VIRTIO_NET_F_GUEST_CSUM); -features |= (1 << VIRTIO_NET_F_GUEST_TSO4); -features |= (1 << VIRTIO_NET_F_GUEST_TSO6); -features |= (1 << VIRTIO_NET_F_GUEST_ECN); +features |= (1 << VIRTIO_NET_F_HOST_CSUM); +features |= (1 << VIRTIO_NET_F_HOST_TSO4); +features |= (1 << VIRTIO_NET_F_HOST_TSO6); +features |= (1 << VIRTIO_NET_F_HOST_ECN); return features & virtio_net_get_features(vdev); } signature.asc Description: This is a digitally signed message part
Re: [Qemu-devel] qemu-kvm-0.11 regression, crashes on older guests with virtio network
On Thu, 2009-10-29 at 15:01 +, Mark McLoughlin wrote: > Sorry, should be VIRTIO_NET_F_CSUM ... the rest is correct Brilliant! Works like a champ. I'll send a patch in a subsequent email. Would you add a signed-off-by (or whatever), Mark? :-Dustin signature.asc Description: This is a digitally signed message part
[Qemu-devel] [PATCH] whitelist host virtio networking features [was Re: qemu-kvm-0.11 regression, crashes on older ...]
whitelist host virtio networking features This patch is a followup to 8eca6b1bc770982595db2f7207c65051572436cb, fixing crashes when guests with 2.6.25 virtio drivers have saturated virtio network connections. https://bugs.edge.launchpad.net/ubuntu/+source/qemu-kvm/+bug/458521 That patch should have been whitelisting *_HOST_* rather than the the *_GUEST_* features. I tested this by running an Ubuntu 8.04 Hardy guest (2.6.24 kernel + 2.6.25-virtio driver). I saturated both the incoming, and outgoing network connection with nc, seeing sustained 6MB/s up and 6MB/s down bitrates for ~20 minutes. Previously, this crashed immediately. Now, the guest does not crash and maintains network connectivity throughout the test. Signed-off-by: Dustin Kirkland Signed-off-by: Mark McLoughlin Tested-by: Dustin Kirkland diff --git a/hw/virtio-net.c b/hw/virtio-net.c index ce8e6cb..27834fa 100644 --- a/hw/virtio-net.c +++ b/hw/virtio-net.c @@ -164,10 +164,10 @@ static uint32_t virtio_net_bad_features(VirtIODevice *vdev) /* Linux kernel 2.6.25. It understood MAC (as everyone must), * but also these: */ features |= (1 << VIRTIO_NET_F_MAC); -features |= (1 << VIRTIO_NET_F_GUEST_CSUM); -features |= (1 << VIRTIO_NET_F_GUEST_TSO4); -features |= (1 << VIRTIO_NET_F_GUEST_TSO6); -features |= (1 << VIRTIO_NET_F_GUEST_ECN); +features |= (1 << VIRTIO_NET_F_CSUM); +features |= (1 << VIRTIO_NET_F_HOST_TSO4); +features |= (1 << VIRTIO_NET_F_HOST_TSO6); +features |= (1 << VIRTIO_NET_F_HOST_ECN); return features & virtio_net_get_features(vdev); } signature.asc Description: This is a digitally signed message part
Ubuntu Patches [was Re: [Qemu-devel] qemu-kvm-0.11 regression, crashes on older guests with virtio network]
On Thu, Oct 29, 2009 at 6:22 PM, Scott Tsai wrote: > What's the easiest way to see the patches to qemu that Canonical > carries for the different Ubuntu releases? > (I think http://patches.ubuntu.com/ only diffs against Debian for the > last stable Ubuntu release?) Correct. That site is sort of intended to show where Ubuntu's packages differ from Debian. I've spoken with the person behind that site (Jorge Castro) and he offered to see what could be done to make it more useful to upstream projects. You can direct your suggestions to him. However, all of our packages are now maintained in Bazaar in Launchpad. You can (a) checkout the source of the package using bzr, and going to the debian/patches directory. Or you can (b) browse the source code over http using Loggerhead (sort of like gitweb for bzr). (a) bzr checkout lp:ubuntu/qemu-kvm/karmic (b) https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/karmic/qemu-kvm/karmic/files/head%3A/debian/patches/ Very soon, you'll probably be more interested in "lucid" than "karmic", very soon. In which case, s/karmic/lucid/ against those URLs. > Also, is there a way for an outside developer to get email > notifications when a patch is added to Ubuntu's qemu package? Sort of... You can subscribe for email notifications to changes to any given package in Launchpad. Assuming you have a Launchpad account, you can log in and go to: * https://code.launchpad.net/~ubuntu-branches/ubuntu/karmic/qemu-kvm/karmic To the right, there's a link to "Subscribe yourself". You'll get email to changes to that package in the given release (karmic, in this case, so modify the url accordingly). You might have to ignore some packaging changes, as some changes don't necessarily touch the core qemu-kvm code, for instance. :-Dustin
[Qemu-devel] Re: [PATCH] whitelist host virtio networking features [was Re: qemu-kvm-0.11 regression, crashes on older ...]
On Thu, Oct 29, 2009 at 10:34 AM, Dustin Kirkland wrote: > whitelist host virtio networking features > > This patch is a followup to 8eca6b1bc770982595db2f7207c65051572436cb, > fixing crashes when guests with 2.6.25 virtio drivers have saturated > virtio network connections. > > https://bugs.edge.launchpad.net/ubuntu/+source/qemu-kvm/+bug/458521 > > That patch should have been whitelisting *_HOST_* rather than the the > *_GUEST_* features. > > I tested this by running an Ubuntu 8.04 Hardy guest (2.6.24 kernel + > 2.6.25-virtio driver). I saturated both the incoming, and outgoing > network connection with nc, seeing sustained 6MB/s up and 6MB/s down > bitrates for ~20 minutes. Previously, this crashed immediately. Now, > the guest does not crash and maintains network connectivity throughout > the test. FYI... Canonical's Ubuntu Security Team will be filing a CVE on this issue, since there is a bit of an attack vector here, and since qemu-kvm-0.11.0 is generally available as an official release (and now part of Ubuntu 9.10). Guests running linux <= 2.6.25 virtio-net (e.g Ubuntu 8.04 hardy) on top of qemu-kvm-0.11.0 can be remotely crashed by a non-privileged network user flooding an open port on the guest. The crash happens in a manner that abruptly terminates the guest's execution (ie, without shutting down cleanly). This may affect the guest filesystem's general happiness. :-Dustin
[Qemu-devel] Re: [PATCH] whitelist host virtio networking features [was Re: qemu-kvm-0.11 regression, crashes on older ...]
On Mon, Nov 2, 2009 at 8:38 AM, Mark McLoughlin wrote: > On Fri, 2009-10-30 at 16:15 -0500, Dustin Kirkland wrote: >> Canonical's Ubuntu Security Team will be filing a CVE on this issue, >> since there is a bit of an attack vector here, and since >> qemu-kvm-0.11.0 is generally available as an official release (and now >> part of Ubuntu 9.10). >> >> Guests running linux <= 2.6.25 virtio-net (e.g Ubuntu 8.04 hardy) on >> top of qemu-kvm-0.11.0 can be remotely crashed by a non-privileged >> network user flooding an open port on the guest. The crash happens in >> a manner that abruptly terminates the guest's execution (ie, without >> shutting down cleanly). This may affect the guest filesystem's >> general happiness. > > IMHO, the CVE should be against the 2.6.25 virtio drivers - the bug is > in the guest and the issue we're discussing here is just a hacky > workaround for the guest bug. Kees/Jamie/Marc- I think Mark has a good point. This bug has two parts. Ultimately, it's triggered by a buggy virtio-net implementation in the Ubuntu 8.04 kernel (as well as any others using the circa 2.6.25 virtio net code). The CVE should probably mention (or focus on) this too. The qemu-kvm patch is still a good thing to do, as it shouldn't just exit and terminate the VM, so that's needed as well. :-Dustin
Re: [Qemu-devel] Re: [PATCH] whitelist host virtio networking features [was Re: qemu-kvm-0.11 regression, crashes on older ...]
On Mon, 2009-11-02 at 12:55 -0600, Anthony Liguori wrote: > They can exit qemu via an ACPI shutdown. I don't see the difference. An ACPI shutdown is triggered by an authenticated user inside of the guest. The present exit is triggered by any other anonymous user on the network, with the ability to send a lot of packets very quickly to the VM guest. The guest isn't able to handle this properly (and rightly that guest's kernel should be fixed). But I do see a difference. :-Dustin signature.asc Description: This is a digitally signed message part
[Qemu-devel] Re: [PATCH 0/4] net-bridge: rootless bridge support for qemu
On Tue, 2009-11-03 at 18:28 -0600, Anthony Liguori wrote: > This series solves a problem that I've been struggling with for a few years > now. > One of the best things about qemu is that it's possible to run guests as an > unprivileged user to improve security. However, if you want to have your > guests > communicate with the outside world, you're pretty much forced to run qemu as > root. > > At least with KVM support, this is probably the most common use case which > means > that most of our users are running qemu as root. That's terrible. Ack. > We address this problem by introducing a new network backend: -net bridge. > This > backend is less flexible than -net tap because it relies on a helper with > elevated privileges to do the heavy lifting of allocating and attaching a tap > device to a bridge. We use a special purpose helper because we don't want > to elevate the privileges of more generic tools like brctl. > > From a user perspective, to use bridged networking with a guest, you simply > use: > > qemu -hda linux.img -net bridge -net nic I know that this patch is less than a day old and untested, but would it be reasonable to make this the "default" network configuration at some point in the future? This certainly seems to be what I want 99% of the time when I launch qemu or kvm by hand from the command line. > And assuming a bridge is defined named qemubr0 and the administrator has setup > permissions accordingly, it will Just Work. My hope is that distributions > will > do this work as part of the qemu packaging process such that for most users, > the out-of-the-box experience will also Just Work. Also, ack. I'll handle the Ubuntu packaging to enable this support in Lucid by the time qemu-0.12-rc1 is available. As Alexander mentions, there's a bit more complexity we'll need to account for (wifi, network manager, multiple nic's). :-Dustin signature.asc Description: This is a digitally signed message part
Re: [Qemu-devel] Re: [PATCH 0/4] net-bridge: rootless bridge support for qemu
On Wed, 2009-11-04 at 18:52 -0600, Anthony Liguori wrote: > I'd rather make the "default" network configurable via a global > configuration file. That way, if a distribution knew that it had a > bridge setup for its users, it could make -net bridge the default. Fair enough. :-Dustin signature.asc Description: This is a digitally signed message part
