I think you should be able to modify nova/manager.py to be able to store and
report a list of capabilites and report them all individually to the scheduler
via the periodic task.
Vish
On Aug 21, 2012, at 1:28 PM, David Kang wrote:
>
> Hi Vish,
>
> We are trying to change our code accordin
No it is not possible to do this with flaoting ips. Floating ips are not
visible to the instance and they are natted by the network host to the first
fixed ip of the guest.
It is possible to configure nova to give multiple fixed ips to a single vm on
different interfaces, but configuring it is
This is currently not supported by OpenStack. We have localization support
but it is host-configured and it doesn't vary based on an accept-header.
This seems like a very useful feature to get in for the next release, however.
Vish
On Aug 21, 2012, at 6:36 AM, boden wrote:
> All,
>
> Although
On Aug 17, 2012, at 1:00 PM, Lars Kellogg-Stedman wrote:
>> This is not possible. Sounds like you really want a fix for this bug:
>>
>> https://bugs.launchpad.net/nova/+bug/914484
>>
>> The fix was reverted but hopefully it can be cleaned up and come back in.
>
> That looks like it would get
On Aug 16, 2012, at 6:58 AM, Lars Kellogg-Stedman wrote:
> I have a system that I've booted using a live CD image (so
> .../instance-/disk points at the ISO file). I've installed an OS
> onto /dev/vda (which is .../instance-/disk.local).
>
> Running 'nova image-create ` results in a traceback
Hello Everyone,
We had another productive nova-meeting today. We granted a few feature freeze
exeptions to stuff that just missed F-3 and we pushed a few features to
Grizzly. Detailed (and slightly cleaned up notes are below.
Vish
Meeting summary
---
* Role Call (vishy, 21:01:36)
This was an immediate goal, the bare-metal nova-compute node could keep an
internal database, but report capabilities through nova in the common way with
the changes below. Then the scheduler wouldn't need access to the bare metal
database at all.
On Aug 15, 2012, at 4:23 PM, David Kang wrote:
On Aug 15, 2012, at 3:17 PM, Michael J Fork wrote:
> I am interested in finding a solution that enables bare-metal and virtualized
> requests to be serviced through the same scheduler where the compute_nodes
> table has a full view of schedulable resources. This would seem to simplify
> the
On Aug 14, 2012, at 10:00 PM, Chuck Thier wrote:
>
> I could get behind this, and was was brought up by others in our group
> as a more feasible short term solution. I have a couple of concerns
> with this. It may cause just as much confusion if the api can't
> reliably determine which device
On Aug 14, 2012, at 10:52 PM, Kurt Scholtens wrote:
> Vish -
>
> Thank you for responding. So, when using multiple interfaces, will setting
> the PUBLIC_INTERFACE to the separate interface w/o VLANing work? Is that
> what you are saying below? Are any additional configuration parameters t
On Aug 14, 2012, at 7:55 PM, "Wangpan" wrote:
> How about using the pci address as the UUID of target devices in one VM?
> the pci address is generated by libvirt and we can see it in VM by cmd "ls
> -la /sys/block/",
> and it has no dependency with the kernel version, I can see it in 2.6.32*
>
On Aug 14, 2012, at 1:24 PM, Kurt Scholtens wrote:
> Any takers?
>
> I am looking for guidance on my current deployment. Let me start by saying,
> it works. That being said, I want to ensure what I am doing makes sense
> because I'm slightly confused by the networking. Specifically, the b
it is an action on a server so you want:
v2/{tenant_id}/servers/{server_id}/action
{
"addFloatingIp": {"address": "10.100.20.7"}
}
Python-novaclient is very helpfel for this kind of thing try nova --debug
add-flaoting-ip :
…
REQ: curl -i
http://192.168.27.100:8774/v2/cd1a46fd42ab43c9a8e
Hey Everyone,
Overview
One of the things that we are striving for in nova is interface consistency,
that is, we'd like someone to be able to use an openstack cloud without knowing
or caring which hypervisor is running underneath. There is a nasty bit of
inconsistency in the way that d
This patch would be most welcome.
Vish
On Aug 13, 2012, at 12:25 PM, Rafi Khardalian wrote:
> We ran into this issue as well and just patched a fix into our
> distribution. Basically, the patch will re-establish iSCSI connections
> anytime an instance is hard rebooted. The Nova configuration
This is up to dan, I suppose, but the rootwrap stuff seems like something worth
granting a ffe to…
Vish
On Aug 13, 2012, at 11:49 AM, j...@redhat.com wrote:
>> From: j...@redhat.com
>> Date: Fri, 10 Aug 2012 11:52:49 -0400
> [...]
>> Very much, thanks. More news as it happens...
>
>
On Aug 10, 2012, at 6:24 AM, Patrick Petit
wrote:
> Hi,
> So, if I paraphrase correctly what is meant out of the stacker jargon.
>
> min_count and max_count doc will go in the API doc as an extension item once
> the DisableServerExtension cleanup is done. Right?
Correct.
>
> However, the
On Aug 9, 2012, at 7:31 PM, Xin Zhao wrote:
> Hello,
>
> In my essex install on RHEL6, there is a problem with the metadata service.
> The metadata service works for instances running on the controller node, where
> the nova-api(metadata service) is running. But for the other worker nodes,
> th
On Aug 9, 2012, at 6:28 PM, Daryl Walleck wrote:
> As part of my work on Tempest, I've created an alternate backend
> configuration to use XML requests/responses. This right now mostly covers
> Nova, but could easily be extended to test other projects as well. I hadn't
> pushed it yet because
On Aug 9, 2012, at 3:32 PM, George Reese wrote:
> Why aren't the integration tests both XML and JSON?
The simple answer is that no one has taken the time to write them. Our devstack
exercises use the python client bindings. Tempest has json clients but no xml
clients[1]. I think this demonstr
On Aug 9, 2012, at 1:56 PM, Sébastien Han wrote:
>
> Did I miss something?
Unfortunately this is confusing because the term metadata is used for two
different things.
the metadata visible to the instance is a replication of the aws metadata
server. it is constructed from the database (most
Hello Everyone,
We are in the unfortunate position of not knowing how good our OpenStack API
XML support is. All of our integration tests use json. Many of the compute
extensions don't even have XML deserializers. We also assume that there bugs we
don't even know about due to underuse. We need
Hello Everyone,
The nova meeting today was quite eventful. Minutes are included below. A couple
of important updates:
* we are putting nova-core review days on hold.
* nova-core is going to pay extra attention to reviewing so that we can get
everything merged by Tuesday
* after F-3 nova-core
On Aug 9, 2012, at 8:13 AM, Robert Kukura wrote:
> We should immediately change devstack to stop running the quantum agents
> as root, so at least the root_helper=sudo functionality is really being
> used.
>
> It looks like devstack does configure nova with the new
> rootwrap/rootwrap_config an
On Aug 9, 2012, at 7:13 AM, "Daniel P. Berrange" wrote:
>
> With non-live migration, the migration operation is guaranteed to
> complete. With live migration, you can get into a non-convergence
> scenario where the guest is dirtying data faster than it can be
> migrated. With the way Nova curre
On Aug 9, 2012, at 1:03 AM, Blair Bethwaite wrote:
> Hi Daniel,
>
> Thanks for following this up!
>
> On 8 August 2012 19:53, Daniel P. Berrange wrote:
>> not tune this downtime setting, I don't see how you'd see 4 mins
>> downtime unless it was not truely live migration, or there was
>
> Ye
No need to edit code, there is a config option for this:
## (MultiStrOpt) mkfs commands for ephemeral device. The format is
=
Put the following in nova.conf:
virt_mkfs=default=mkfs.ext4 -L %(fs_label)s -F %(target)s
On Aug 6, 2012, at 3:02 AM, Sébastien Han wrote:
> Hi,
>
> I think thi
Hi Gaurab,
Openstack is not a hypervisor, it is a management layer that sits on top of a
hypervisor. Management of the guest filesystem and memory is all done by an
underlying hypervisor, Generally KVM or Xen. KVM is essentially kernel module
extensions for QEMU (which is a software emulator).
On Aug 2, 2012, at 1:05 PM, Eric Windisch wrote:
> The scope of common is expanding. I believe it is time to seriously consider
> a proper PTL. Preferably, before the PTL elections.
+1
___
Mailing list: https://launchpad.net/~openstack
Post to :
Which version of the code are you using? This could potentially be a bug.
Can you give some more information on what goes wrong with creating an instance?
Do you get a traceback anywhere?
Vish
On Aug 2, 2012, at 1:23 PM, Mitchell Broome wrote:
> I'm using essex 2012.1 and I'm running into an is
The create command via cidr is just a convienience to create a bunch of
floating ips at once, floating ips are actually individual entries in the db.
It should skip the network and gateway addressses by default, but it is
perfectly acceptable to delete individual addresses with
nova-manage floa
Hello Everyone,
Just a quick reminder that we are having a nova team meeting today at 2100 UTC.
That is 2PM on the West Coast, and 4PM Central. Check your city/timezone here:
http://www.timeanddate.com/worldclock/fixedtime.html?hour=21&min=0&sec=0
The agenda is located at:
http://wiki.openstac
On Aug 2, 2012, at 7:35 AM, Lars Kellogg-Stedman wrote:
>
> With a multi_host, flatDHCP model, is the general idea that fixed_ips
> are -- generally -- internal to the compute host, and all external
> access is supposed to be via floating ips? That's sort of how it
> looks, but I hadn't seen t
You will likely have to write a nova-volume/cinder backend to talk to the dell
SAN directly. You could probably base it on the HP lefthand san code and get
something working pretty quickly:
https://github.com/openstack/nova/blob/master/nova/volume/san.py
Vish
On Aug 2, 2012, at 2:31 AM, Bilel
On Aug 1, 2012, at 12:10 PM, Samuel Winchenbach wrote:
> Hi All,
>
> I have been tasked with creating an openstack cloud on a cluster at the
> University of Maine. Here is a rough diagram of the planned network
> network setup: http://dl.dropbox.com/u/22341705/network-layout.jpg
> wher XXX.YYY
On Aug 1, 2012, at 9:35 AM, Lars Kellogg-Stedman wrote:
>
> For outbound access, it's not clear why the flat_network_bridge needs
> to be connected to an actual physical interface...since everything
> goes out public_interface, I'm not sure what flat_interface is for.
Traffic from vm to vm on
On Aug 1, 2012, at 9:00 AM, "Day, Phil" wrote:
> Hi Folks,
>
> Looking at the current policy.json file both falvorextraspecs and
> flavorextradata are set to “[]”, whereas flavormanage is [[“rule:admin_api”]]
>
> Seems to me that all three of these should be admin_api – or am I missing
> s
On Jul 31, 2012, at 10:09 PM, Brian Waldon wrote:
>
> I do agree that this current upgrade story could be better, but how much
> better do you expect it to be and in what specific ways? If the command-line
> interface were backwards-compatibile, would that solve all your problems? I'm
> fine
Communication should be blocked via security groups, but perhaps you want more
complete isolation. The network host (which in this case is the compute host)
will be able to route packets between subnets even though they are on different
networks, so you will need to drop packets between vlans.
For now it is fine to put it in the same place where network_id is specified.
In the nova meeting on Thursday, we are going to discuss a better way to do
extensions that need to do things based on additional post params.
Vish
On Jul 31, 2012, at 12:30 AM, Nati Ueno wrote:
> Hi Dan
>
Mat
Hello Everyone,
It was recently suggested that we start a weekly nova team meeting. We used to
use the release meeting to discuss nova issues, but due to the proliferation of
projects, there isn't time to get deeply into nova. Also, it seems that
nova-core could communicate a bit more, so we ar
On Jul 27, 2012, at 10:18 AM, Mark Collier wrote:
> I do wonder if it would make sense to gather user feedback and goals before
> the summit, like the day (or week) before, to help provide some priorities
> (from their perspective) to consider going into the summit.
This does seem valuable,
Hello Everyone
Please welcome Yun Mao, Padraig Brady, and Michael Still to nova-core. Sean
Dague needs two more core +1s by tomorrow to be added.
Also we have a lot of untrained bugs here:
https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New
It be great if everyone (including t
Hello Everyone,
Here are the current vote counts from nova-core members on the 4 new core
member proposals from last week:
Yun Mao: 7
Padraig Brady: 6
Michael Still: 5
Sean Dague: 2
That is enough votes for the first three. If they don't get any -1s by
Wednesday, They will be joining nova-core
Hello Everyone,
When I was going through the list of reviewers to see who would be good for
nova-core a few days ago, I left one out. Sean has been doing a lot of reviews
lately[1] and did the refactor and cleanup of the driver loading code. I think
he would also be a great addition to nova-cor
Hello Everyone!
Michael wrote the image cache management code, did all of the remaining
conversions of instance_id -> instance_uuid, and has been contributing a lot to
reviews[1]. I think he would make a great addition to nova-core.
[1] https://review.openstack.org/#/dashboard/2271
Vish
Hello Everyone!
Yun has been putting a lot of effort into cleaning up our state management, and
has been contributing a lot to reviews[1]. I think he would make a great
addition to nova-core.
[1] https://review.openstack.org/#/dashboard/1711
Vish
_
Hello Everyone!
Padraig has been contributing a lot of code to all parts of nova, and has been
contributing a lot to reviews[1]. I think he would make a great addition to
nova-core.
[1] https://review.openstack.org/#/dashboard/1812
Vish
___
Mailing
On Jul 18, 2012, at 9:44 AM, Boris-Michel Deschenes wrote:
> Thanks everybody,
>
> Vish, I think you’ve got it, but here are some more details about the setup
> just to be sure we’re on the same level:
>
> my private network is defined as 172.0.0.0/21
> my floating network is defined as 10.1
Hi Boris,
There must be something misconfigured in your setup. Nova network shouldn't be
snatting for other vms. Are your machines outside the cloud also in the 10/8
range? if so you should change the setting for fixed_range to something smaller
so it doesn't snat for your other machines. For e
So creating the configuration file used to be done automatically via a
nova-manage project zipfile, but it got removed along with the deprecated auth
removal. A user should be able to generate the required certificate and private
key from nova using novaclient via:
nova x509-create-cert (it dow
The only way currently is to delete the records from the services table in the
database.
Vish
On Jul 13, 2012, at 5:27 AM, Alessandro Tagliapietra wrote:
> Hello list,
>
> i've this problem, when i run nova-manage service list i get
>
> nova-compute server1.site.it nov
On Jul 12, 2012, at 2:36 PM, David Mortman wrote:
> On Thu, Jul 12, 2012 at 3:38 PM, Vishvananda Ishaya
> wrote:
>
> Two thoughts:
>
> 1) I think this is the wrong forum to poll operators on their
> preferences in general
>
> 2) We don't yet even have a fully
On Jul 12, 2012, at 2:22 PM, Narayan Desai wrote:
> I think that the long term maintenance or removal of nova-volume in
> its existing form is orthogonal to the actual issue of continuity from
> one release to the next.
Agreed. Discussion the volume/cinder strategy is a separate topic. I've
take
On Jul 12, 2012, at 11:48 AM, Christopher B Ferris wrote:
> This level of response is unnecessary.
>
> That said, the perspectives which influenced the decision seemed somewhat
> weighted to the development community. I could be wrong, but I did not see
> much input from the operations commun
Hello Everyone,
Now that the PPB has decided to promote Cinder to core for the Folsom
release, we need to decide what happens to the existing Nova Volume
code. As far as I can see it there are two basic strategies. I'm going
to give an overview of each here:
Option 1 -- Remove Nova Volume
===
It looks like the ip for your hosts is in the 10./8 range which is probably
messing up routing and snatting. You will need to use a smaller range when
you create your vm network, say 10.75.0.0/16 and make sure you set
fixed_range to the same value in nova.conf
For metadata, you may have to set met
On Jul 3, 2012, at 11:51 AM, Scott Moser wrote:
> On Tue, 3 Jul 2012, Vishvananda Ishaya wrote:
>
>> Metadata is supposed to be user "tags" that are associated with a guest
>> that are available via the api. We discussed displaying these tags inside
>> the g
I like the security of this idea, but it would also require that metadata is
available outside the vm which it isn't. What about creating a security group
that opens a specific port, and run a little webserver on that port in the
guest that makes the key available. That would mean you don't nee
Metadata is supposed to be user "tags" that are associated with a guest
that are available via the api. We discussed displaying these tags inside
the guest as well.
The main difference between user-data and metadata is that metadata is
available to the api, whereas user-data is only available in t
On Jul 2, 2012, at 7:28 AM, Jay Pipes wrote:
> Hi Ron, cc'ing the openstack ML for extra eyes and opinions...
>
> So, Nati and I are looking to use either the osops chef-repo or
> something similar as the basis of the new TryStack zone chef deployment.
> I've been going through the recipes and r
Seems like you could use a floating ip for this. You can define a range for
internal floating ips by using a separate floating ip pool.
On Jun 29, 2012 7:06 PM, "Christian Parpart" wrote:
> Hey all,
>
> I would like to setup a highly available service *inside* two KVM
> instances,
> so I have cre
those are supposed to be ip addresses, so I would go with doc bug now unless
there is a good reason to change it.
Vish
On Jun 28, 2012, at 12:00 PM, Lars Kellogg-Stedman wrote:
> Maybe I sent this out too late at night; I think it slipped below
> everyone's radar. I'm interested in whether or
On Jun 28, 2012, at 8:13 AM, Monty Taylor wrote:
> Which adds an additional testing environment that has system software
> enabled and also installs additional "optional" things. With that
> environment, we should be able to run a jenkins gate that tests things
> with full libvirt, and also tests
tl; dr
It allows us to version up the internal apis to move towards seamless upgrades.
Blueprint:
https://blueprints.launchpad.net/nova/+spec/versioned-rpc-apis
Some discussion from the ml:
http://www.gossamer-threads.com/lists/openstack/dev/11811
usage instructions:
https://lists.launchpa
This looks like virus initiated spam to me. I recommend not clicking this link
Vish
On Jun 27, 2012, at 1:15 PM, Jayashree(Jay) Beltur wrote:
> http://katierefling.com/blog/wp-content/themes/pyrmont-v2/ybkrz.html
> ___
> Mailing list: https://launchpad
On Jun 27, 2012, at 3:52 AM, Daniel P. Berrange wrote:
> The following document presented for discussion is based on my
> experiance over the past few months getting involved with OpenStack
> Nova through learning the codebase, examining its history, writing
> code and participating in reviews. I
We generally add methods to the fake as they are needed by the implementation.
You should probably add the needed methods and return fake values.
Vish
On Jun 27, 2012, at 7:17 AM, Leander Bessa Beernaert wrote:
> I've been looking at the implementation of the tests and i the fake_libvirt
> is
On Jun 21, 2012, at 7:29 AM, Thierry Carrez wrote:
>
>
> * Run BugTriage days more often ?
> We could have regular (monthly?) Nova Bugtriage days to get rid of what
> accumulated in the mean time. But I fear that urgent bugs might not get
> the attention they deserve, and that over time less and
Yessir.
The issue (which was very annoying to track down) is the nova_ipam_lib is
loaded by default, and it trickily was unsetting the timeout_fixed_ips setting
of FlatDHCPManager with the (seemingly innocuous):
self.net_manager.timeout_fixed_ips = not self.net_manager.DHCP
Vish
On Jun
Found the issue.
Fix here: https://review.openstack.org/9026
On Jun 26, 2012, at 12:13 PM, Lars Kellogg-Stedman wrote:
>> A rebuild of this would probably work:
>> http://ftp.redhat.com/pub/redhat/linux/enterprise/6Workstation/en/os/SRPMS/dnsmasq-2.48-6.el6.src.rpm
>
> Thanks for the pointer!
On Jun 26, 2012, at 9:55 AM, Lars Kellogg-Stedman wrote:
>
> It does not appear that ips are ever properly reclaimed. They will
> hang around with allocated=0 and instance_id != NULL forever, until I
> manually correct the database.
I just turned off force_dhcp_release on my install and it app
This is expected. The compute host doesn't have an ip on the vm network unless
you are in multi_host mode and you are running nova-network on the compute host
as well.
Vish
On Jun 26, 2012, at 6:49 AM, David wrote:
> Hi all
>
> Is it a problem : I cannot ping from compute-node to vm with a f
Yes, this can work. This is the default setup in devstack. Generally for
production you would want to split to separate interfaces or vlans for security
reasons, but it does work to put everything on one interface like that.
Vish
On Jun 26, 2012, at 2:43 AM, David wrote:
> Hi all
>
> Can flo
Filed a bug here:
https://bugs.launchpad.net/nova/+bug/1017988
Fix for nova to allow hints that are not lists:
https://review.openstack.org/9002
fix for novaclient to turn multiple hints into a list:
https://review.openstack.org/9006
Vish
On Jun 26, 2012, at 1:31 AM, Christian Parpart wrote:
g a vlan configuration, the instances for this project are all
> launched on a network assigned to vlan109.
>
>
> On Mon, Jun 25, 2012 at 9:03 PM, Vishvananda Ishaya
> wrote:
> 10.0.9.5 is probably the ip that nova assigned to your compute host for the
> bridge.
>
>
Yes, you will have to manually detach and reattach volumes before using a
resize in essex.
Vish
On Jun 26, 2012, at 12:46 AM, 王盼|2076 wrote:
> Hi All,
>
> I saw that nova doesn't do anything with the attached volumes on the server
> in the essex version, and when I tried to resize a server w
On Jun 25, 2012, at 9:25 AM, Eoghan Glynn wrote:
>
> Hi Folks,
>
> I've been looking into the (currently broken) EC2 CreateImage API support
> and just wanted to get a sanity check on the following line of reasoning:
>
> - EC2 CreateImage should *only* apply to booted-from-volume nova servers
10.0.9.5 is probably the ip that nova assigned to your compute host for the
bridge.
ip addr show should show it on br100
There is likely something else going on that is causing your instance to fail
to network properly. I would check the console output of the vm first, make
sure it is getting
Usually queued means it didn't ever get uploaded into glance. Any errors in the
glance log? I have never seen the error below, but it could be related.
Vish
On Jun 25, 2012, at 3:50 AM, Leander Bessa Beernaert wrote:
> Hello,
>
> I've performed snapshots over and over without ever running into
force_dhcp_release=true should cause the ip to be released immediately,
assuming the relevant optional binary from dnsmasq is installed (it is in
the package dnsmasq-utils in ubuntu). If it is set to false then the ips
should be reclaimed after a set timeout period (ten minutes by default) via
a pe
d
> nova-scheduler in control node. after that was done, I tried to create a VM,
> but it still failed, and the debug info is showing as below:
> http://pastebin.com/RDHb9fDU
>
> Can you help me to take a look at the error info at your convenience?
>
> Thanks,
> Sam
>
Try setting:
ram_allocation_ratio=10
in your nova.conf (it defaults to 1.5)
Vish
On Jun 21, 2012, at 11:34 AM, Sam Su wrote:
> Hi,
>
> I have a mini openstack environment with one compute node and one nova
> control node. There is 4G memory in the compute node, and I have allocated 2
> VMs
On Jun 20, 2012, at 7:52 PM, Naveen Kuna wrote:
> Hi All,
>
> Can anyone help me in making cloudpipe image and how to use cloudpipe image
> for VPN service ?
Manually:
http://nova.openstack.org/devref/cloudpipe.html
Automatically:
https://github.com/Mirantis/cloudpipe-image-auto-creation
V
Generally the suggestion is to not set metadata_host to 127.0.0.1, but to set
it to the actual IP of the compute host. Your code change seems reasonable
however and I don't see any problem merging it if you propose it thorugh gerrit.
Vish
On Jun 20, 2012, at 2:44 PM, Lars Kellogg-Stedman wrote
cleanly again.
>
> I'll look into adding a forcible removal of this lockfile to the unstack.sh
> script (which I personally use to reset my Devstack envs)
>
> Thanks,
> -jay
>
> On 06/19/2012 03:13 PM, Vishvananda Ishaya wrote:
>> Sorry, paste fail on the last
Sorry, paste fail on the last message.
This seems like a likely culprit:
https://review.openstack.org/#/c/8339/
I'm guessing it only happens on concurrent builds? We probably need a
synchronized somewhere.
Vish
On Jun 19, 2012, at 12:03 PM, Jay Pipes wrote:
> cc'ing Vish on this, as this is
This seems like a likely culprit.
Vish
On Jun 19, 2012, at 12:03 PM, Jay Pipes wrote:
> cc'ing Vish on this, as this is now occurring on every single devstack +
> Tempest run, for multiple servers.
>
> Vish, I am seeing the exact same issue as shown below. Instances end up in
> ERROR state an
On Jun 19, 2012, at 10:52 AM, Florian Haas wrote:
> Hi everyone,
>
> perhaps someone can shed some light on a floating IP issue.
>
> I have 2 nova-compute nodes (call them alice and bob), one of them
> (alice) is also running nova-network. bob uses alice as its
> --metadata_host and --network_h
Are you running in VLAN mode? If so, you probably need to update to a new
version of dnsmasq. See this message for reference:
http://osdir.com/ml/openstack-cloud-computing/2012-05/msg00785.html
Vish
On Jun 14, 2012, at 1:41 PM, Christian Parpart wrote:
> Hey all,
>
> I feel really sad with s
On Jun 8, 2012, at 9:03 AM, Pádraig Brady wrote:
>
>> $ qemu-img info cirros-0.3.0-x86_64-disk.img
>> image: cirros-0.3.0-x86_64-disk.img
>> file format: qcow2
>> virtual size: 39M (41126400 bytes)
>> disk size: 11M
>> cluster_size: 65536
>> $ sudo qemu-nbd -c /dev/nbd15 $PWD/cirros-0.3.0-x86_64-
It is done by libvirt.
Vish
On Jun 5, 2012, at 11:55 PM, William Herry wrote:
> when a instance created, a network interface call vnetX will be created and
> attach to that instance
>
> I find related info about this in nova/virt/libvirt/vif.py, ip and tunctl
> seem to be the tool to create t
No, migrate does "dead" migration on a server. Essentially snapshots the drive
transfers it to a new server and reboots. Migrate and live-migration do need
to be consolidated.
Vish
On Jun 5, 2012, at 12:04 AM, Florian Haas wrote:
> Hi everyone,
>
> do I understand correctly that "nova migra
The default iscisi driver doesn't support CHAP. If you want to use chap
credentials for iscsi, you will have to modify the existing driver or create a
new one.
for example, check out:
nova/volume/san.py
You simply need to write the provider location field with the chap credentials
into the da
o know is there a way in openstack command to stop this situation,
> not replay me to delete the compute node route item. and I think, each VM
> should connect to the "access port" and go through trunk port(eth1 or eth2)
> to communicate with others.
> here is my wants.
o remote host (169.254.169.254): Connection timed out
> cloud-setup: failed 1/30: up 9.84. request failed
>
> Thanks,
> -vj
> From: Sergio Ariel de la Campa Saiz
> To: Vishvananda Ishaya ; Vijay
> Cc: "openstack@lists.launchpad.net"
> Sent: Friday, June 1, 201
On Jun 1, 2012, at 7:40 AM, John Garbutt wrote:
> Hi,
>
> Sorry, not had chance to look at the bugs in the last few days.
>
> It should be possible to just snapshot the root VDI. I guess that is what
> makes the most sense, what does the API say should happen?
+1 Snapshots should only be of
it looks like you are running a very old version of openstack (perhaps
diablo?), so it might be harder to figure out the problem.
Please check:
a) if your compute worker is still up and running
b) if there is an error message in the nova-api.log or the nova-compute.log
Vish
On Jun 1, 2012, at 3
Broadcast traffic should be blocked via the vlan separation and direct traffic
should be blocked via security groups. Do you have a security group that allows
ping traffic from 0.0.0.0/0?
Vish
On Jun 1, 2012, at 1:38 AM, romi zhang wrote:
> Hi,
>
> I use following command to create 2 NICs fo
On Jun 1, 2012, at 12:46 AM, Bram De Wilde wrote:
> Thanx Vish,
>
> On the name resolution: would you consider this a bug (I can file one if you
> would like) or a feature?
Bug if it is an easy fix :)
> Could this be fixed by changing the /usr/bin/nova-dhcpbridge script to load
> all mac, ho
201 - 300 of 718 matches
Mail list logo
