[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Wg-openstack] Minutes from Sept 21 Openstack WG meeting



On 09/21/2016 11:25 AM, Lars Kurth wrote:
> @ Andy: there is some stuff related to CPUID levelling, which is why you
> are CC'ed
>
> == Attendees ==
> Joao Martins (Oracle)
> Cedric Bosdonnat (SUSE)
> Anhtony Perard (Citrix)
> Jim Fehlig (SUSE)
> Lars Kurth (Citrix)
>
> == Introductions ==
> Lars: Xen project community manager, and advisory board chairman
> Joao: Working on Xen and Oracle Products based on Xen. Working on libvirt
> and networking IO
> Cedric: Jumped into libvirt and containers 3 years, libgustfs, libxl
> driver together with Jim (SUSE)
> Antony: QEMU, OpenStack CI loop, OpenStack work (on the side) (SUSE)
> Jim: Suse, occasional Xen upstream contributor, libvirt contributor
>
> == Agenda ==
>
> === New libvirt libxl features since last call ==
> See 
> https://www.youtube.com/watch?v=rSXb1g4rJ3w&list=PLYyw7IQjL-zEcw-9M5YWzAwXj
> 9mlOKZnU&index=4
>
> Jim: 
> Cinder volumes backed by ceph are now supported
> May need to look at Tempest tests to see whether there are such tests
> May need to upgrade what we test
>
> Lars: do we have a list of tests that are disabled
> Joao: posted some time ago on the list
>
> ACTION: Joao will have a look and check what could be enabled and whether
> libvirt + Xen needs to be upgraded in the CI loop
>
> === libvirt libxl features in progress or planned ===
>
> ==== In progress features
>
> Port for XenChannels (Joao) :
> allows sys prepping type activities to guess agents and cloud tools.
>
> Joao: will be sending another version (today or tomorrow)
>
>
>
> ==== Planned features
>
> * Guest agent commands using the Channels functionality
> Joao: qemu-agent support is deferred to the next release
> Joao: as far is I am aware, Nova uses missing qemu-agent APIs in
> setuserpassword, snapshot, freeze and thaw ...
>
> Lars: may be able to re-enable some tests with a newer version.
> Joao: May need to update the CI loop to use newer
>
> * Status update on CPUID support :
> Joao had a series which was committed which propagates more CPU info
> (sockets, ... , host and CCPU capabilities).

For example, Joao's work added the following to host capabilities

    <cpu>
    ...
      <model>IvyBridge</model>
      <topology sockets='2' cores='12' threads='2'/>
      <feature name='ds'/>
      <feature name='acpi'/>
      <feature name='ht'/>
      <feature name='tm'/>
      <feature name='pbe'/>
      <feature name='dtes64'/>
      <feature name='monitor'/>
      <feature name='ds_cpl'/>
      <feature name='vmx'/>
      <feature name='smx'/>
      <feature name='est'/>
      <feature name='tm2'/>
      <feature name='xtpr'/>
      <feature name='pdcm'/>
      <feature name='pcid'/>
      <feature name='dca'/>
      <feature name='xsaveopt'/>
      <feature name='pdpe1gb'/>
      <feature name='invtsc'/>
    </cpu>

His work also included support for 'virsh cpu-compare' and 'virsh cpu-baseline'.
cpu-compare can be used to determine if the host's cpu is compatible with a cpu
described in an XML file (e.g. collected from another host). cpu-baseline can be
used to compute a baseline cpu from an XML file containing several host cpu
descriptions. So we are now able to compare host cpus to see if they are
compatible and compute a baseline cpu from a collection of host cpu
descriptions. What remains is the ability to control the guest cpu description.

