From: osstest service owner <osstest-admin@xenproject.org>
To: xen-devel@lists.xensource.com, osstest-admin@xenproject.org
Subject: [libvirt test] 88753: regressions - trouble: blocked/broken/pass
Date: Tue, 05 Apr 2016 18:07:10 +0000 [thread overview]
Message-ID: <osstest-88753-mainreport@xen.org> (raw)
flight 88753 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/88753/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken REGR. vs. 88483
build-armhf-pvops 4 host-build-prep fail REGR. vs. 88483
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a
test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a
test-armhf-armhf-libvirt 1 build-check(1) blocked n/a
test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt-xsm 12 migrate-support-check fail never pass
test-amd64-i386-libvirt 12 migrate-support-check fail never pass
test-amd64-amd64-libvirt 12 migrate-support-check fail never pass
test-amd64-i386-libvirt-xsm 12 migrate-support-check fail never pass
test-amd64-amd64-libvirt-vhd 11 migrate-support-check fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass
version targeted for testing:
libvirt 2cc91ddd2d3043593172927e49762d3bab28f399
baseline version:
libvirt dfbc9a8382adc0495bf0e034ae6add92bed4822b
Last test of basis 88483 2016-04-03 04:27:22 Z 2 days
Testing same since 88753 2016-04-05 04:32:11 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
John Ferlan <jferlan@redhat.com>
Laine Stump <laine@laine.org>
Martin Kletzander <mkletzan@redhat.com>
jobs:
build-amd64-xsm pass
build-armhf-xsm pass
build-i386-xsm pass
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-pvops pass
build-armhf-pvops broken
build-i386-pvops pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm broken
test-amd64-amd64-libvirt-xsm pass
test-armhf-armhf-libvirt-xsm blocked
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt blocked
test-amd64-i386-libvirt pass
test-amd64-amd64-libvirt-pair pass
test-amd64-i386-libvirt-pair pass
test-armhf-armhf-libvirt-qcow2 blocked
test-armhf-armhf-libvirt-raw blocked
test-amd64-amd64-libvirt-vhd pass
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
broken-step test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm host-install(3)
Not pushing.
------------------------------------------------------------
commit 2cc91ddd2d3043593172927e49762d3bab28f399
Author: John Ferlan <jferlan@redhat.com>
Date: Mon Apr 4 15:27:58 2016 -0400
qemu: Fix mis-merge of qemuBuildRedirdevCommandLine
Commit id '59e7ef3c' misapplied a merge of commit id '019244751'
to place the "-chardev" command after formatting the character
backend value.
commit 28e960b691ad239fd41b0138f3d41e295bab51d5
Author: John Ferlan <jferlan@redhat.com>
Date: Mon Apr 4 15:26:43 2016 -0400
qemu: Fix mis-merge of qemuBuildConsoleCommandLine
Commit id 'e6944a52' misapplied a merge of commit id '019244751'
to place the "-chardev" command after formatting the character
backend value.
commit 48d5b3d81d06ed9b3441ddd5ad5d3f97b67a7126
Author: John Ferlan <jferlan@redhat.com>
Date: Mon Apr 4 15:24:28 2016 -0400
qemu: Fix mis-merge of qemuBuildChannelsCommandLine
Commit id '3cdcc910' misapplied a merge of commit id '019244751'
to place the "-chardev" command after formatting the character
backend value.
commit 6a97e35f827031daecd3258d72fa1d26a9c945e5
Author: John Ferlan <jferlan@redhat.com>
Date: Mon Apr 4 15:23:07 2016 -0400
qemu: Fix mis-merge of qemuBuildParallelsCommandLine
Commit id '0e1e7ade' misapplied a merge of commit id '019244751'
to place the "-chardev" command after formatting the character
backend value.
commit 3281b47e47706d3d31256d92c113fe10ec8e9de9
Author: John Ferlan <jferlan@redhat.com>
Date: Mon Apr 4 15:21:57 2016 -0400
qemu: Fix mis-merge of qemuBuildSerialCommandLine
Commit id '5ab8640' misapplied a merge of commit id '019244751'
to place the "-chardev" command after formatting the character
backend value.
commit 344bcd89ebbe0c703716820f781ed9c089851fef
Author: John Ferlan <jferlan@redhat.com>
Date: Mon Apr 4 15:19:57 2016 -0400
qemu: Fix mis-merge of qemuBuildSmartcardCommandLine
Commit id '858bafeb' misapplied a merge of commit id '019244751'
to place the "-chardev" command after formatting the character
backend value.
commit 17a94ba70fc11c21f8ea70ff92131d0868f4cde1
Author: Martin Kletzander <mkletzan@redhat.com>
Date: Sun Apr 3 19:55:54 2016 +0200
nodedev: Fix parsing of generated XMLs
Commit d77ffb6876 added not only reporting of the PCI header type, but
also parsing of that information. However, because there was no parsing
done for the other sub-PCI capabilities, if there was any other
capability then a valid header type name (like phys_function or
virt_functions) the parsing would fail. This prevented passing node
device XMLs that we generated into our own functions when dealing with,
e.g. with SRIOV cards.
Instead of reworking the whole parsing, just fix this one occurence and
remove a test for it for the time being. Future patches will deal with
the rest.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
commit 8f74f5277d33ab791ee5b94f77efbbbebe37c6b1
Author: Laine Stump <laine@laine.org>
Date: Fri Apr 1 13:18:57 2016 -0400
qemu: fix alias name for <interface type='hostdev'>
Starting with commit f8e712fe, if you start a domain that has an
<interface type='hostdev' (or that has <interface type='network'>
where the network is a pool of devices for hostdev assignment), when
you later try to add *another* interface (of any kind) with hotplug,
the function qemuAssignDeviceNetAlias() fails as soon as it sees a
"hostdevN" alias in the list of interfaces), causing the attach to
fail.
This is because (starting with f8e712fe) the device alias names are
assigned during the new function qemuProcessPrepareDomain(), which is
called *before* networkAllocateActualDevice() (which is called from
qemuProcessPrepareHost(), which is called from
qemuProcessLaunch()). Prior to that commit,
networkAllocateActualDevice() was called first.
The problem with this is that the alias for interfaces that are really
a hostdev (<interface type='hostdev'>) is of the form "hostdevN" (just
like other hostdevs), while other interfaces are "netN". But if you
don't know that the interface is going to be a hostdev at the time you
assign the alias name, you can't name it differently. (As far as I've
seen so far, the change in name by itself wouldn't have been a problem
(other than just an outwardly noticeable change in behavior) except
for the abovementioned failure to attach/detach new interfaces.
Rather than take the chance that there may be other not-yet-revealed
problems associated with changing the alias name, this patch changes
the way that aliases are assigned to restore the old behavior.
Old: In the past, assigning an alias to an interface was skipped if it
was seen that the interface was type='hostdev' - we knew that the
hostdev part of the interface was also in the list of hostdevs (that's
part of what happens in networkAllocateActualDevice()) and it would be
assigned when all the other hostdev aliases were assigned.
New: When assigning an alias to an interface, we haven't yet called
networkAllocateActualDevice() to construct the hostdev part of the
interface, so we can't just wait for the loop that creates aliases for
all the hostdevs (there's nothing on that list for this device
yet!). Instead we handle it immediately in the loop creating interface
aliases, by calling the new function networkGetActualType() to
determine if it is going to be hostdev, and if so calling
qemuAssignDeviceHostdevAlias() instead.
Some adjustments have to be made to both
qemuAssignDeviceHostdevAlias() and to qemuAssignDeviceNetAlias() to
accommodate this. In both of them, an error return from
qemuDomainDeviceAliasIndex() is no longer considered an error; instead
it's just ignored (because it almost certainly means that the alias
string for the device was "net" when we expected "hostdev" or vice
versa). in qemuAssignDeviceHostdevAlias() we have to look at all
interface aliases for hostdevN in addition to looking at all hostdev
aliases (this wasn't necessary in the past, because both the interface
entry and the hostdev entry for the device already pointed at the
device info; no longer the case since the hostdev entry hasn't yet
been setup).
Fortunately the buggy behavior hasn't yet been in any official release
of libvirt.
commit f09c7139b0f66fe687ba9fcc823a4837979b05c1
Author: Laine Stump <laine@laine.org>
Date: Fri Apr 1 10:40:23 2016 -0400
qemu: change args to qemuAssignDeviceHostdevAlias()
In certain cases, we need to assign a hostdevN-style alias in a case
when we don't have a virDomainHostdevDefPtr (instead we have a
virDomainNetDefPtr). Since qemuAssignDeviceHostdevAlias() doesn't use
anything in the virDomainHostdevDef except the alias string itself
anyway, this patch just changes the arguments to pass a pointer to the
alias pointer instead.
commit 3992ff14e5a5ce041cb6ba68f317101cee9e47d6
Author: Laine Stump <laine@laine.org>
Date: Fri Apr 1 09:45:51 2016 -0400
network: new function networkGetActualType
There are times when it's necessary to learn the actual type of a
network connection before any resources have been allocated
(e.g. during qemuProcessPrepareDomain()), but in the past it was
necessary to call networkAllocateActualDevice() in order to have the
actual type filled in.
This new function returns the type of network that *will be* setup
once it actually happens, but without making any changes on the host.
commit d558fb34fd0e410fdaeb993ea43ba733bfb5c528
Author: Martin Kletzander <mkletzan@redhat.com>
Date: Sun Apr 3 21:51:29 2016 +0200
qemu: Clear generated private paths
The paths have the domain ID in them. Without cleaning them, they would
contain the same ID even after multiple restarts. That could cause
various problems, e.g. with access.
Add function qemuDomainClearPrivatePaths() for this as a counterpart of
qemuDomainSetPrivatePaths().
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
commit 1893b6df117baf785cc568c9b044a849de0ca046
Author: Martin Kletzander <mkletzan@redhat.com>
Date: Sun Apr 3 21:59:46 2016 +0200
qemu: Simplify calls to qemuDomainSetPrivatePaths
Since commit 9dca74ee6f54, the function can take driver and a vm, no
need to overcomplicate.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
reply other threads:[~2016-04-05 18:07 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=osstest-88753-mainreport@xen.org \
--to=osstest-admin@xenproject.org \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).