September 2015 - Devel - libvirt List Archives

[libvirt] [PATCH v3 0/5] vz: add migration support
by nshirokovskiy＠virtuozzo.com 02 Sep '15

02 Sep '15

NOTE that minimal command to migrate vz domain is like next: virsh -c vz:///system migrate --direct 200 shiny0 --migrateuri vz+ssh://shiny0/system --live --persistent --compressed ==Difference from v1: 1. Patch is quite different. First patchset implements migration thru managed migration scheme. This one goes thru p2p scheme. I belive this is a better approach. Vz migration is done via vz sdk and first patchset uses 5 phased migration only to get a token from destination on prepare phase which is kind a misuse. This patch just adds vz specific function to driver interface to archive the same goal. 2. Offline migration is supported as there is no more dependency on current flow of managed migration scheme. ==Difference from v2: 1. Implement thru direct migration instead of p2p. p2p is just managed 5-staged migration when managing is done on daemon side. Vz migration stages are all hidden in vz sdk and thus it would be more consistent to use direct scheme. 2. Use existing driver function for prepare migration phase to pass session uuid from destination to source instead of new one. As vz migration is direct one we will not use prepare phase function in a straight forward manner anyway. src/libvirt-domain.c | 3 +- src/vz/vz_driver.c | 315 ++++++++++++++++++++++++++++++++++++++++++++++++++ src/vz/vz_sdk.c | 86 ++++++++++++--- src/vz/vz_sdk.h | 6 + src/vz/vz_utils.h | 4 +- 5 files changed, 398 insertions(+), 16 deletions(-)

4 25

[libvirt] libvirtlight problem with Xen
by Eric 02 Sep '15

02 Sep '15

I'm trying to use virt-manager with Xen. My Dom0 is Debian 8. When I create a DomU (Ubuntu Trusty) as a PV guest, the boot fails with an error saying that libvirtlight failed to connect. The opinion from the virt-manager list group is that the problem is libvirt, not virt-manager. I've googled around, and have seen old posts about this, but these seem to claim that the problem has resolved. Solution? Thanks Eric

2 1

[libvirt] [PATCH] virVMXParseDisk: Recognize scsi-passthru
by Michal Privoznik 01 Sep '15

01 Sep '15

https://bugzilla.redhat.com/show_bug.cgi?id=1172544 So, imagine you have this config: scsi0:1.present = "TRUE" scsi0:1.deviceType = "scsi-passthru" scsi0:1.fileName = "/vmfs/devices/cdrom/mpx.vmhba32:C0:T0:L0" scsi0:1.allowGuestConnectionControl = "FALSE" So far, libvirt does not recognize this pattern and fails. What if we produce the following XML to it? <disk type='block' device='disk'> <source dev='/vmfs/devices/cdrom/mpx.vmhba32:C0:T0:L0'/> <target dev='sdb' bus='scsi'/> <address type='drive' controller='0' bus='0' target='0' unit='1'/> </disk> Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/vmx/vmx.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/src/vmx/vmx.c b/src/vmx/vmx.c index 36e2891..6d83d81 100644 --- a/src/vmx/vmx.c +++ b/src/vmx/vmx.c @@ -2187,6 +2187,17 @@ virVMXParseDisk(virVMXContext *ctx, virDomainXMLOptionPtr xmlopt, virConfPtr con * function to parse a CDROM device may handle it. */ goto ignore; + } else if (STREQ_NULLABLE(deviceType, "scsi-passthru")) { + char *tmp; + + virDomainDiskSetType(*def, VIR_STORAGE_TYPE_BLOCK); + if (!(tmp = ctx->parseFileName(fileName, ctx->opaque))) + goto cleanup; + if (virDomainDiskSetSource(*def, tmp) < 0) { + VIR_FREE(tmp); + goto cleanup; + } + VIR_FREE(tmp); } else { virReportError(VIR_ERR_INTERNAL_ERROR, _("Invalid or not yet handled value '%s' " -- 2.4.6

2 2

[libvirt] Missing CPU vendor in capabilities in 1.2.18+
by Guido Günther 01 Sep '15

01 Sep '15

