- Devel - libvirt List Archives

[libvirt] [PATCH v2] qemu: Use virtio network device for aarch64/virt
by Oleg Strikov 19 Feb '14

19 Feb '14

This patch changes network device type used by default from rtl8139 to virtio when architecture type is aarch64 and machine type is virt. Qemu doesn't support any other machine types for aarch64 right now and we can't make any other aarch64-specific tuning in this function yet. Signed-off-by: Oleg Strikov <oleg.strikov(a)canonical.com> --- Changes since v1: * qemuxml2argvtest suite has been extended to validate correct setup for aarch64 guests when no NIC model is provided in the XML src/qemu/qemu_domain.c | 3 ++- .../qemuxml2argv-aarch64-virt-default-nic.args | 6 ++++++ .../qemuxml2argv-aarch64-virt-default-nic.xml | 22 ++++++++++++++++++++ tests/qemuxml2argvtest.c | 3 +++ 4 files changed, 33 insertions(+), 1 deletion(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-aarch64-virt-default-nic.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-aarch64-virt-default-nic.xml diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index a665061..9a040ee 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -797,7 +797,8 @@ qemuDomainDefaultNetModel(const virDomainDef *def) def->os.arch == VIR_ARCH_S390X) return "virtio"; - if (def->os.arch == VIR_ARCH_ARMV7L) { + if (def->os.arch == VIR_ARCH_ARMV7L || + def->os.arch == VIR_ARCH_AARCH64) { if (STREQ(def->os.machine, "versatilepb")) return "smc91c111"; diff --git a/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virt-default-nic.args b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virt-default-nic.args new file mode 100644 index 0000000..d4d403b --- /dev/null +++ b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virt-default-nic.args @@ -0,0 +1,6 @@ +LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test QEMU_AUDIO_DRV=none \ +/usr/bin/qemu-system-aarch64 -S -M virt -m 1024 -smp 1 -nographic \ +-nodefconfig -nodefaults -monitor unix:/tmp/test-monitor,server,nowait \ +-boot c -kernel /aarch64.kernel -initrd /aarch64.initrd -append console=ttyAMA0 \ +-usb -device virtio-net-device,vlan=0,id=net0,mac=52:54:00:09:a4:37 \ +-net user,vlan=0,name=hostnet0 diff --git a/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virt-default-nic.xml b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virt-default-nic.xml new file mode 100644 index 0000000..868de94 --- /dev/null +++ b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virt-default-nic.xml @@ -0,0 +1,22 @@ +<domain type="qemu"> + <name>aarch64-virt-default-nic</name> + <uuid>6ba410c5-1e5c-4d57-bee7-2228e7ffa32f</uuid> + <memory>1048576</memory> + <currentMemory>1048576</currentMemory> + <vcpu>1</vcpu> + <features> + <acpi/> + </features> + <os> + <type arch="aarch64" machine="virt">hvm</type> + <kernel>/aarch64.kernel</kernel> + <initrd>/aarch64.initrd</initrd> + <cmdline>console=ttyAMA0</cmdline> + </os> + <devices> + <emulator>/usr/bin/qemu-system-aarch64</emulator> + <interface type='user'> + <mac address='52:54:00:09:a4:37'/> + </interface> + </devices> +</domain> diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c index 7a5b50d..43ac1d1 100644 --- a/tests/qemuxml2argvtest.c +++ b/tests/qemuxml2argvtest.c @@ -1335,6 +1335,9 @@ mymain(void) QEMU_CAPS_DEVICE, QEMU_CAPS_NODEFCONFIG, QEMU_CAPS_DTB, QEMU_CAPS_DRIVE, QEMU_CAPS_DEVICE_VIRTIO_MMIO, QEMU_CAPS_DEVICE_VIRTIO_RNG, QEMU_CAPS_OBJECT_RNG_RANDOM); + DO_TEST("aarch64-virt-default-nic", + QEMU_CAPS_DEVICE, QEMU_CAPS_NODEFCONFIG, + QEMU_CAPS_DEVICE_VIRTIO_MMIO); DO_TEST("kvm-pit-device", QEMU_CAPS_KVM_PIT_TICK_POLICY); DO_TEST("kvm-pit-delay", QEMU_CAPS_NO_KVM_PIT); -- 1.7.9.5

2 1

[libvirt] [PATCH] networkRunHook: Run hook only if possible
by Michal Privoznik 19 Feb '14

19 Feb '14

Currently, networkRunHook() is called in networkAllocateActualDevice and friends. These functions, however, doesn't necessarily work on networks, For example, if domain's interface is defined in this fashion: <interface type='bridge'> <mac address='52:54:00:0b:3b:16'/> <source bridge='virbr1'/> <model type='rtl8139'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> </interface> The networkAllocateActualDevice jumps directly onto 'validate' label as the interface is not type of 'network'. Hence, @network is left initialized to NULL and networkRunHook(network, ...) is called. One of the things that the hook function does is dereference @network. Soupir. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/network/bridge_driver.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c index ee264b9..a6c719d 100644 --- a/src/network/bridge_driver.c +++ b/src/network/bridge_driver.c @@ -150,6 +150,12 @@ networkRunHook(virNetworkObjPtr network, int ret = -1; if (virHookPresent(VIR_HOOK_DRIVER_NETWORK)) { + if (!network) { + VIR_DEBUG("Not running hook as @network is NULL"); + ret = 0; + goto cleanup; + } + virBufferAddLit(&buf, "<hookData>\n"); virBufferAdjustIndent(&buf, 2); if (virNetworkDefFormatBuf(&buf, network->def, 0) < 0) -- 1.9.0

2 1

[libvirt] Is it possible to set a timeout to the Connection class?
by Pasquale Dir 19 Feb '14

19 Feb '14

I am using the java api bindings. I'd like to set a connection timeout on the Connect class as sometimes it takes just too long. Is there any way/workaround?

4 5

Re: [libvirt] Is it possible to set a timeout to the Connection class?
by Claudio Bley 19 Feb '14

19 Feb '14

[please, don't top-post on technical lists and keep the conversation on list] At Wed, 19 Feb 2014 11:59:29 +0100, Pasquale Dir wrote: > > Thank you I didn't think about the Future, I'll try it and if it doesn't > work I'll just try to edit the tcp connection timeout file. > Can you answer me to the other question too, please? > > << what new apis are you talking about? I am doing migration by executing > the Domain.migrate function in a separate thread and obtaining progress by > DomainJobInfo class. Did you introduce some new api who automatically does > this? I can't find it here http://libvirt.org/sources/java/javadoc/ >> Eric was talking about the block-pull API functions, like virDomainBlockPull[1] which was added to libvirt in version 0.9.4. These functions have not been wrapped in libvirt-java, yet. (Patches welcome!) As Eric pointed out, there is curently no equivalent async _migration_ function in libvirt. Claudio [1]: http://libvirt.org/html/libvirt-libvirt.html#virDomainBlockPull

1 0

[libvirt] LSN-2013-0018: Unsafe usage of paths under /proc/$PID/root by the LXC driver
by Daniel P. Berrange 19 Feb '14

19 Feb '14

Libvirt Security Notice: LSN-2013-0018 ====================================== Summary: Unsafe usage of paths under /proc/$PID/root by the LXC driver Reported on: 20131217 Published on: 20131217 Fixed on: 20140219 Reported by: Reco <recoverym4n(a)gmail.com> Patched by: Reco <recoverym4n(a)gmail.com>, Eric Blake <eblake(a)redhat.com>, Daniel Berrange <berrange(a)redhat.com> See also: CVE-2013-6456, debian bug #732394 Description ----------- The LXC driver will open paths under /proc/$PID/root for some operations it performs on running guests. For the virDomainShutdown and virDomainReboot APIs it will use this to access the /dev/initctl path in the container. For the virDomainDeviceAttach / virDomainDeviceDettach APIs it will use this to create device nodes in the container's /dev filesystem. If any of the path components under control of the container are symlinks the container can cause the libvirtd daemon to access the incorrect files. Impact ------ A container can cause the administrator to shutdown or reboot the host OS if /dev/initctl in the container is made to be an absolute symlink back to itself or /run/initctl. A container can cause the host administrator to mknod in an arbitrary host directory when invoking the virDomainDeviceAttach API by replacing '/dev' with an absolute symlink. A container can cause the host administrator to delete host device when invoking the virDomainDeviceDettach API by replacing '/dev' with an absolute symlink. Workaround ---------- Do not use the virDomainShutdown or virDomainReboot APIs without also passing the VIR_DOMAIN_SHUTDOWN_SIGNAL or VIR_DOMAIN_REBOOT_SIGNAL flags respectively. These will cause the LXC driver to send a SIGTERM or SIGHUP signal respectively, to the init process instead of using /dev/initct.. Do not use the virDomainDeviceAttach or virDomainDeviceDetach APIs at all unless the guest OS is trusted. Affected product ---------------- Name: libvirt Repository: git://libvirt.org/git/libvirt.git http://libvirt.org/git/?p=libvirt.git Branch: master Broken in: v1.0.1 Broken in: v1.0.2 Broken in: v1.0.3 Broken in: v1.0.4 Broken in: v1.0.5 Broken in: v1.0.6 Broken in: v1.0.0 Broken in: v1.1.1 Broken in: v1.1.2 Broken in: v1.1.3 Broken in: v1.1.4 Broken in: v1.2.0 Broken in: v1.2.1 Broken by: cbb106f807b32f1f6af22d1e92fe0ff9ba6d73b3 Broken by: de858e3fa7ffcab5f80d07f8a74d94cbaf8716b9 Broken by: ed77abc58bc5a6837a5021f26e1a335dbfb477bf Broken by: a5efb3190913b6903775ca3756f79443d4ea8a5b Broken by: 4ad6a013304f6fe29b0866742c902054bfbcf23f Fixed by: aebbcdd33c8c18891f0bdbbf8924599a28152c9c Fixed by: 4dd3a7d5bc44980135a1b11810ba9aeab42a4a59 Fixed by: 7fba01c15c1f886b4235825692b4c13e88dd9f7b Fixed by: 1754c7f0ab1407dcf7c89636a35711dd9b1febe1 Fixed by: 1cadeafcaa422844a27ef622e2a7041d0235bcb3 Fixed by: 5fc590ad9f4071350a8df4d567ba88baacc8334d Branch: v1.0.1-maint Broken by: cbb106f807b32f1f6af22d1e92fe0ff9ba6d73b3 Branch: v1.0.2-maint Broken by: cbb106f807b32f1f6af22d1e92fe0ff9ba6d73b3 Broken by: de858e3fa7ffcab5f80d07f8a74d94cbaf8716b9 Broken by: ed77abc58bc5a6837a5021f26e1a335dbfb477bf Broken by: a5efb3190913b6903775ca3756f79443d4ea8a5b Broken by: 4ad6a013304f6fe29b0866742c902054bfbcf23f Branch: v1.0.3-maint Broken by: cbb106f807b32f1f6af22d1e92fe0ff9ba6d73b3 Broken by: de858e3fa7ffcab5f80d07f8a74d94cbaf8716b9 Broken by: ed77abc58bc5a6837a5021f26e1a335dbfb477bf Broken by: a5efb3190913b6903775ca3756f79443d4ea8a5b Broken by: 4ad6a013304f6fe29b0866742c902054bfbcf23f Branch: v1.0.4-maint Broken by: cbb106f807b32f1f6af22d1e92fe0ff9ba6d73b3 Broken by: de858e3fa7ffcab5f80d07f8a74d94cbaf8716b9 Broken by: ed77abc58bc5a6837a5021f26e1a335dbfb477bf Broken by: a5efb3190913b6903775ca3756f79443d4ea8a5b Broken by: 4ad6a013304f6fe29b0866742c902054bfbcf23f Branch: v1.0.5-maint Broken in: v1.0.5.1 Broken in: v1.0.5.2 Broken in: v1.0.5.3 Broken in: v1.0.5.4 Broken in: v1.0.5.5 Broken in: v1.0.5.6 Broken in: v1.0.5.7 Broken in: v1.0.5.8 Broken in: v1.0.5.9 Broken by: cbb106f807b32f1f6af22d1e92fe0ff9ba6d73b3 Broken by: de858e3fa7ffcab5f80d07f8a74d94cbaf8716b9 Broken by: ed77abc58bc5a6837a5021f26e1a335dbfb477bf Broken by: a5efb3190913b6903775ca3756f79443d4ea8a5b Broken by: 4ad6a013304f6fe29b0866742c902054bfbcf23f Fixed by: f84056cf6166332b1f15f3e6584a88f5d42273fe Fixed by: 0e9fee68b3bff24e4d3ab48de8129946202f3bc0 Fixed by: 9849cf6d89e5665667a0df449ddc3fd5582da242 Fixed by: 21821ed4d1faf5bf563a26e8ac7cd2eb0450d322 Fixed by: e57058cfe827b1971ca0dee224ff273c9cad7756 Fixed by: e1e7e05376faf1ed471cb5c1d1e0415458f2af7d Branch: v1.0.6-maint Broken by: cbb106f807b32f1f6af22d1e92fe0ff9ba6d73b3 Broken by: de858e3fa7ffcab5f80d07f8a74d94cbaf8716b9 Broken by: ed77abc58bc5a6837a5021f26e1a335dbfb477bf Broken by: a5efb3190913b6903775ca3756f79443d4ea8a5b Broken by: 4ad6a013304f6fe29b0866742c902054bfbcf23f Fixed by: e9941eee1a3c1cb0af7bc39076eb0e8c2c4eb603 Fixed by: 84cf9af8d9a803f2e12df0b8b0c2bd2de544cf93 Fixed by: f8706947b86e6de2961aacddb5eb2345d9c033b4 Fixed by: 081e0fabfd8c0f5c3f2c869ddcf11710c445a962 Fixed by: b2a853e1f6aea9683a30eafd2b069b8be0fcf898 Fixed by: bd9ec4506e29a9ce682961eee99d0326ed64145d Branch: v1.1.0-maint Broken by: cbb106f807b32f1f6af22d1e92fe0ff9ba6d73b3 Broken by: de858e3fa7ffcab5f80d07f8a74d94cbaf8716b9 Broken by: ed77abc58bc5a6837a5021f26e1a335dbfb477bf Broken by: a5efb3190913b6903775ca3756f79443d4ea8a5b Broken by: 4ad6a013304f6fe29b0866742c902054bfbcf23f Fixed by: 61c7e0b66e8b37d4ea64024c100d2ed467d5cb47 Fixed by: 43720035b7f4c175ef2594296d874bc1910840b3 Fixed by: 212414281f0001da78f2312d7f52dcf124317fc9 Fixed by: c17dd7ede2affd147ffdc5e8daef85939bda0dd0 Fixed by: ed46a680a02cf96b229a89f74ddbab69522c9ef5 Fixed by: 807db4a30ee903f973d496b3293d9e6aaa511174 Branch: v1.1.1-maint Broken by: cbb106f807b32f1f6af22d1e92fe0ff9ba6d73b3 Broken by: de858e3fa7ffcab5f80d07f8a74d94cbaf8716b9 Broken by: ed77abc58bc5a6837a5021f26e1a335dbfb477bf Broken by: a5efb3190913b6903775ca3756f79443d4ea8a5b Broken by: 4ad6a013304f6fe29b0866742c902054bfbcf23f Fixed by: 6ecb7bc3aed7f60edad5289c9b0cfcf99eee6611 Fixed by: 72a4c29ca72789b13de1ed9cb96df9fb2b0fdde4 Fixed by: 83f83508e128275bd1b74988162dc6b9f86e00ee Fixed by: 398c88edfaef50b9b59eb2d9a61b07c9c940a661 Fixed by: dd055960df60c536957664f0ae3c591feecf7b09 Fixed by: 14d69bd00e4455a1d174d14c5af73975cf9e904a Branch: v1.1.2-maint Broken by: cbb106f807b32f1f6af22d1e92fe0ff9ba6d73b3 Broken by: de858e3fa7ffcab5f80d07f8a74d94cbaf8716b9 Broken by: ed77abc58bc5a6837a5021f26e1a335dbfb477bf Broken by: a5efb3190913b6903775ca3756f79443d4ea8a5b Broken by: 4ad6a013304f6fe29b0866742c902054bfbcf23f Fixed by: f639b2d17ce935b650bb2aca7bdd8d727cab8b02 Fixed by: a06bdfcb446f182e490f70422a8431c3bcb2c801 Fixed by: 77ddbad2a9272239a09673c5d6993793308514e9 Fixed by: a6e9270ec79924fabd5a872984bb5d38eaf3df8a Fixed by: eae2a2ada81c5828991bb1b9438f7556a7e51ce8 Fixed by: 21368274a9aa91e8a5f0addb3a6bba8dad91e334 Branch: v1.1.3-maint Broken in: v1.1.3.1 Broken in: v1.1.3.2 Broken in: v1.1.3.3 Fixed in: v1.1.3.4 Broken by: cbb106f807b32f1f6af22d1e92fe0ff9ba6d73b3 Broken by: de858e3fa7ffcab5f80d07f8a74d94cbaf8716b9 Broken by: ed77abc58bc5a6837a5021f26e1a335dbfb477bf Broken by: a5efb3190913b6903775ca3756f79443d4ea8a5b Broken by: 4ad6a013304f6fe29b0866742c902054bfbcf23f Fixed by: a3a3cfcb7c400bcde198b5b929ff2d4f889dee78 Fixed by: cb016b9ef1a6d786657a98546db8412f86510367 Fixed by: 72e379ed93b4707e26bbc5e3457a85833f50eb1a Fixed by: fcf05c194cb1cca6b5c703073b97ed1408a2c546 Fixed by: d5c0b57fffbe651c425b4de6c11712030cce7e7e Fixed by: fef343339127b989746214b86901553da6d17863 Branch: v1.1.4-maint Broken by: cbb106f807b32f1f6af22d1e92fe0ff9ba6d73b3 Broken by: de858e3fa7ffcab5f80d07f8a74d94cbaf8716b9 Broken by: ed77abc58bc5a6837a5021f26e1a335dbfb477bf Broken by: a5efb3190913b6903775ca3756f79443d4ea8a5b Broken by: 4ad6a013304f6fe29b0866742c902054bfbcf23f Fixed by: 28681077373f1fa567b7f56117a22047f90925fe Fixed by: 0e931dfcda308fbb84eef42bc92e257e39af083d Fixed by: 3101022b4d4fee46916b87b1c21a3956a91d94b2 Fixed by: 1d1daaf58677cfa843b6891a98dc6cdb42116434 Fixed by: 80f57ec4224af65392db09fb8f47be7434e2fc86 Fixed by: ba4065b6f64fca7706070b8458fdf0bc06115b9b Branch: v1.2.0-maint Broken by: cbb106f807b32f1f6af22d1e92fe0ff9ba6d73b3 Broken by: de858e3fa7ffcab5f80d07f8a74d94cbaf8716b9 Broken by: ed77abc58bc5a6837a5021f26e1a335dbfb477bf Broken by: a5efb3190913b6903775ca3756f79443d4ea8a5b Broken by: 4ad6a013304f6fe29b0866742c902054bfbcf23f Fixed by: 3e97a53caa9adddd47da1c22dbed81ef2e02f735 Fixed by: 17188260657e095f5d210bc73ba1661875a8f885 Fixed by: 70665ec5f2cd910666bc703727dc6d7c15efe7bf Fixed by: 3f43a7727ac068de8aac6b9c030b38fb3cb1426d Fixed by: cd48d62aca488a116b47073be2607653a1d3305e Fixed by: 8fca7a4fa6b40d21723008d2092536349f20517d Branch: v1.2.1-maint Broken by: cbb106f807b32f1f6af22d1e92fe0ff9ba6d73b3 Broken by: de858e3fa7ffcab5f80d07f8a74d94cbaf8716b9 Broken by: ed77abc58bc5a6837a5021f26e1a335dbfb477bf Broken by: a5efb3190913b6903775ca3756f79443d4ea8a5b Broken by: 4ad6a013304f6fe29b0866742c902054bfbcf23f Fixed by: 8b546028f901dc414463678574ceabbacc37c4cb Fixed by: b0ed2d94ace3c57198ce7b4793f906abf5397e36 Fixed by: ee1269eecd3566729f3909db624f7ebd7bf1b84a Fixed by: b9997828231b3492252cb6d9a0ad4f3dc522791e Fixed by: 51a897a22e1c031edd46fd077487a2f8e649cb9f Fixed by: ad52184399aa414fa3d7e2756e4ea6a45ec0d3a3 -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|

1 0

[libvirt] java api bindings for detecting domain events
by Avanti Ajay 19 Feb '14

19 Feb '14

Hi.. I am doing a project in which I need to detect KVM domain events and I am using java for my project. On the net I found many patches for the libvirt Java API bindings for event detection. Does the latest version 0.5 have these patches included ie can I use the method Domain.domainEventRegisterAny() directly. Also can u please tell me exactly how to use this method? Thank you Avanti

2 1

[libvirt] [bug-report] libvirtd 1.1.4-maint with lastest patches can't be connected
by Wangpan 19 Feb '14

19 Feb '14

Hi experts, Is there anybody could help me to fix this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1066801 my libvirt version is 1.1.4-manit without the newest patches after this one: 13 days ago Eric Blake event: move event filtering to daemon (regression fix) Description of problem: After I cherry-picked these patches of 1.1.4-maint branch(I want to fix the dead lock and a libvirtd crash bugs of libvirtd, https://bugzilla.redhat.com/show_bug.cgi?id=929412 https://bugzilla.redhat.com/show_bug.cgi?id=1058149) my libvirtd can be started, but the connection can't be established, and libvirtd failed to stop after 'service libvirt-bin stop', as well as 'ctrl+c' when I run 'libvirtd -v' on the foreground. Steps to Reproduce: 1. create many VMs(40 in my env) on the host 2. kill -9 `pid of libvirtd` 3. start libvirtd by using service libvirt-bin start 4. virsh list or virsh version Thanks a lot!

1 0

[libvirt] [PATCH v9 0/7] Support keyboard device
by Li Zhang 19 Feb '14

19 Feb '14

From: Li Zhang <zhlcindy(a)linux.vnet.ibm.com> This patchset is to add keyboard input device. For PPC64, it doesn't support a default keyboard device when the graphic is enabled. Libvirt supports QEMU command line as "-device VGA" which won't create any keyboard device for it. So it requires libvirt to add a default USB keyboard device for it. This patchset is to add keyboard input device and a default USB keyboard for PPC64. The related discussion in QEMU community: http://lists.nongnu.org/archive/html/qemu-devel/2013-11/msg01734.html Li Zhang (7): conf: Add one interface to add default input devices conf: Add a keyboard input device type conf: Remove the implicit PS2 devices for non-X86 platforms qemu_cap: Add USB keyboard capability qemu: format qemu command line for USB keyboard xen: format xen command line for USB keyboard Add a default USB keyboard and USB mouse for PPC64 v9 -> v8: * Move keyboard XML format to the first patch. (Jan Tomko) * Correct one logic error. (Jan Tomko) v8 -> v7: * Add USB keyboard output XML format when VIR_DOMAIN_XML_MIGRATABLE isn't set. (Daniel P. && Jan Tomko) * Fix test cases because of XML changes. v7 -> v6: * Corret indention errors in code. (Jan Tomko) * Correct make check error in xen driver. (Jan Tomko) * Split 5/6 to 2 parts, qemu and xen. (Jan Tomko) v6 -> v5: * Change kbd to keyboard, and correct -usbdevice parameter. * Remove implicit PS/2 keyboard output in XML in case older libvirtd can read it. (Jan Tomko) * Remove implicit keyboard for XEN to make it safer. v5 -> v4: * Add PS/2 KBD definition in XML file. (Daniel.P.Berrange) * Allow PS/2 KBD devices and set KBD default bus as PS2 for X86, USB for non-x86. (Daniel.P.Berrange) * Add an implicit PS/2 KBD as PS/2 mouse. (Danniel.P.Berrange) v4 -> v3: * Don't remove PS2 mouse device for other virtualization drivers (Jan Tomko). v3 -> v2: * Handle the KBD device type in xen and QEMU driver. (Daniel.P.Berrange) * Remove PS2 mouse device for non-X86 platforms. * Move virDomainDefMaybeAddInput to a new patch. (Jan Tomko) * Replace VIR_REALLOC_N with VIR_APPEND_ELEMENT. (Jan Tomoko) * Fix several typos. (Jan Tomoko) * Add a virReportError when QEMU_CAPS_DEVICE_USB_KBD can't be gotten. (Jan Tomoko) v2 -> v1: * change ifs to switch clause. * reconstruct the patches docs/schemas/domaincommon.rng | 1 + src/conf/domain_conf.c | 116 ++++++++++++++------- src/conf/domain_conf.h | 5 + src/libvirt_private.syms | 1 + src/qemu/qemu_capabilities.c | 3 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 41 ++++++-- src/qemu/qemu_domain.c | 23 +++- src/util/virarch.h | 2 + src/xenxs/xen_sxpr.c | 27 +++-- src/xenxs/xen_xm.c | 30 ++++-- tests/qemucapabilitiesdata/caps_1.2.2-1.caps | 1 + tests/qemucapabilitiesdata/caps_1.3.1-1.caps | 1 + tests/qemucapabilitiesdata/caps_1.4.2-1.caps | 1 + tests/qemucapabilitiesdata/caps_1.5.3-1.caps | 1 + tests/qemucapabilitiesdata/caps_1.6.0-1.caps | 1 + tests/qemucapabilitiesdata/caps_1.6.50-1.caps | 1 + tests/qemuhelptest.c | 8 ++ ...qemuhotplug-console-compat-2+console-virtio.xml | 1 + .../qemuxml2argv-console-compat-2.xml | 1 + .../qemuxml2argv-graphics-listen-network.xml | 1 + .../qemuxml2argv-graphics-listen-network2.xml | 1 + .../qemuxml2argv-graphics-sdl-fullscreen.xml | 1 + .../qemuxml2argvdata/qemuxml2argv-graphics-sdl.xml | 1 + .../qemuxml2argv-graphics-spice-compression.xml | 1 + .../qemuxml2argv-graphics-spice-qxl-vga.xml | 1 + .../qemuxml2argv-graphics-spice-timeout.xml | 2 + .../qemuxml2argv-graphics-spice.xml | 1 + .../qemuxml2argv-graphics-vnc-policy.xml | 1 + .../qemuxml2argv-graphics-vnc-sasl.xml | 1 + .../qemuxml2argv-graphics-vnc-socket.xml | 1 + .../qemuxml2argv-graphics-vnc-tls.xml | 1 + .../qemuxml2argv-graphics-vnc-websocket.xml | 1 + .../qemuxml2argvdata/qemuxml2argv-graphics-vnc.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-input-xen.xml | 1 + .../qemuxml2argv-net-bandwidth.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-pci-bridge.xml | 1 + .../qemuxml2argvdata/qemuxml2argv-pseries-disk.xml | 3 +- .../qemuxml2argv-pseries-usb-kbd.args | 9 ++ .../qemuxml2argv-pseries-usb-kbd.xml | 19 ++++ .../qemuxml2argv-serial-spiceport.xml | 1 + tests/qemuxml2argvtest.c | 3 + .../qemuxml2xmlout-graphics-listen-network2.xml | 1 + .../qemuxml2xmlout-graphics-spice-timeout.xml | 1 + tests/vmx2xmldata/vmx2xml-graphics-vnc.xml | 1 + 45 files changed, 256 insertions(+), 66 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-usb-kbd.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-usb-kbd.xml -- 1.8.2.1

2 18

[libvirt] [Question] Is it ok to occupy large amount of cache when save?
by Wangyufei (James) 19 Feb '14

19 Feb '14

Hello, When I call virDomainManagedSave, libvirtd will fork a child process libvirt_iohelper to write save file, and the system cache will increase soon just like this: Swap: 0M total, 0M used, 0M free, 1668M cached Swap: 0M total, 0M used, 0M free, 1715M cached But I have cgroup to control the memory of libvirtd below 50 M, so in this case, libvirt_iohelper will be killed, and virDomainManagedSave failed. So my question is: 1. Is it ok for libvirtd to occupy large amount of cache when save? Can we flush cache in time? 2. In my situation, is it any good idea to help me out? Increase the memory limit value? Pass through the cache? Flush cache? Or any one better? Which one do you preffer? Best Regards, -WangYufei

2 1

[libvirt] ANNOUNCE: libvirt 1.1.3.4 maintenance release
by Cole Robinson 19 Feb '14

19 Feb '14

libvirt 1.1.3.4 maintenance release is now available. This is libvirt 1.1.3 with additional bugfixes that have accumulated upstream since the initial release. This release can be downloaded at: http://libvirt.org/sources/stable_updates/libvirt-1.1.3.4.tar.gz Changes in this version: * CVE-2013-6456: Avoid unsafe use of /proc/$PID/root in LXC hotunplug code * CVE-2013-6456: Avoid unsafe use of /proc/$PID/root in LXC chardev hostdev hotplug * CVE-2013-6456: Avoid unsafe use of /proc/$PID/root in LXC block hostdev hotplug * CVE-2013-6456: Avoid unsafe use of /proc/$PID/root in LXC USB hotplug * CVE-2013-6456: Avoid unsafe use of /proc/$PID/root in LXC disk hotplug * CVE-2013-6456: Avoid unsafe use of /proc/$PID/root in LXC shutdown/reboot code * Add helper for running code in separate namespaces * Add virFileMakeParentPath helper function * Move check for cgroup devices ACL upfront in LXC hotplug * Disks are always block devices, never character devices * Fix reset of cgroup when detaching USB device from LXC guests * Record hotplugged USB device in LXC live guest config * Fix path used for USB device attach with LXC * Don't block use of USB with containers * storage: avoid short reads while chasing backing chain * event: move event filtering to daemon (regression fix) * Push nwfilter update locking up to top level * Add a read/write lock implementation * tests: Add more tests for virConnectBaselineCPU * cpu: Try to use source CPU model in virConnectBaselineCPU * cpu: Fix VIR_CONNECT_BASELINE_CPU_EXPAND_FEATURES * tests: Better support for VIR_CONNECT_BASELINE_CPU_EXPAND_FEATURES * qemu: Change the default unix monitor timeout For info about past maintenance releases, see: http://wiki.libvirt.org/page/Maintenance_Releases Thanks, Cole

1 0