Re: [libvirt] [PATCH] conf: Parse virtio-crypto in the domain XML
> > Sent: Monday, January 09, 2017 10:15 AM > To: libvir-list@redhat.com > Cc: Wubin (H); Zhoujian (jay, Euler); Gonglei (Arei); berra...@redhat.com; > longpeng > Subject: [PATCH] conf: Parse virtio-crypto in the domain XML > > As virtio-crypto has been supported in QEMU 2.9 and Take a quick glance: s/QEMU 2.9/QEMU 2.8/ > the frontend driver has been merged in linux 4.10, > so it's necessary to support virtio-crypto in domain > XML. > > This patch parse the domain XML with virtio-crypto > support, the virtio-crypto XML looks like this: > > > > > > Signed-off-by: Longpeng(Mike) <longpe...@huawei.com> > --- -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] Question about how to distinguish a usb device in usb pass-through feature
Hi, Qemu has supported 3rd method for USB passthrough except two ways that you have pointed: hostbus+hostport -- match for a specific physical port in the host, any device which is plugged in there gets passed to the guest. The method can resolve your all problems. AFAICT, libvirt do not support this way at present. Any Plan? CC'ing libvirt developer mailist. Best regards, -Gonglei From: qemu-devel-bounces+arei.gonglei=huawei@nongnu.org [mailto:qemu-devel-bounces+arei.gonglei=huawei@nongnu.org] On Behalf Of Yuanjing (D) Sent: Monday, June 09, 2014 11:37 AM To: qemu-de...@nongnu.org Cc: Liuji (Jeremy) Subject: [Qemu-devel] Question about how to distinguish a usb device in usb pass-through feature Hi, I want to provide feature that pass-through host's usb device to guest os in Openstack. I have question about how to distinguish a usb device. I have read some introductions and made some tests. I think qemu supports two ways to identify a host usb device: (1)host:bus.addr (2)host:vendor_id:product_id I think they both have restriction on some use cases: (1) 'host:bus.addr' is not appropriate if more than one usb devices with the same 'host:bus.addr' in a host. (2) The addr(device number) may change every time unplug/plug usb device of a host. One this happen the guest may reboot failed with wrong host:bus.addr. I noticed that Vmware supports technology 'autoconnection', they pass-through usb device by using usb path of the device on the host(physical topology and port location). Once unplug usb device and plug usb device again with the same usb path, the new device appears and is connected to the guest. I am not a qemu/system programmer and I apologize if I am missing something very obvious. Hope somebody can help me to find the best way to distinguish a usb device? Thanks in advance -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] migration: Fix possible bug for migrate cancel
Return error for migrate cancel, when migration status is not MIG_STATE_SETUP or MIG_STATE_ACTIVE. Thus, libvirt can can perceive the operation fails. Signed-off-by: zengjunliang zengjunli...@huawei.com Signed-off-by: Gonglei arei.gong...@huawei.com I think this is done on purpose, because canceling migration is racy. Instead, libvirt should do query-migrate and check if the migration was completed or canceled. Can you please give more details at how you are triggering the problem with libvirt? I think Paolo is probably right - the bug is more likely to be in libvirt not expecting the race and not recovering correctly when the race occurs, than it is to be in changing qemu's state algorithm. When the migration progress reaches 100%, and the migration status becomes MIG_STATE_COMPLETED in Qemu. It will take some time which from MIG_STATE_COMPLETED to the migration thread resources are recovered. If we cancel the migration at this moment, the migrate_fd_cancel function will break directly without reporting error code. Then, libvirt considers the cancle operation a success, contrary facts. Ping... Best regards, -Gonglei -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] question for interface in ethernet type and multiple queues in KVM (start VM failed)
I use ethernet vif for VM (libvirt 1.1.0 qemu 1.5.1). xml as such
interface type='ethernet'
script path='' /
target dev='tap_mq'/
mac address='52:54:00:19:9e:4e'/
model type='virtio' /
driver name='vhost' queues='2'/
/interface
tap_mq is a tap device with multi_queue property which was created
on host by ip command, such as follows
#ip tuntap add tap_mq mode tap multi_queue
I want to use multiple queue feature for this vif so I set queues='2'
in
xml.
When start VM , an error occurs
error: unsupported configuration: Multiqueue network is not
supported for: ethernet.
This error is reported from function qemuBuildInterfaceCommandLine
/* Currently nothing besides TAP devices supports multiqueue. */
if (net-driver.virtio.queues 0
!(actualType == VIR_DOMAIN_NET_TYPE_NETWORK ||
actualType == VIR_DOMAIN_NET_TYPE_BRIDGE)) {
virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
_(Multiqueue network is not supported
for: %s),
virDomainNetTypeToString(actualType));
return -1;
}
The comment specifies that only TAP device supports multiqueue. But
VIR_DOMAIN_NET_TYPE_ETHERNET is also TAP device I think.
Even though the device is TAP device indeed, it's not from the libvirt
POV. Libvirt doesn't examine the target dev to see if it is TAP,
physical NIC, sit, ... whatever.
Yep, but I think libvirt should provide this ability which process multi_queue
of ethernet type.
And the result is guaranteed by the emulator, such as Qemu.
As always, patches are welcome :)
Michal
Best regards,
-Gonglei
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] migration: Fix possible bug for migrate cancel
-Original Message- From: Eric Blake [mailto:ebl...@redhat.com] Sent: Tuesday, March 25, 2014 12:01 AM To: Paolo Bonzini; Gonglei (Arei); qemu-de...@nongnu.org Cc: quint...@redhat.com; owass...@redhat.com; Yanqiangjun; Zhaoyanbin (A); Zengjunliang; libvir-list@redhat.com Subject: Re: [PATCH] migration: Fix possible bug for migrate cancel [adding libvirt] On 03/24/2014 09:47 AM, Paolo Bonzini wrote: Il 24/03/2014 14:04, arei.gong...@huawei.com ha scritto: From: zengjunliang zengjunli...@huawei.com Return error for migrate cancel, when migration status is not MIG_STATE_SETUP or MIG_STATE_ACTIVE. Thus, libvirt can can perceive the operation fails. Signed-off-by: zengjunliang zengjunli...@huawei.com Signed-off-by: Gonglei arei.gong...@huawei.com I think this is done on purpose, because canceling migration is racy. Instead, libvirt should do query-migrate and check if the migration was completed or canceled. Can you please give more details at how you are triggering the problem with libvirt? I think Paolo is probably right - the bug is more likely to be in libvirt not expecting the race and not recovering correctly when the race occurs, than it is to be in changing qemu's state algorithm. When the migration progress reaches 100%, and the migration status becomes MIG_STATE_COMPLETED in Qemu. It will take some time which from MIG_STATE_COMPLETED to the migration thread resources are recovered. If we cancel the migration at this moment, the migrate_fd_cancel function will break directly without reporting error code. Then, libvirt considers the cancle operation a success, contrary facts. Best regards, -Gonglei -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] USB: about the auto identify funciton for guest OS
Hi, all Qemu upstream had achieved USB Auto Connect function for the guest. the patch was: https://lists.gnu.org/archive/html/qemu-devel/2011-05/msg02341.html However, Libvirt has not provide such an interface that identifies a USB device for pass through with physical port, rather than the device number. Do you have any ideas or plans about this problem? Thanks in advance. Best Regards, -Gonglei -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] USB: USB Passthrough Device Autoconnect Feature
Hi, all Qemu upstream had achieved USB Passthrough Device Autoconnect Feature for the guest. Such as a USB device is unplugged from the host then plugged back in to the same USB physical port. the patch was: https://lists.gnu.org/archive/html/qemu-devel/2011-05/msg02341.html However, Libvirt has not provide such an interface that identifies a USB device for pass through with physical port, rather than the device number. Do you have any ideas or plans about this problem? Thanks in advance. Best Regards, -Gonglei -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] usb: Correct test for virUSBDeviceListSteal
In the for loop, the if condition is always true, and will execute memmove. But it will cause the list-devs[i+1] overflow while i equals list-count-1. Signed-off-by: Gonglei arei.gong...@huawei.com --- src/util/virusb.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/util/virusb.c b/src/util/virusb.c index d34e44f..30d0b12 100644 --- a/src/util/virusb.c +++ b/src/util/virusb.c @@ -497,7 +497,7 @@ virUSBDeviceListSteal(virUSBDeviceListPtr list, ret = list-devs[i]; -if (i != list-count--) +if (i != --list-count) memmove(list-devs[i], list-devs[i+1], sizeof(*list-devs) * (list-count - i)); -- 1.7.3.1 Best Regards, -Gonglei -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Hostdev: USB passthrough, about hostport support
Hi, the Qemu upstream has a hostport property which allows to specify the host usb devices to pass through by bus number and physical port. Will the libvirt have a plan to support this? Thanks! The Qemu's patch: http://git.qemu.org/?p=qemu-stable-1.4.git;a=commitdiff;h=9056a2972a9e935198e518c37365513a199ae3d0 Best Regards! -Gonglei -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] virsh edit failed to take effect on KVM
Hi all, we use the command virsh edit to modify the VM configuration information online on KVM Platform(libvirt-1.0.0 and qemu-1.4), but it does not take effect after reboot. However, it works fine on Xen Platform. for an example,a VM is running with the following configuration information: ... os type arch='x86_64'hvm/type boot dev='hd'/ bootmenu enable='yes'/ /os ... use command virsh edit to modify it: ... os type arch='x86_64'hvm/type boot dev='cdrom'/ bootmenu enable='yes'/ /os ... With the changing, the VM is expected to start from cdrom, when execute the command virsh reboot. But the fact is that the modify does not take effect, the VM is still start from hd. Well, it will take effect if I use command virsh shutdown and virsh start instesad of virsh reboot. We are wondering if there have any other ways to take the online modify effect. What is the next step going on with the command virsh edit on KVM Platform? Any ideas? Thanks! -Gonglei -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
