Ask Your Question

sigrist's profile - activity

2017-01-24 04:40:10 -0500 received badge  Nice Question (source)
2016-03-11 03:14:32 -0500 received badge  Famous Question (source)
2014-09-12 11:11:04 -0500 received badge  Notable Question (source)
2014-07-11 00:54:48 -0500 received badge  Taxonomist
2014-03-31 00:38:41 -0500 received badge  Famous Question (source)
2013-12-12 14:07:16 -0500 commented answer Windows 8 x86 on Grizzly

I would also try older CPU models... maybe one of them would work, IDK.

2013-12-12 14:06:29 -0500 commented answer Windows 8 x86 on Grizzly

Thanks man! I haven't tried x86 myself, only x64. Did you create a whole new instance after setting the libvirt CPU model? IIRC, changing CPU models will only affect new instances, not previously existing ones (because for them the libvirt XML will already have been created).

2013-12-10 21:37:03 -0500 answered a question Windows 8 x86 on Grizzly

Hi ghost!

I think I know what may be happening to you, I had the same happen to me with Windows Server 2012.

You probably haven't configured the CPU model in your compute node (nova-compute.conf) so by default KVM is basically advertising all your host's processor capabilities to the guest, even those that KVM itself doesn't support.

So Windows attempts to execute an instruction that the guest processor doesn't support, which causes the invalid instruction processor exception, which then leads to your STOP 0x5D.

To fix it, try this. Assuming you have an Intel "Sandy Bridge" CPU model on your host, add those lines to your nova-compute.conf, which will configure the guest-exposed CPUs as that model. When you configure explicitly, KVM doesn't expose to the guest instructions that it doesn't support:

libvirt_cpu_mode=custom
libvirt_cpu_model=SandyBridge

For more information on those settings, check this out: https://wiki.openstack.org/wiki/LibvirtXMLCPUModel

Cheers, and let us know how that goes, if that solves your problem etc!

-- thiago

2013-11-19 05:50:12 -0500 received badge  Notable Question (source)
2013-11-16 14:26:19 -0500 received badge  Popular Question (source)
2013-11-13 21:36:41 -0500 received badge  Student (source)
2013-11-13 21:28:13 -0500 received badge  Popular Question (source)
2013-10-27 09:43:33 -0500 asked a question Cinder disaster recovery procedure?

Hi folks!

Recently, after attempting to recover from disaster, I ended up with an inconsistent cinder database due to incorrect manual editing. :-(

However, I devised a procedure to obtain a clean cinder db without losing data from the volumes. It seems to work, but I'd like some expert opinion to see if I'm not missing something.

Here are the steps:

  1. dump all volume data (cinder list, cinder show etc).
  2. stop all cinder services
  3. delete all iscsi targets (tgt-admin --delete)
  4. go into mysql and drop database cinder
  5. recreate cinder database and permissions, and do cinder-manage db sync
  6. restart all cinder services
  7. for each volume in the cinder LVM group:
  8. create new volume through cinder with same size and metadata
  9. stop all cinder services
  10. delete new volume's iscsi target
  11. lvremove new volume
  12. lvrename old volume to new volume's name
  13. restart all cinder services
  14. back to step 7/8 until all volumes are recovered

This seems to work like a charm in my experience, but I still worry it may be creating some inconsistencies in cinder's/tgt metadata that I'm unaware of.

Can any of you experts analyze this and tell me if this is a sound procedure?

Thanks!

-- thiago

2013-09-05 11:35:08 -0500 received badge  Enthusiast
2013-08-27 12:01:36 -0500 answered a question ERROR: Malformed request url (HTTP 400) (Request-ID: req-fc257562-9561-49d7-a704-261e1d0956ad)

Hello there!

Do you know if nova-network is running and if it is logging any errors?

I am just a beginner with OpenStack, but you'll be able to get a lot more traction figuring out your problem if you check those two things.

To check if nova-network is running, use nova-manage service list and look for nova-network there. If it has a happy face ':-)' it started properly, otherwise it will show 'XXX' meaning it couldn't start for some reason.

Also look at the end of the nova-network log file, which is /var/log/nova/nova-network.log. If nova-network is not running then the log will probably have errors that point out why; if it IS running then try running your nova network-create command again and see if that causes errors to appear in the log, which might give some info why the command is not running.

And of course, please share with us what you find. The community here is very helpful and knowledgeable and will be able to help you even further.

Thanks!

-- thiago

2013-08-27 06:03:44 -0500 commented answer Why is quota charged for shutdown instances?

Thanks for your answer! That's what I imagined, unfortunately. It would be cool if there was a way to tweak how quotas are charged. For example, for my requirements I would not charge VCPU or RAM for shutdown instances, but other users might have other requirements. :)

2013-08-27 05:59:19 -0500 received badge  Supporter (source)
2013-08-26 13:20:22 -0500 received badge  Editor (source)
2013-08-26 11:33:40 -0500 received badge  Organizer (source)
2013-08-26 11:32:02 -0500 asked a question Why is quota charged for shutdown instances?

Hi OpenStack folks!

I have a brand new private cloud setup for development using Ubuntu 12.04 and OpenStack grizzly.

I just noticed behavior that is quite undesirable for my purposes: shutdown machines still cause tenant quotas to be charged for VCPUs and RAM, even though they are actually utilizing neither.

Since I intend to keep around some shutdown machines in case I need them, this is quite undesirable as I will run out of quota while still having spare compute capacity to use.

Can anyone tell me if this is an OpenStack bug or if there is a way to configure quotas so that shutdown machines won't charge VCPUs and RAM?

Please let me know.

Thanks!

-- thiago