[vdsm] network/integration test failures
by Francesco Romani
This is a multi-part message in MIME format.
--------------3945872423EDD8DBF79FFA16
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Hi developers,
we had another network CI failure while testing unrelated changes:
http://jenkins.ovirt.org/job/vdsm_master_check-patch-el7-x86_64/22708/con...
*12:20:19* self = <network.integration.link_bond_test.LinkBondTests testMethod=test_bond_clear_arp_ip_target>
*12:20:19*
*12:20:19* def test_bond_clear_arp_ip_target(self):
*12:20:19* OPTIONS_A = {
*12:20:19* 'mode': '1',
*12:20:19* 'arp_interval': '1000',
*12:20:19* 'arp_ip_target': '192.168.122.1'}
*12:20:19* OPTIONS_B = {
*12:20:19* 'mode': '1',
*12:20:19* 'arp_interval': '1000'}
*12:20:19*
*12:20:19* with bond_device() as bond:
*12:20:19* > bond.set_options(OPTIONS_A)
*12:20:19*
*12:20:19* network/integration/link_bond_test.py:171:
Could please some network developer have a look?
Bests,
--
Francesco Romani
Senior SW Eng., Virtualization R&D
Red Hat
IRC: fromani github: @fromanirh
--------------3945872423EDD8DBF79FFA16
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi developers,</p>
<p><br>
</p>
<p>we had another network CI failure while testing unrelated
changes:</p>
<p><br>
</p>
<p><a class="moz-txt-link-freetext" href="http://jenkins.ovirt.org/job/vdsm_master_check-patch-el7-x86_64/22708/con...">http://jenkins.ovirt.org/job/vdsm_master_check-patch-el7-x86_64/22708/con...</a></p>
<p><br>
</p>
<pre class="console-output"><span class="timestamp"><b>12:20:19</b> </span>self = <network.integration.link_bond_test.LinkBondTests testMethod=test_bond_clear_arp_ip_target>
<span class="timestamp"><b>12:20:19</b> </span>
<span class="timestamp"><b>12:20:19</b> </span> def test_bond_clear_arp_ip_target(self):
<span class="timestamp"><b>12:20:19</b> </span> OPTIONS_A = {
<span class="timestamp"><b>12:20:19</b> </span> 'mode': '1',
<span class="timestamp"><b>12:20:19</b> </span> 'arp_interval': '1000',
<span class="timestamp"><b>12:20:19</b> </span> 'arp_ip_target': '192.168.122.1'}
<span class="timestamp"><b>12:20:19</b> </span> OPTIONS_B = {
<span class="timestamp"><b>12:20:19</b> </span> 'mode': '1',
<span class="timestamp"><b>12:20:19</b> </span> 'arp_interval': '1000'}
<span class="timestamp"><b>12:20:19</b> </span>
<span class="timestamp"><b>12:20:19</b> </span> with bond_device() as bond:
<span class="timestamp"><b>12:20:19</b> </span>> bond.set_options(OPTIONS_A)
<span class="timestamp"><b>12:20:19</b> </span>
<span class="timestamp"><b>12:20:19</b> </span>network/integration/link_bond_test.py:171:
Could please some network developer have a look?
Bests,
</pre>
<pre class="moz-signature" cols="72">--
Francesco Romani
Senior SW Eng., Virtualization R&D
Red Hat
IRC: fromani github: @fromanirh</pre>
</body>
</html>
--------------3945872423EDD8DBF79FFA16--
6 years, 9 months
[ OST Failure Report ] [ oVirt Master (log-collector/engine/vdsm) ] [ 23/25/26-03-2018 ] [004_basic_sanity.hotplug_cpu ]
by Dafna Ron
Hi,
We have a failure that seems to be random and happening in several
projects.
from what I can see, we are failing due to a timing issue in the test
itself because we are querying the vm after its been destroyed in engine.
looking at engine, I can see that the vm was actually shut down,
I would like to disable this test until we can fix the issue since it
already failed about 7 different patches from different projects.
*Link to
Job:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6521/
<http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6521/>Link
to all
logs:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6521/a...
<http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6521/artifa...>(Relevant)
error snippet from the log: <error>*
*engine: 018-03-23 14:44:14,156-04 INFO
[org.ovirt.engine.core.vdsbroker.vdsbroker.DestroyVDSCommand]
(ForkJoinPool-1-worker-5) [] Failed to destroy VM
'7020944f-cd26-4c31-b381-0ce6be733fd7' because VM does not exist,
ignoring2018-03-23 14:44:14,156-04 INFO
[org.ovirt.engine.core.vdsbroker.vdsbroker.DestroyVDSCommand]
(ForkJoinPool-1-worker-5) [] FINISH, DestroyVDSCommand, log id:
646766a2018-03-23 14:44:14,156-04 DEBUG
[org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor]
(ForkJoinPool-1-worker-5) [] method: runVdsCommand, params: [Destroy,
DestroyVmVDSCommandParameters:{hostId='c40b11df-7053-437e-8acc-c5e91c1694bc',
vmId='7020944f-cd26-4c31-b381-0ce6be733fd7', secondsToWait='0',
gracefully='false', reason='', ignoreNoVm='true'}], timeElapsed:
14ms2018-03-23 14:44:14,156-04 DEBUG
[org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor]
(ForkJoinPool-1-worker-5) [] method: getVmManager, params:
[7020944f-cd26-4c31-b381-0ce6be733fd7], timeElapsed: 0ms2018-03-23
14:44:14,156-04 INFO
[org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer]
(ForkJoinPool-1-worker-5) [] VM '7020944f-cd26-4c31-b381-0ce6be733fd7'(vm2)
moved from 'Up' --> 'Down'2018-03-23 14:44:14,156-04 DEBUG
[org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor]
(ForkJoinPool-1-worker-5) [] method: getVmManager, params:
[7020944f-cd26-4c31-b381-0ce6be733fd7], timeElapsed: 0ms2018-03-23
14:44:14,177-04 INFO
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(default task-4) [a463501f-f01a-4048-93ca-02647308394b] EVENT_ID:
USER_STOP_VM(33), VM vm2 powered off by admin@internal-authz (Host:
lago-basic-suite-master-host-0).*
*vdsm: 2018-03-23 14:44:14,024-0400 INFO (libvirt/events) [virt.vm]
(vmId='7020944f-cd26-4c31-b381-0ce6be733fd7') Changed state to Down: Admin
shut down from the engine (code=6) (vm:1684)2018-03-23 14:44:14,028-0400
INFO (jsonrpc/1) [api.virt] FINISH destroy return={'status': {'message':
'Machine destroyed', 'code': 0}} from=::ffff:192.168.201.4,53454,
flow_id=a463501f-f01a-4048-93ca-02647308394b,
vmId=7020944f-cd26-4c31-b381-0ce6be733fd7 (api:52)2018-03-23
14:44:14,028-0400 INFO (jsonrpc/1) [jsonrpc.JsonRpcServer] RPC call
VM.destroy succeeded in 1.72 seconds (__init__:311)2018-03-23
14:44:14,031-0400 INFO (periodic/2) [Executor] Worker was discarded
(executor:305)2018-03-23 14:44:14,033-0400 INFO (libvirt/events) [virt.vm]
(vmId='7020944f-cd26-4c31-b381-0ce6be733fd7') Stopping connection
(guestagent:440)2018-03-23 14:44:14,033-0400 ERROR (libvirt/events) [vds]
Error running VM callback (clientIF:666)Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/vdsm/clientIF.py", line 629, in
dispatchLibvirtEvents v.onLibvirtLifecycleEvent(event, detail,
None)AttributeError: 'NoneType' object has no attribute
'onLibvirtLifecycleEvent'2018-03-23 14:44:14,078-0400 INFO (jsonrpc/4)
[api.virt] START destroy(gracefulAttempts=1)
from=::ffff:192.168.201.4,53454, vmId=7020944f-cd26-4c31-b381-0ce6be733fd7
(api:46)2018-03-23 14:44:14,078-0400 INFO (jsonrpc/4) [api] FINISH destroy
error=Virtual machine does not exist: {'vmId':
u'7020944f-cd26-4c31-b381-0ce6be733fd7'} (api:127)2018-03-23
14:44:14,079-0400 INFO (jsonrpc/4) [api.virt] FINISH destroy
return={'status': {'message': "Virtual machine does not exist: {'vmId':
u'7020944f-cd26-4c31-b381-0ce6be733fd7'}", 'code': 1}}
from=::ffff:192.168.201.4,53454, vmId=7020944f-cd26-4c31-b381-0ce6be733fd7
(api:52)*
*</error>*
6 years, 9 months
[ENGINE] JUnit version upgrade
by Allon Mureinik
Hi oVirt Engine developers,
I've just merged a patch to bump oVirt Engine's JUnit requirement to the
latest available 5.1 GA.
As a first step, I've integrated the vintage engine, which is a drop-in
replacement that can run old JUnit 4 (and even JUnit 3!) tests, just with a
newer runtime engine.
This isn't the final goal, but a first step towards moving to the newer
Jupiter engine, which won't be a clean dependency replacement.
Please let me know if you encounter any problem.
Regards,
Allon
6 years, 9 months
[ OST Failure Report ] [ oVirt Master (ovirt-engine-nodejs-modules) ] [ 23-03-2018] [ 002_bootstrap.check_update_host ]
by Dafna Ron
Hi,
we had a failure reported in CQ for change:
https://gerrit.ovirt.org/#/c/89338/ - Bump 1.5.2-1.
I don't think the failure is related to the change. it seems to be an issue
with mom failing to start.
*Link and headline of suspected patches:
https://gerrit.ovirt.org/#/c/89338/ <https://gerrit.ovirt.org/#/c/89338/> -
Bump 1.5.2-1Link to
Job:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6512/
<http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6512/>Link
to all
logs:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6512/a...
<http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6512/artifa...>(Relevant)
error snippet from the log: <error>*
*engine: *018-03-23 07:12:33,435-04 ERROR
[org.ovirt.engine.core.bll.host.HostUpgradeManager]
(EE-ManagedThreadFactory-commandCoordinator-Thread-1)
[7a4f81e6-6ae6-4444-ace6-de757e78f41e] Failed to run check-update of host
'lago-basic-suite-master-
host-0'.
2018-03-23 07:12:33,436-04 ERROR
[org.ovirt.engine.core.bll.hostdeploy.HostUpdatesChecker]
(EE-ManagedThreadFactory-commandCoordinator-Thread-1)
[7a4f81e6-6ae6-4444-ace6-de757e78f41e] Failed to check if updates are
available for host 'lag
o-basic-suite-master-host-0' with error message 'Failed to run check-update
of host 'lago-basic-suite-master-host-0'.'
2018-03-23 07:12:33,441-04 ERROR
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(EE-ManagedThreadFactory-commandCoordinator-Thread-1)
[7a4f81e6-6ae6-4444-ace6-de757e78f41e] EVENT_ID:
HOST_AVAILABLE_UPDATES_FAILED(8
39), Failed to check for available updates on host
lago-basic-suite-master-host-0 with message 'Failed to run check-update of
host 'lago-basic-suite-master-host-0'.'.
2018-03-23 07:12:33,566-04 DEBUG
[org.ovirt.engine.core.vdsbroker.vdsbroker.GetAllVmStatsVDSCommand]
(EE-ManagedThreadFactory-engineScheduled-Thread-11) [] START,
GetAllVmStatsVDSCommand(HostName = lago-basic-suite-master-host-0, VdsIdVDS
CommandParametersBase:{hostId='dc339bcf-b769-41f6-8252-c61fffd56b17'}), log
id: 4eb92a5a
2018-03-23 07:12:33,567-04 DEBUG
[org.ovirt.vdsm.jsonrpc.client.reactors.stomp.impl.Message]
(EE-ManagedThreadFactory-engineScheduled-Thread-11) [] SEND
destination:jms.topic.vdsm_requests
reply-to:jms.topic.vdsm_responses
content-length:103
*host-0:*
vdsm log show: momStatus': 'inactive'
*Mom log: *
2018-03-23 07:09:48,849 - mom - INFO - MOM starting
2018-03-23 07:09:48,864 - mom.HostMonitor - INFO - Host Monitor starting
2018-03-23 07:09:48,867 - mom - INFO - hypervisor interface
vdsmjsonrpcclient
2018-03-23 07:09:48,983 - mom - ERROR - Failed to initialize MOM threads
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/mom/__init__.py", line 29, in run
hypervisor_iface = self.get_hypervisor_interface()
File "/usr/lib/python2.7/site-packages/mom/__init__.py", line 217, in
get_hypervisor_interface
return module.instance(self.config)
File
"/usr/lib/python2.7/site-packages/mom/HypervisorInterfaces/vdsmjsonrpcclientInterface.py",
line 96, in instance
return JsonRpcVdsmClientInterface()
File
"/usr/lib/python2.7/site-packages/mom/HypervisorInterfaces/vdsmjsonrpcclientInterface.py",
line 31, in __init__
self._vdsm_api = client.connect(host="localhost")
File "/usr/lib/python2.7/site-packages/vdsm/client.py", line 139, in
connect
raise ConnectionError(host, port, use_tls, timeout, e)
ConnectionError: Connection to localhost:54321 with use_tls=True,
timeout=60 failed: [Errno 111] Connection refused
2018-03-23 07:09:54,475 - mom - INFO - MOM starting
2018-03-23 07:09:54,499 - mom.HostMonitor - INFO - Host Monitor starting
2018-03-23 07:09:54,500 - mom - INFO - hypervisor interface
vdsmjsonrpcclient
2018-03-23 07:09:54,725 - mom.HostMonitor - INFO - HostMonitor is ready
2018-03-23 07:09:54,813 - mom.GuestManager - INFO - Guest Manager starting:
multi-thread
2018-03-23 07:09:54,819 - mom.Policy - INFO - Loaded policy '00-defines'
2018-03-23 07:09:54,820 - mom.Policy - INFO - Loaded policy '01-parameters'
2018-03-23 07:09:54,841 - mom.Policy - INFO - Loaded policy '02-balloon'
2018-03-23 07:09:54,871 - mom.Policy - INFO - Loaded policy '03-ksm'
2018-03-23 07:09:54,909 - mom.Policy - INFO - Loaded policy '04-cputune'
2018-03-23 07:09:54,951 - mom.Policy - INFO - Loaded policy '05-iotune'
2018-03-23 07:09:54,956 - mom.PolicyEngine - INFO - Policy Engine starting
2018-03-23 07:09:54,957 - mom.RPCServer - INFO - Using unix socket
/var/run/vdsm/mom-vdsm.sock
2018-03-23 07:09:54,957 - mom.RPCServer - INFO - RPC Server starting
2018-03-23 07:10:10,020 - mom.Controllers.KSM - INFO - Updating KSM
configuration: pages_to_scan:0 merge_across_nodes:1 run:0 sleep_millisecs:0
lago-basic-suite-master-host-0/_var_log/vdsm/mom.log (END)
*</error>*
6 years, 9 months
Fwd: Project for profiles and defaults for libvirt domains
by Michal Skrivanek
--Apple-Mail=_6D569541-1CA3-4944-AFE7-86FD31122B7D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
cross-posting to the right list, by mistake a wrong ovirt list was used =
originally
> Begin forwarded message:
>=20
> From: Martin Kletzander <mkletzan(a)redhat.com>
> Subject: [kubevirt-dev] Project for profiles and defaults for libvirt =
domains
> Date: 20 March 2018 at 15:20:31 CET
> To: libvir-list(a)redhat.com, openstack-dev(a)lists.openstack.org, =
ovirt-devel(a)redhat.com, kubevirt-dev(a)googlegroups.com, =
virt-tools-list(a)redhat.com, cockpit-devel(a)lists.fedorahosted.org
>=20
> Hi everyone!
>=20
> First of all sorry for such wide distribution, but apparently that's =
the
> best way to make sure we cooperate nicely. So please be considerate =
as
> this is a cross-post between huge amount of mailing lists.
>=20
> After some discussions with developers from different projects that =
work
> with libvirt one cannot but notice some common patterns and =
workarounds.
> So I set off to see how can we make all our lives better and our =
coding
> more effective (and maybe more fun as well). If all goes well we will
> create a project that will accommodate most of the defaulting, =
policies,
> workarounds and other common algorithms around libvirt domain
> definitions. And since early design gets you half way, I would like =
to
> know your feedback on several key points as well as on the general =
idea.
> Also correct me brutally in case I'm wrong.
>=20
> In order to not get confused in the following descriptions, I will =
refer
> to this project idea using the name `virtuned`, but there is really no
> name for it yet (although an abbreviation for "Virtualization
> Abstraction Definition and Hypervisor Delegation" would suit well,
> IMHO).
>=20
> Here are some common problems and use cases that virtuned could solve
> (or help with). Don't take it as something that's impossible to solve
> on your own, but rather something that could be de-duplicated from
> multiple projects or "done right" instead of various hack-ish =
solutions.
>=20
> 1) Default devices/values
>=20
> Libvirt itself must default to whatever values there were before any
> particular element was introduced due to the fact that it strives to
> keep the guest ABI stable. That means, for example, that it can't =
just
> add -vmcoreinfo option (for KASLR support) or magically add the =
pvpanic
> device to all QEMU machines, even though it would be useful, as that
> would change the guest ABI.
>=20
> For default values this is even more obvious. Let's say someone =
figures
> out some "pretty good" default values for various HyperV enlightenment
> feature tunables. Libvirt can't magically change them, but each one =
of
> the projects building on top of it doesn't want to keep that list
> updated and take care of setting them in every new XML. Some projects
> don't even expose those to the end user as a knob, while others might.
>=20
> One more thing could be automatically figuring out best values based =
on
> libosinfo-provided data.
>=20
> 2) Policies
>=20
> Lot of the time there are parts of the domain definition that need to =
be
> added, but nobody really cares about them. Sometimes it's enough to
> have few templates, another time you might want to have a policy
> per-scenario and want to combine them in various ways. For example =
with
> the data provided by point 1).
>=20
> For example if you want PCI-Express, you need the q35 machine type, =
but
> you don't really want to care about the machine type. Or you want to
> use SPICE, but you don't want to care about adding QXL.
>=20
> What if some of these policies could be specified once (using some DSL
> for example), and used by virtuned to merge them in a unified and
> predictable way?
>=20
> 3) Abstracting the XML
>=20
> This is probably just usable for stateless apps, but it might happen
> that some apps don't really want to care about the XML at all. They
> just want an abstract view of the domain, possibly add/remove a device
> and that's it. We could do that as well. I can't really tell how =
much
> of a demand there is for it, though.
>=20
> 4) Identifying devices properly
>=20
> In contrast to the previous point, stateful apps might have a problem
> identifying devices after hotplug. For example, let's say you don't
> care about the addresses and leave that up to libvirt. You hotplug a
> device into the domain and dump the new XML of it. Depending on what
> type of device it was, you might need to identify it based on =
different
> values. It could be <target dev=3D''/> for disks, <mac address=3D''/> =
for
> interfaces etc. For some devices it might not even be possible and =
you
> need to remember the addresses of all the previous devices and then
> parse them just to identify that one device and then throw them away.
>=20
> With new enough libvirt you could use the user aliases for that, but
> turns out it's not that easy to use them properly anyway. Also the
> aliases won't help users identify that device inside the guest.
>=20
> <rant>
> We really should've gone with new attribute for the user alias instead
> of using an existing one, given how many problems that is causing.
> </rant>
>=20
> 5) Generating the right XML snippet for device hot-(un)plug
>=20
> This is kind of related to some previous points.
>=20
> When hot-plugging a device and creating an XML snippet for it, you =
want
> to keep the defaults from point 1) and policies from 2) in mind. Or
> something related to the already existing domain which you can =
describe
> systematically. And adding something for identification (see previous
> point).
>=20
> Doing the hot-unplug is easy depending on how much information about
> that device is saved by your application. The less you save about the
> device (or show to the user in a GUI, if applicable) the harder it =
might
> be to generate an XML that libvirt will accept. Again, some problems
> with this should be fixed in libvirt, some of them are easy to
> workaround. But having a common ground that takes care of this should
> help some projects.
>=20
> Hot-unplug could be implemented just based on the alias. This is
> something that would fit into libvirt as well.
>=20
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> To mention some pre-existing solutions:
>=20
> - I understand OpenStack has some really sensible and wisely chosen
> and/or tested default values.
>=20
> - I know KubeVirt has VirtualMachinePresets. That is something =
closely
> related to points 1) and 2). Also their abstraction of the XML might
> be usable for point 3).
>=20
> - There was an effort on creating policy based configuration of =
libvirt
> objects called libvirt-designer. This is closely related to points 2)
> and 3). Unfortunately there was no much going on lately and part of
> virt-manager repository has currently more features implemented with
> the same ideas in mind, just not exported for public use.
>=20
> We could utilize some of the above to various extents.
>=20
> Let me know what you think and have a nice day.
> Martin
>=20
> --=20
> You received this message because you are subscribed to the Google =
Groups "kubevirt-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send =
an email to kubevirt-dev+unsubscribe(a)googlegroups.com.
> To post to this group, send email to kubevirt-dev(a)googlegroups.com.
> To view this discussion on the web visit =
https://groups.google.com/d/msgid/kubevirt-dev/20180320142031.GB23007%40wh=
eatley.
> For more options, visit https://groups.google.com/d/optout.
--Apple-Mail=_6D569541-1CA3-4944-AFE7-86FD31122B7D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=us-ascii
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" =
class=3D"">cross-posting to the right list, by mistake a wrong ovirt =
list was used originally<div class=3D""><div><br class=3D""><blockquote =
type=3D"cite" class=3D""><div class=3D"">Begin forwarded =
message:</div><br class=3D"Apple-interchange-newline"><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px;" class=3D""><span style=3D"font-family: =
-webkit-system-font, Helvetica Neue, Helvetica, sans-serif; =
color:rgba(0, 0, 0, 1.0);" class=3D""><b class=3D"">From: =
</b></span><span style=3D"font-family: -webkit-system-font, Helvetica =
Neue, Helvetica, sans-serif;" class=3D"">Martin Kletzander <<a =
href=3D"mailto:mkletzan@redhat.com" =
class=3D"">mkletzan(a)redhat.com</a>><br class=3D""></span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px;" class=3D""><span style=3D"font-family: =
-webkit-system-font, Helvetica Neue, Helvetica, sans-serif; =
color:rgba(0, 0, 0, 1.0);" class=3D""><b class=3D"">Subject: =
</b></span><span style=3D"font-family: -webkit-system-font, Helvetica =
Neue, Helvetica, sans-serif;" class=3D""><b class=3D"">[kubevirt-dev] =
Project for profiles and defaults for libvirt domains</b><br =
class=3D""></span></div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px;" class=3D""><span =
style=3D"font-family: -webkit-system-font, Helvetica Neue, Helvetica, =
sans-serif; color:rgba(0, 0, 0, 1.0);" class=3D""><b class=3D"">Date: =
</b></span><span style=3D"font-family: -webkit-system-font, Helvetica =
Neue, Helvetica, sans-serif;" class=3D"">20 March 2018 at 15:20:31 =
CET<br class=3D""></span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=3D""><span=
style=3D"font-family: -webkit-system-font, Helvetica Neue, Helvetica, =
sans-serif; color:rgba(0, 0, 0, 1.0);" class=3D""><b class=3D"">To: =
</b></span><span style=3D"font-family: -webkit-system-font, Helvetica =
Neue, Helvetica, sans-serif;" class=3D""><a =
href=3D"mailto:libvir-list@redhat.com" =
class=3D"">libvir-list(a)redhat.com</a>, <a =
href=3D"mailto:openstack-dev@lists.openstack.org" =
class=3D"">openstack-dev(a)lists.openstack.org</a>, <a =
href=3D"mailto:ovirt-devel@redhat.com" =
class=3D"">ovirt-devel(a)redhat.com</a>, <a =
href=3D"mailto:kubevirt-dev@googlegroups.com" =
class=3D"">kubevirt-dev(a)googlegroups.com</a>, <a =
href=3D"mailto:virt-tools-list@redhat.com" =
class=3D"">virt-tools-list(a)redhat.com</a>, <a =
href=3D"mailto:cockpit-devel@lists.fedorahosted.org" =
class=3D"">cockpit-devel(a)lists.fedorahosted.org</a><br =
class=3D""></span></div><br class=3D""><div class=3D""><div class=3D"">Hi =
everyone!<br class=3D""><br class=3D"">First of all sorry for such wide =
distribution, but apparently that's the<br class=3D"">best way to make =
sure we cooperate nicely. So please be considerate as<br =
class=3D"">this is a cross-post between huge amount of mailing lists.<br =
class=3D""><br class=3D"">After some discussions with developers from =
different projects that work<br class=3D"">with libvirt one cannot but =
notice some common patterns and workarounds.<br class=3D"">So I set off =
to see how can we make all our lives better and our coding<br =
class=3D"">more effective (and maybe more fun as well). If all =
goes well we will<br class=3D"">create a project that will accommodate =
most of the defaulting, policies,<br class=3D"">workarounds and other =
common algorithms around libvirt domain<br class=3D"">definitions. =
And since early design gets you half way, I would like to<br =
class=3D"">know your feedback on several key points as well as on the =
general idea.<br class=3D"">Also correct me brutally in case I'm =
wrong.<br class=3D""><br class=3D"">In order to not get confused in the =
following descriptions, I will refer<br class=3D"">to this project idea =
using the name `virtuned`, but there is really no<br class=3D"">name for =
it yet (although an abbreviation for "Virtualization<br =
class=3D"">Abstraction Definition and Hypervisor Delegation" would suit =
well,<br class=3D"">IMHO).<br class=3D""><br class=3D"">Here are some =
common problems and use cases that virtuned could solve<br class=3D"">(or =
help with). Don't take it as something that's impossible to =
solve<br class=3D"">on your own, but rather something that could be =
de-duplicated from<br class=3D"">multiple projects or "done right" =
instead of various hack-ish solutions.<br class=3D""><br class=3D"">1) =
Default devices/values<br class=3D""><br class=3D"">Libvirt itself must =
default to whatever values there were before any<br class=3D"">particular =
element was introduced due to the fact that it strives to<br =
class=3D"">keep the guest ABI stable. That means, for example, =
that it can't just<br class=3D"">add -vmcoreinfo option (for KASLR =
support) or magically add the pvpanic<br class=3D"">device to all QEMU =
machines, even though it would be useful, as that<br class=3D"">would =
change the guest ABI.<br class=3D""><br class=3D"">For default values =
this is even more obvious. Let's say someone figures<br =
class=3D"">out some "pretty good" default values for various HyperV =
enlightenment<br class=3D"">feature tunables. Libvirt can't =
magically change them, but each one of<br class=3D"">the projects =
building on top of it doesn't want to keep that list<br class=3D"">updated=
and take care of setting them in every new XML. Some projects<br =
class=3D"">don't even expose those to the end user as a knob, while =
others might.<br class=3D""><br class=3D"">One more thing could be =
automatically figuring out best values based on<br =
class=3D"">libosinfo-provided data.<br class=3D""><br class=3D"">2) =
Policies<br class=3D""><br class=3D"">Lot of the time there are parts of =
the domain definition that need to be<br class=3D"">added, but nobody =
really cares about them. Sometimes it's enough to<br class=3D"">have=
few templates, another time you might want to have a policy<br =
class=3D"">per-scenario and want to combine them in various ways. =
For example with<br class=3D"">the data provided by point 1).<br =
class=3D""><br class=3D"">For example if you want PCI-Express, you need =
the q35 machine type, but<br class=3D"">you don't really want to care =
about the machine type. Or you want to<br class=3D"">use SPICE, =
but you don't want to care about adding QXL.<br class=3D""><br =
class=3D"">What if some of these policies could be specified once (using =
some DSL<br class=3D"">for example), and used by virtuned to merge them =
in a unified and<br class=3D"">predictable way?<br class=3D""><br =
class=3D"">3) Abstracting the XML<br class=3D""><br class=3D"">This is =
probably just usable for stateless apps, but it might happen<br =
class=3D"">that some apps don't really want to care about the XML at =
all. They<br class=3D"">just want an abstract view of the domain, =
possibly add/remove a device<br class=3D"">and that's it. We could =
do that as well. I can't really tell how much<br class=3D"">of a =
demand there is for it, though.<br class=3D""><br class=3D"">4) =
Identifying devices properly<br class=3D""><br class=3D"">In contrast to =
the previous point, stateful apps might have a problem<br =
class=3D"">identifying devices after hotplug. For example, let's =
say you don't<br class=3D"">care about the addresses and leave that up =
to libvirt. You hotplug a<br class=3D"">device into the domain and =
dump the new XML of it. Depending on what<br class=3D"">type of =
device it was, you might need to identify it based on different<br =
class=3D"">values. It could be <target dev=3D''/> for disks, =
<mac address=3D''/> for<br class=3D"">interfaces etc. For =
some devices it might not even be possible and you<br class=3D"">need to =
remember the addresses of all the previous devices and then<br =
class=3D"">parse them just to identify that one device and then throw =
them away.<br class=3D""><br class=3D"">With new enough libvirt you =
could use the user aliases for that, but<br class=3D"">turns out it's =
not that easy to use them properly anyway. Also the<br =
class=3D"">aliases won't help users identify that device inside the =
guest.<br class=3D""><br class=3D""><rant><br class=3D"">We really =
should've gone with new attribute for the user alias instead<br =
class=3D"">of using an existing one, given how many problems that is =
causing.<br class=3D""></rant><br class=3D""><br class=3D"">5) =
Generating the right XML snippet for device hot-(un)plug<br class=3D""><br=
class=3D"">This is kind of related to some previous points.<br =
class=3D""><br class=3D"">When hot-plugging a device and creating an XML =
snippet for it, you want<br class=3D"">to keep the defaults from point =
1) and policies from 2) in mind. Or<br class=3D"">something =
related to the already existing domain which you can describe<br =
class=3D"">systematically. And adding something for identification =
(see previous<br class=3D"">point).<br class=3D""><br class=3D"">Doing =
the hot-unplug is easy depending on how much information about<br =
class=3D"">that device is saved by your application. The less you =
save about the<br class=3D"">device (or show to the user in a GUI, if =
applicable) the harder it might<br class=3D"">be to generate an XML that =
libvirt will accept. Again, some problems<br class=3D"">with this =
should be fixed in libvirt, some of them are easy to<br =
class=3D"">workaround. But having a common ground that takes care =
of this should<br class=3D"">help some projects.<br class=3D""><br =
class=3D"">Hot-unplug could be implemented just based on the alias. =
This is<br class=3D"">something that would fit into libvirt as =
well.<br class=3D""><br =
class=3D"">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D<br class=3D""><br class=3D"">To mention some pre-existing =
solutions:<br class=3D""><br class=3D"">- I understand OpenStack has =
some really sensible and wisely chosen<br class=3D""> and/or tested =
default values.<br class=3D""><br class=3D"">- I know KubeVirt has =
VirtualMachinePresets. That is something closely<br class=3D""> =
related to points 1) and 2). Also their abstraction of the XML =
might<br class=3D""> be usable for point 3).<br class=3D""><br =
class=3D"">- There was an effort on creating policy based configuration =
of libvirt<br class=3D""> objects called libvirt-designer. This is =
closely related to points 2)<br class=3D""> and 3). Unfortunately =
there was no much going on lately and part of<br class=3D""> =
virt-manager repository has currently more features implemented with<br =
class=3D""> the same ideas in mind, just not exported for public use.<br =
class=3D""><br class=3D"">We could utilize some of the above to various =
extents.<br class=3D""><br class=3D"">Let me know what you think and =
have a nice day.<br class=3D"">Martin<br class=3D""><br class=3D"">-- =
<br class=3D"">You received this message because you are subscribed to =
the Google Groups "kubevirt-dev" group.<br class=3D"">To unsubscribe =
from this group and stop receiving emails from it, send an email to <a =
href=3D"mailto:kubevirt-dev+unsubscribe@googlegroups.com" =
class=3D"">kubevirt-dev+unsubscribe(a)googlegroups.com</a>.<br class=3D"">To=
post to this group, send email to <a =
href=3D"mailto:kubevirt-dev@googlegroups.com" =
class=3D"">kubevirt-dev(a)googlegroups.com</a>.<br class=3D"">To view this =
discussion on the web visit <a =
href=3D"https://groups.google.com/d/msgid/kubevirt-dev/20180320142031.GB23=
007%40wheatley" =
class=3D"">https://groups.google.com/d/msgid/kubevirt-dev/20180320142031.G=
B23007%40wheatley</a>.<br class=3D"">For more options, visit <a =
href=3D"https://groups.google.com/d/optout" =
class=3D"">https://groups.google.com/d/optout</a>.<br =
class=3D""></div></div></blockquote></div><br =
class=3D""></div></body></html>=
--Apple-Mail=_6D569541-1CA3-4944-AFE7-86FD31122B7D--
6 years, 10 months
UI is not coming up after pulled latest code from master
by Gobinda Das
Hi,
UI keeps on loading and I can see below error in browser.
webadmin-0.js:422 Wed Mar 21 14:59:47 GMT+530 2018
com.google.gwt.logging.client.LogConfiguration
SEVERE: Possible problem with your *.gwt.xml module file.
The compile time user.agent value (gecko1_8) does not match the runtime
user.agent value (safari).
Expect more errors.
com.google.gwt.useragent.client.UserAgentAsserter$UserAgentAssertionError:
Possible problem with your *.gwt.xml module file.
The compile time user.agent value (gecko1_8) does not match the runtime
user.agent value (safari).
Expect more errors.
at Unknown.L(webadmin-0.js)
at Unknown.oj(webadmin-0.js)
at Unknown.new pj(webadmin-0.js)
at Unknown.nj(webadmin-0.js)
at Unknown.nb(webadmin-0.js)
at Unknown.qb(webadmin-0.js)
at Unknown.eval(webadmin-0.js)
--
Thanks,
Gobinda
6 years, 10 months
[VDSM] Remove fcraw build as gating
by Edward Haas
Hi All,
Fcraw build on VDSM check-patch has been failing recently (again).
fcraw cannot act as gating to the VDSM CI, as it is unstable (by
definition).
If there is a strong interest for some to track VDSM against this unstable
distribution, it better be performed in parallel to the VDSM developing
flow.
With the current state, we are unable to trust the CI and it causes us to
either overwrite its output (which I consider very bad) or just get stuck
frequently.
Could we please move this job to be triggered once a day as a nightly job
and whoever is interested in its output to get notifications for it?
Please. lets not make it a gating to VDSM development.
Thanks,
Edy.
6 years, 10 months
[vdsm][maintainership] proposal for a new stable branch policy
by Francesco Romani
Hi all,
Recently Milan, Petr and me discussed the state of ovirt.4.2,
considering that release 4.2.2 is still pending and this prevents
merging of patches in the sub-branch ovirt-4.2.
We agreed we could improve the handling of the stable branch(es), in
order to make the process smoother and more predictable.
Currently, we avoid doing Z- branches (e.g. ovirt-4.2.2, ovirt-4.2.3...)
as much as we can, to avoid the hassle of double-backporting patches to
stable branch.
However, if a release hits unexpected delay, this policy causes
different hassles: the Y-branch (ovirt-4.2, ovirt-4.3) is effectively
locked, so patches already queued
and ready for next releases can't be merged and need to wait.
The new proposed policy is the following:
- we will keep working exactly as now until we hit a certain RC version.
We choosed RC3, a rule of thumb made out of experience.
- if RC3 is final, everyone's happy and things resume as usual
- if RC3 is NOT final, we will branch out at RC3
-- from that moment on, patches for next version could be accepted on
the Y-branch
-- stabilization of the late Z version will continue on the Z-branch
-- patches will be backported twice
Example using made up numbers
- We just released ovirt 4.3.1
- We are working on the ovirt-4.3 branch
- The last tag is v4.30.10, from ovirt-4.3 branch
- We accept patches for ovirt 4.3.2 on the ovirt-4.3 branch
- We keep collecting patches, until we tag v4.30.11 (oVirt 4.3.2 RC 1).
Tag is made from ovirt-4.3 branch.
- Same for tags 4.30.12 - oVirt 4.3.2 RC 2 and 4.30.13 - oVirt 4.3.2 RC
3. Both tags are made from ovirt-4.3 branch.
- Damn, RC3 is not final. We branch out ovirt-4.3.2 form branch
ovirt-4.3 from the same commit pointed by tag 4.30.13
- Next tags (4.30.13.1) for ovirt 4.3.2 will be taken from the
ovirt-4.3.2 branch
I believe this approach will make predictable for everyone if and when
the branch will be made, so when the patches could be merged and where.
The only drawback I can see - and that I realized while writing the
example - is the version number which can be awkward:
v4.30.11 -> 4.3.2 RC1
v4.30.12 -> 4.3.2 RC2
v4.30.13 -> 4.3.2 RC3
v4.30.13.1 -> 4.3.2 RC4 ?!?!
v4.30.13.5 -> 4.3.2 RC5 ?!?!
Perhaps we should move to four versions digit? So we could have
v4.30.11.0 -> 4.3.2 RC1
v4.30.11.1 -> 4.3.2 RC2
v4.30.11.2 -> 4.3.2 RC3
v4.30.11.3 -> 4.3.2 RC4
v4.30.11.4 -> 4.3.2 RC5
I don't see any real drawback in using 4-digit versions by default,
besides a minor increase in complexity, which is balanced by more
predictable and consistent
versions. Plus, we already had 4-digit versions in Vdsm, so packaging
should work just fine.
Please share your thoughts,
--
Francesco Romani
Senior SW Eng., Virtualization R&D
Red Hat
IRC: fromani github: @fromanirh
6 years, 10 months