>  Next step is to wire up this
> in libxl.
> Jim: wanted to check whether Joao is doing anything in this area (up to
> Xen 4.7)
> Joao: now we are supporting strictly host passthrough mode. The levelling
> part still requires some work on libxl. Am experimenting and speccing out
> these features. Will post on xen-devel. Implementing full policy support
> on libxl coordinating with Andy Cooper.
>
> * CPUID levelling at DevSummit:
> https://www.youtube.com/watch?v=vb3RrjiZckw&index=23&list=PLYyw7IQjL-zEcw-9
> M5YWzAwXj9mlOKZnU
>
>
> Lars: CC Wei and Andy to ask what CPUID and start coordinating to see
> whether this is something we can get into Xen 4.9
>
> * Feature / Bug ... Deadlock in libvirt caused by libxl
> Jim: was surprised that an upstream bug report (1 a year ago, again one 2
> months ago which essentially encounters a deadlock in libvirt caused by
> libxl). 
> Had a fix for this: then forgot about it, but working on it again
>
> Jim: Any observation of libvirtd deadlock in the CI loop?
> Anthony: Have not seen anything
> Jim: can be reproduced under heavy load test (needs lots of save/restore
> in parallel and it will take days to see it). Just be aware that if there
> are instances where libvirtd is locked up, Jim is working on it

Patch posted upstream that is working fine in my test setup

https://www.redhat.com/archives/libvir-list/2016-September/msg00970.html

Looking forward to feedback from the upstream reporters.

>
> * Jim: misc items not necessarily relevant for OpenStack
> OpenVSwitch in Xen: not sure whether this is a big deal for OpenStack
> USB (PV, Emulated, ...): and a few others
>
> * Other planned / ongoing work
>
> Bob: is working on turnoff migration (default enabled on openstack P2P
> migration). Expect to see patches at some point. Also working on other
> stuff.
>
> Joao: multi-serial support went into libvirt 2.2. Does not look relevant,
> but is relevant for HVM guests and OpenStack. When you get an empty file,
> you get an empty console. Allows us to behave more like Nova. 1st serial
> is written to a file, the 2nd serial is written to the console.
>
> * Any outstanding libvirt libxl patches
>
> None
>
> * Upcoming deadlines:
> 4.8 freeze coming: Sept 30
>
>
> === Stuck stuff ===
>
> * https://bugs.launchpad.net/nova/+bug/1450465 (no-one looking at that)
> Joao: not sure how this can be fixed
> Joao: on some Nova releases this works, but with Neutron it doesn't work
> Joao: issue with OpenStack assumptions
> Jim: The only way it solve this is to increase the buffer size
> Joao: any Xen related fix would create a backwards compatibility issue
> Jim: not able to specify "want to have PV only", "want to have" ... the
> default getting both to os hard to change the default ...
> Jim: instance fails to start because the name is too long we fail the
> whole thing
> Joao: name is taken straight from a UID
>
> ACTION: Lars it chat to Bob Ball / Platform Team to see whether how XS is
> working around this or whether there is a way to fix this
>
> * https://review.openstack.org/#/c/264101/ (abandoned, but maybe shouldn't
> be - see Jim's last comment)
> Similar set of backwards compatibility issues
> Using pygrub in cloud environments does not seem wise
> Certain instance types don't work with PVGRUB ...
> Would have to look into how Nova uses this stuff
> Identify what issues we would face with PVGRUB only
> Joao: Doesn't Daniel Berrange have a voting opinion on this?
> Joao: Patch doesn't look intrusive and doesn't need to be the default.
> Seems quite harmless for normal users.
> Lars: Thomas is a SUSE employee - maybe Jim, Cedric ...can
>
> * https://review.openstack.org/#/c/201257/
> Lars to follow up with Bob Ball to see what needs to be done to get this
> in shape, given that Bob voted -1
>
> === Documentation ===
>
> ACTION: all review 
> http://docs.openstack.org/mitaka/config-reference/compute/hypervisor-xen-li
> bvirt.html and let Lars know whether we need to update docs

I did a quick read and didn't notice anything wrt version numbers, know issues,
etc. that needs updated.

Regards,
Jim


_______________________________________________
Wg-openstack mailing list
Wg-openstack@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/cgi-bin/mailman/listinfo/wg-openstack

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.