Hi Melanie,
We recommend using novncproxy_base_url with vncserver_proxyclient_address set
to the dom0's management IP address.
We don't currently use nova-console, so deprecation would be the best approach.
Thanks,
Bob
-Original Message-
From: melanie witt [mailto:melwi...@gmail.com]
> Yeah, the nova.CONF cpu_allocation_ratio is being overridden to 0.0:
The default there is 0.0[1] - and the passing tempest-full from Zuul on
https://review.openstack.org/#/c/590041/ has the same line when reading the
config[2]:
We'll have a dig to see if we can figure out why it's not default
We're not running with [1], however that did also fail the CI in the same way -
see [2] for the full logs.
The first failing appeared to be around Aug 27 08:32:14:
Aug 27 08:32:14.502788 dsvm-devstack-citrix-lon-nodepool-1379254
devstack@placement-api.service[13219]: DEBUG
nova.api.openstack.pl
Hi Matt,
My understanding is that this is being used by Rackspace.
AFAIK the change isn't upstream because there was no sensible way to permit
reboot of a rescued instance for XenAPI users but prevent it for other drivers.
I'd be hesitant to permit reboot-from-rescue for all drivers as I'm not
As far as I remember this isn't a nova-network only feature; but I may be
missing something.
I believe the bandwidth counters may be being used at Rackspace.
Bob
-Original Message-
From: Balázs Gibizer [mailto:balazs.gibi...@ericsson.com]
Sent: 16 April 2018 13:37
To: OpenStack-dev
Sub
2018 6:39 p.m.
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] Debian OpenStack packages switching to Py3 for
Queens
2018-02-15 11:25 GMT+01:00 Bob Ball :
> Hi Thomas,
>
> As noted on the patch, XenServer only has python 2 (and so
Hi Thomas,
As noted on the patch, XenServer only has python 2 (and some versions of
XenServer even has Python 2.4) in domain0. This is code that will not run in
Debian (only in XenServer's dom0) and therefore can be ignored or removed from
the Debian package.
It's not practical to convert thes
Hi Sahid,
> > a second device emulator along-side QEMU. There is no mdev
> > integration. I'm concerned about how much mdev-specific functionality
> > would have to be faked up in the XenServer-specific driver for vGPU to
> > be used in this way.
>
> What you are refering with your DEMU it's
Hi Sahid,
> Please consider the support of MDEV for the /pci framework which provides
> support for vGPUs [0].
From my understanding, this MDEV implementation for vGPU would be entirely
specific to libvirt, is that correct?
XenServer's implementation for vGPU is based on a pooled device model
>> Side note: we should first have Xen third-party CI testing running
>
> It already is running
> Oh right. It does not validate the new change though. Would be nice to see
> the new ‘daemon’-ic mode behaves in real world.
100% agreed. I'll work with Jianghua to make sure we get automated test
Hi Ihar,
> I am puzzled. Is Neutron the only component that need to call to dom0?
No it's not. Nova has similar code to call plugins in dom0[1], and Ceilometer
will also need to make the calls for some metrics not exposed through the
formal API.
We don't want code duplication, and are working
> > Oslo.privsep seem try to launch a daemon process and set caps for this
> daemon; but for XenAPI, there is no need to spawn the daemon.
>
> I guess I'm lacking some context... If you don't need special rights, why use
> a
> rootwrap-like thing at all ? Why go through a separate process to call
> TL;DR: If you don’t want a mascot, you don’t have to. But Nova, you’ll be
> missed. :-)
It also seems from http://www.openstack.org/project-mascots that the majority
of OpenStack projects have selected a mascot. I think it would be a great
shame if the Nova project didn’t have an easily reco
The ACL at
https://git.openstack.org/cgit/openstack-infra/project-config/tree/gerrit/acls/openstack/fuel-plugin-xenserver.config
shows that, in order for our CI to vote on the fuel-plugins-xenserver project,
we need to be in the fuel-plugins-ci group.
As such, could I request that the "Citrix X
Hi Masayuki,
We have been running against Tempest and commenting for many months (years?)
and run in the Rackspace public cloud so have no capacity issues.
Indeed the execution time is longer than other jobs, because we actually have
to use double nesting (Devstack running on Ubuntu in a VM und
How should we expose Virtual GPUs to Nova?
Various discussions have happened on the original spec submission for Mitaka[1]
and the recent submission for Newton[2], however there are a few questions
which need further discussion. But before those question (at the end), some
thinking behind the
The failure rate was indeed 100%; there were some requirements on packages not
installed in our CI environment (libssl-dev libffi-dev) which were causing all
failures.
This is now fixed and the CI is back to voting on passing changes. I have
re-queued all jobs which failed in less than 6 minut
Hi Sean,
> [section "XenServer"]
> query = label:Code-Review>=1,bob.b...@citrix.com file:xenserver
I believe this should be file:xenapi?
Can you match multiple files here? Most files are under the xenapi trees, but
it would miss some files in plugins/xenserver and not in
plugins/xenserver/xen
Hi Mikhail,
Unfortunately I completely agree that using Glance with the XenServer plugin is
painful. As Keven pointed out, the current release of XenServer includes
python 2.4 in dom0 (where the plugin runs) so having a dependency on nova.image
or glanceclient is likely to introduce more pain
> On Mon, Dec 21, 2015 at 1:43 PM, Igor Kalnitsky
> wrote:
> > What about hypervisor "Qemu", and checkbox option on Settings tab -
> > "Use KVM extension"?
> Qemu is not a hypervisor This will be even more confusing.
> I think "Libvirt" + some tooltip which says "Qemu and KVM" will be ok.
Libvirt
There was a conversation a while ago around explicitly avoiding the empty
namespace - see
http://lists.openstack.org/pipermail/openstack-dev/2014-July/041238.html
The approach I have used since is "xenserver: recheck" and "xen: recheck".
I think the appropriate command should be "fuel: recheck"
u will not be able to use
tempest in OFFLINE=true mode, but you may be able to use other services if you
remove tempest from ENABLED_SERVICES.
@jordan.pittier @Bob Ball
If I can ensure my IP address , localrc and everything else are not changed, is
there any way I can achieve my goal?
I don’t
Ah yes - I’d forgotten about OFFLINE=True (shows how often I use it!)
If you set this in your localrc file then yes, in theory it should work offline
– but will still generate a new environment when you reboot the VM.
Bob
From: yatin kumbhare [mailto:yatinkumbh...@gmail.com]
Sent: 23 November 2
Hi,
Devstack is intended for development, so when you reboot it is not expecting to
be able to preserve any information, and will give you a fresh environment to
continue development on.
The XenServer devstack installation uses a separate VM, but devstack is
automatically run at boot, as there
> I noticed today that nova.console.xvp hits the database directly for
> console pools. We should convert this to objects so that the console
> service does not have direct access to the database (this is the only
> console I see that hits the database directly). However, rather than go
> through t
> -Original Message-
> From: Anita Kuno [mailto:ante...@anteaya.info]
> Sent: 25 August 2015 01:44
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [all][third-party][ci] Announcing CI Watch -
> Third-party CI monitoring tool
>
> We have a number of people working on
Hi all,
To be able to involve some new sub-team members in China, we've moved the
meeting times as discussed in the last two XenAPI meetings.
The new time is at 0930 UTC, Alternate Wednesdays, with the next meeting at
0930 UTC on 8th July.
See you there!
Bob
_
Hi Anthony,
> The Xen script is simply calling those commands:
> ...
> iptables -I FORWARD -m physdev --physdev-is-bridged --physdev-in "$dev"
> -j ACCEPT
> iptables -I FORWARD -m physdev --physdev-is-bridged --physdev-out
> "$dev" -j ACCEPT
Are you saying that these two commands aren't neede
> -Original Message-
> From: John Garbutt [mailto:j...@johngarbutt.com]
> On 5 June 2015 at 15:29, Moshe Levi wrote:
> >
> > I talked also with John Garbutt and it seem that the recommendation is to
> filter only doc and test folders,
> > but still I would like to filter some other folders
Hi Gary,
It should have been included in the comment - what was the changeset that
failed?
For reference a recheck can be triggered with "xen: recheck"
Thanks,
Bob
From: Gary Kotton [mailto:gkot...@vmware.com]
Sent: 25 May 2015 16:21
To: OpenStack List
Subject: [openstack-dev] [nova] xen proj
Sorry all for this breakage; I've been on vacation and didn't set up adequate
cover.
Thanks for disabling it and we'll let everyone know when the job is ready to
start commenting and hopefully voting on changes in the very near future.
Regards,
Bob
From
Sorry for the late notice but due to travel we're cancelling this week's
meeting.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http
We certainly care about this but converting the XenServer CI to Neutron+OVS has
been hitting a number of issues (notably a few concurrency ones – although
there are a few missing features) that we’ve been trying to sort through.
I am certainly hoping that we’ll have everything stable enough to s
This is likely https://launchpad.net/bugs/1415795 which is fixed by
https://review.openstack.org/#/c/151506/
Make sure you have the above change in your devstack and it should work again.
Bob
From: liuxinguo [mailto:liuxin...@huawei.com]
Sent: 06 February 2015 03:08
To: OpenStack Development Ma
Hi,
The next meeting will be tomorrow @ 15:00 UTC - We'd love to see you there and
we can talk about the CI and Terry's work.
We're currently meeting fortnightly and skipped one due to travel, which is why
there haven't been minutes recently.
Thanks,
Bob
> -Original Message-
> From:
Hi Abhishek,
This is bug https://launchpad.net/bugs/1415795 introduced by
https://review.openstack.org/#/c/142967/ because Swift doesn't use olso.config.
The fix is at https://review.openstack.org/#/c/151506/ which has not yet been
approved, but if you can cherry-pick it for your CI it should g
Hi Yamamoto,
XenAPI and Neutron do work well together, and we have an private CI that is
running Neutron jobs. As it's not currently the public CI it's harder to
access logs.
We're working on trying to move the existing XenServer CI from a nova-network
base to a neutron base, at which point th
Hi Daniel,
The following is an example return value from one of my hosts
{"host_name-description": "Default install of XenServer", "host_hostname":
"ciceronicus", "host_memory": {"total": 17169604608, "overhead": 266592256,
"free": 16132087808, "free-computed": 16111337472}, "enabled": "true",
> -Original Message-
> From: Sean Dague [mailto:s...@dague.net]
> Sent: 25 July 2014 12:36
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [infra] "recheck no bug" and comment
>
> > Would that still allow us to only trigger 3rd party CI ? eg if we do
> > 'recheck xen
Hi Afef,
There was a regression in Icehouse that broke XenAPI aggregates. This has been
fixed in Juno, however we would recommend you use live migrate with block
migration (using XCP 1.6 or XenServer 6.2 – which is Free as well now, see
http://lists.openstack.org/pipermail/openstack-dev/2013-S
nted a fix - thanks for letting us know.
Bob
____
From: Bob Ball
Sent: 23 February 2014 20:29
To: David Kranz; #OpenStack External Email
Cc: OpenStack Development Mailing List
Subject: RE: [qa] Can't interpret failure from XenServer CI
Hi David,
That's
___
From: David Kranz [dkr...@redhat.com]
Sent: 23 February 2014 21:17
To: Bob Ball; #OpenStack External Email
Cc: OpenStack Development Mailing List
Subject: Re: [qa] Can't interpret failure from XenServer CI
On 02/23/2014 03:29 PM, Bob Ball wrote:
> Hi David,
>
> That's a very
Hi David,
That's a very strange error - it basically means the node has been used for
running a test already (both the first error in run_tests.log about the git
repository also existing, and the more fatal error about vif 3 existing)
I believe this was my fault - I should have purged all negat
> From: Russell Bryant [rbry...@redhat.com]
> Sent: 17 February 2014 22:41
> To: OpenStack Development Mailing List
> Subject: [openstack-dev] [Nova] Meetup Summary
>
> 5) Driver CI - We talked about the ongoing effort to set up CI for all
> of the compute drivers. The discussion was mostly a sta
Hi Thomas,
> I don't agree with this view. If there's no XCP in Debian, I don't see the
> point
> in supporting it in OpenStack. (and no, adding support for the "magical"
> Citrix CentOS appliance blackbox isn't something I wish to do...)
All use of XenAPI in OpenStack is through a VM - even if
Hi Thomas,
> This means that it will also be impossible to support XCP support in
> OpenStack, unfortunately (the support for XCP was removed a few months
> ago because that was blocking migration to Debian testing anyway).
Just a quick note - there are two separate issues here which some might c
Hi Mardan,
Assuming that you meant openstack rather than cloudstack(!) then check out the
guide at
http://blogs.citrix.com/2012/09/06/vhd-to-openstack-using-a-xapi-host-plugin/.
VHDs in OpenStack are actually a TGZ - since it can contain a VHD chain - with
each VHD renamed to "0.vhd", "1.vhd"
+1 here too - I'd love to be able to attend alternate weeks.
Bob
> -Original Message-
> From: Gary Kotton [mailto:gkot...@vmware.com]
> Sent: 18 December 2013 14:36
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Nova] Future meeting time
> -Original Message-
> From: Russell Bryant [mailto:rbry...@redhat.com]
> Sent: 26 November 2013 19:33
> To: OpenStack Development Mailing List
> Subject: [openstack-dev] [Nova] Proposal to re-add Dan Prince to nova-core
>
> I would like to propose that we re-add Dan Prince to the nova-cor
> -Original Message-
> From: Russell Bryant [mailto:rbry...@redhat.com]
> Sent: 26 November 2013 13:56
> To: openstack-dev@lists.openstack.org
> Cc: Sean Dague
> Subject: Re: [openstack-dev] [Nova] Hypervisor CI requirement and
> deprecation plan
>
> On 11/26/20
It's not certain that this will be implemented for the XenAPI driver.
Our view is that the BIOS strings shouldn't be relied upon - the hypervisor can
clearly set them to anything so it's not really a reliable way to configure the
application. Also note that in some scenarios, such as PV guests
> -Original Message-
> From: Russell Bryant [mailto:rbry...@redhat.com]
> Sent: 25 November 2013 22:37
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Nova] Hypervisor CI requirement and
> deprecation plan
>
> On 11/25/2013 05:19 PM, Matt Riedemann wrote:
> > I'll p
The trace below seems to be wanting to access the console log, rather than the
VNC console.
I believe there is a blog post about how to enable this, but basically you need
a cronjob to run in dom0 to rotate the logs. This is because the Xen console
logging is not ring-based, and therefore with
Hi Simon,
Yes, I believe you are right.
We were already planning to discuss this very topic at the XenAPI roadmap
session at the summit. Hopefully someone will take on tying up this loose end
there.
Security group support is the only thing we are aware of that is missing from
the XenAPI neut
Hi Parikshit,
More details can be extracted by setting debug=true in /etc/nova/nova.conf or
setting default_log_levels to include nova.virt.xenapi.driver=debug.
This is likely to be a mis-configured nova.conf - check
http://docs.openstack.org/trunk/openstack-compute/install/yum/content/introduc
I'm happy with that approach - again I've not seen any discussions about how
this should be done.
I've added [tempest] and [ceilometer] tags so we can hopefully get input from
the guys involved.
Bob
From: Gary Kotton [mailto:gkot...@vmware.com]
Sent: 13 October 2013 05:21
To: OpenStack Develop
From: Alessandro Pilotti [apilo...@cloudbasesolutions.com]
Sent: 12 October 2013 20:21
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Hyper-V] Havana status
> 1) All the drivers will still be part of Nova.
>
> 2) One official project
> -Original Message-
> From: Russell Bryant [mailto:rbry...@redhat.com]
> Sent: 11 October 2013 15:18
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Hyper-V] Havana status
>
> > As a practical example for Nova: in our case that would simply include the
> following
Just a quick note to say that we're skipping the XenAPI meeting this week as a
couple of key participants have other commitments.
Normal service will resume next week.
Bob
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.
The blueprint currently seems libvirt specific to me? Is there a common -
perhaps abstracted - interface that we can provide through Nova / image
meta-data which will be implemented by each driver in their own way?
Otherwise I can see a bigger mess of metadata values where libvirt uses
enable_
[mailto:dtro...@gmail.com]
Sent: 18 September 2013 15:04
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [DevStack] Generalize config file settings
On Wed, Sep 18, 2013 at 7:49 AM, Bob Ball
mailto:bob.b...@citrix.com>> wrote:
In which case, would a simple fix of adding a &q
ean Troyer [mailto:dtro...@gmail.com]
Sent: 18 September 2013 13:37
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [DevStack] Generalize config file settings
On Wed, Sep 18, 2013 at 4:46 AM, Bob Ball
mailto:bob.b...@citrix.com>> wrote:
I understand that there are some very g
The biggest concern I have about the current implementation is that it handles
conf files inconsistently - but as Dean pointed out on the review it opens a
wider question. I will very often run devstack, find something not quite
working unstack, change a value or two in localrc and then re-run
Puppet is failing to build the packages - which is probably understandable
given it's a refactor.
I'm not sure if this is something that points to a problem with the refactor or
the packaging itself - hopefully Dan can review the logs, or if others want to
see more of the details look at the lo
I've received a number of questions recently about XenServer and XCP and how
they are different - particularly now that XS 6.2 has been released - so
thought I should try and get the answers all in one place.
XenServer:
As of XS 6.2, it was announced that it will be fully open sourced[1] and all
I agree with the below from a XenServer perspective. As with vmware, XenServer
supports live snapshotting and creating multiple clones from that live snapshot.
I understand that there is a XenAPI equivalent in the works and therefore would
argue the API changes need to be accepted as a minimum.
I'm running the unit tests and can confirm they do work.
I'm currently developing support for xenserver-core on CentOS 6.4 and many of
the tempest tests pass, and I'm working through the failures that exist.
I haven't encountered anything yet which is caused by CentOS so I imagine it
will all w
Hi Brian,
Instead of specific GPU pass-through there are blueprints for generic PCI pass
through at https://blueprints.launchpad.net/nova/+spec/pci-passthrough-base -
these are being worked on for Havana and we're hopeful they will get in
(possibly libvirt only)
In terms of vGPU rather than w
I think we need a further constraint:
We must ensure that yum/etc believes that the python-* packages are installed.
There are a number of packages that we are currently purging in devstack due to
the redhat/pip conflict which we cannot purge (e.g. python-lxml, python-c
rypto) as they will remo
The CFP is at
http://events.linuxfoundation.org/events/linuxcon-north-america/program/xen-project-user-summit
- this is for the Xen User Summit as part of linuxcon.
While it might not have OpenStack in the title, I'm aware of at least one talk
which has already been submitted with a strong Open
+1 from me too.
From: Russell Bryant [rbry...@redhat.com]
Sent: 26 June 2013 16:09
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Nova] Nominating John Garbutt for nova-core
Greetings,
I would like to nominate John Garbutt for the nova-co
Development Mailing List
Subject: Re: [openstack-dev] Efficiently pin running VMs to physical CPUs
automatically
On Fri, Jun 21, 2013 at 09:10:32AM +, Bob Ball wrote:
> It seems that numad is libvirt specific - is that the case?
No, it is a completely independant project
https://g
It seems that numad is libvirt specific - is that the case?
I'm not sure if there is a daemon for other hypervisors but would it make sense
to have this functionality in OpenStack so we can extend it to work for each
hypervisor allowing it to control the affinity in their own way? I guess this
| Activator | Relator | Responsibility
Phone: (512) 788 5403 – Cell: (512) 736-7897 (Austin)
Skype: rtgoodwin - Yahoo:
richardtgoodwin
AIM: dellovision - IRC: goody / rgoodwin
From: Bob Ball mailto:bob.b...@citrix.com>>
Reply-To: OpenStack Development Mailing List
mailto:openstack-dev@lists
anager - Cloud Servers & Cloud Images
Ideation | Intellection | Activator | Relator | Responsibility
Phone: (512) 788 5403 - Cell: (512) 736-7897 (Austin)
Skype: rtgoodwin - Yahoo:
richardtgoodwin
AIM: dellovision - IRC: goody / rgoodwin
From: Bob Ball mailto:bob.b...@citrix.com>>
Repl
I'm not sure I understand why the user might want to access the disk_config
value from within the guest?
This seems to be something they could infer from the partition structure - i.e.
if the whole drive is partitioned then disk_config was AUTO when the instance
was created.
Bob
From: Navneet
76 matches
Mail list logo