Hi, We have a report in Debian[1] where after a update from 1.2.16 to 1.2.18 VMs on a Intel i5 CPU fail to start due to libvirt not being able to match the CPU vendor: # virsh start sid error: Failed to start domain sid error: unsupported configuration: guest and host CPU are not compatible: host CPU vendor does not match required CPU vendor Intel The root cause seems to be that the <vendor> element is missing from the hosts capabilities. While I have: $ virsh capabilities | xpath -q -e //host/cpu/vendor <vendor>Intel</vendor> on my Intel box the reporters machine with a Core i5 the <vendor> element is just empty. Any idea what could have triggered this? This is still broken in 1.2.19-rc1. The bug has more details and logs attached. Any pointers would be welcome since I don't have access to such a machine atm to step through src/cpu/cpu_x86.c. Cheers, -- Guido [1] http://bugs.debian.org/797513

1 0

[libvirt] [PATCH] qemu: Default to virtio network devices on ppc64
by Andrea Bolognani 01 Sep '15

01 Sep '15

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1254044 --- src/qemu/qemu_domain.c | 3 ++- .../qemuxml2argvdata/qemuxml2argv-pseries-net-default.args | 6 ++++++ .../qemuxml2argvdata/qemuxml2argv-pseries-net-default.xml | 14 ++++++++++++++ tests/qemuxml2argvtest.c | 1 + 4 files changed, 23 insertions(+), 1 deletion(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-net-default.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-net-default.xml diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index 0a9ed6b..4c5b3ec 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -1195,7 +1195,8 @@ qemuDomainDefPostParse(virDomainDefPtr def, static const char * qemuDomainDefaultNetModel(const virDomainDef *def) { - if (ARCH_IS_S390(def->os.arch)) + if (ARCH_IS_S390(def->os.arch) || + ARCH_IS_PPC64(def->os.arch)) return "virtio"; if (def->os.arch == VIR_ARCH_ARMV7L || diff --git a/tests/qemuxml2argvdata/qemuxml2argv-pseries-net-default.args b/tests/qemuxml2argvdata/qemuxml2argv-pseries-net-default.args new file mode 100644 index 0000000..50adffa --- /dev/null +++ b/tests/qemuxml2argvdata/qemuxml2argv-pseries-net-default.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-ppc64 -S -M pseries -m 512 -smp 1 -nographic -nodefaults \ +-monitor unix:/tmp/test-monitor,server,nowait -no-acpi -boot c -usb \ +-device virtio-net-pci,vlan=0,id=net0,mac=52:54:00:55:2b:d9,bus=pci,addr=0x1 \ +-net user,vlan=0,name=hostnet0 \ +-device virtio-balloon-pci,id=balloon0,bus=pci,addr=0x3 diff --git a/tests/qemuxml2argvdata/qemuxml2argv-pseries-net-default.xml b/tests/qemuxml2argvdata/qemuxml2argv-pseries-net-default.xml new file mode 100644 index 0000000..7bf8139 --- /dev/null +++ b/tests/qemuxml2argvdata/qemuxml2argv-pseries-net-default.xml @@ -0,0 +1,14 @@ +<domain type='qemu'> + <name>pseries-net-default</name> + <memory unit='KiB'>524288</memory> + <vcpu placement='static'>1</vcpu> + <os> + <type arch='ppc64' machine='pseries'>hvm</type> + </os> + <devices> + <emulator>/usr/bin/qemu-system-ppc64</emulator> + <interface type='user'> + <mac address='52:54:00:55:2b:d9'/> + </interface> + </devices> +</domain> diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c index c2482e6..f20a94b 100644 --- a/tests/qemuxml2argvtest.c +++ b/tests/qemuxml2argvtest.c @@ -1397,6 +1397,7 @@ mymain(void) QEMU_CAPS_CHARDEV, QEMU_CAPS_DEVICE, QEMU_CAPS_NODEFCONFIG, QEMU_CAPS_PIIX3_USB_UHCI, QEMU_CAPS_PCI_OHCI, QEMU_CAPS_PCI_MULTIFUNCTION); + DO_TEST("pseries-net-default", QEMU_CAPS_DEVICE); DO_TEST("pseries-vio-user-assigned", QEMU_CAPS_DRIVE, QEMU_CAPS_CHARDEV, QEMU_CAPS_DEVICE, QEMU_CAPS_NODEFCONFIG); DO_TEST_ERROR("pseries-vio-address-clash", QEMU_CAPS_DRIVE, -- 2.4.3

2 1