Openstack++ in a single VM: CPU flag compatibility problem

[solimand]

Hi everyone,
I have successfully installed Openstack++ cloudlet infrastructure on my laptop, following https://github.com/cmusatyalab/elijah-openstack guidelines (I have followed this page for all other attempts).

• Ubuntu 14.04.03 Desktop Trusty.
• CPU: Intel Core i7 2640M, 2.8GHz ( http://www.cpu-world.com/CPUs/Core_i7/Intel-Core%20i7%20Mobile%20i7-2640M.html).
• RAM: 4GB.
• HD: 100GB.

After this, I tried to install Openstack on an AMD CPU based PC, but it fails because I need CPU flag ssse3 and it seems to be Intel property.

XML: Unsupported configuration: guest and host CPU are not compatible: Host CPU does not provide required features: ssse3.

Now, I am trying to install Openstack++ on a VM, but I’m having trouble with KVM nested virtualization and CPU flags and this is the real problem. Openstack creates the VM where I would install Openstack++. The options regarding the libvirt and CPU in nova.conf on Openstack Server are (based on http://docs.openstack.org/juno/config-reference/content/list-of-compute-config-options.html#config_table_nova_hypervisor):

virt_type = kvm;
cpu_mode = host-model | host-passthrough

With both, alternatively, these options I am not able to resume base VM because CPU compatibility problem occurs. The configuration of libvirt in nova.conf on the Openstack++ VM is that set by fabfile.py file that installs the cloudlet ( https://github.com/cmusatyalab/elijah-openstack/blob/master/fabfile.py). The error is the same, but the guilty flag is monitor:

XML: Unsupported configuration: guest and host CPU are not compatible: Host CPU does not provide required features: monitor.

The problem with the monitor flag is this: http://wiki.qemu.org/Features/CPUModels, section “Disabling features that were always disabled on KVM”. My questions are:

• Anyone knows how to bypass this incompatibility between kvm nested virtualization and monitor flag?
• I know @Marco had this type of trouble (topic http://forum.openedgecomputing.org/t/cloudlet-provisioning-apparmor-libvirt-crash-on-fresh-installation/43). Have you solved this issue?
• Can I use a different type of CPU for resume base VM that not expects monitor flag ?

Reading the cpu_map.xml file ( https://wiki.openstack.org/wiki/LibvirtXMLCPUModel) I have compared the CPU model standard and the CPU model that Elijah requires for resume base VM. At the row 123 of this file https://github.com/cmusatyalab/elijah-openstack/blob/master/fabfile.py I found core2due; though in the file cpu_map.xml the model name is core2duo.

• is core2due a modified core2duo? If it is, what are additional flag
  provided to this type of CPU? where I can retrieve his definition ?

My logs are: https://mega.nz/#F!7QJSyaKJ (decrypt_key=!nF-SmPc2fyfHdakT7KNw5g).

Sorry for the length of the post. Best regards to all edge

UPDATE1 = From within openstack++ VM:

@elijah-vm1:~/devstack$ cat /proc/cpuinfo
processor    : 0
vendor_id    : GenuineIntel
cpu family    : 6
model        : 42
model name    : Intel Xeon E312xx (Sandy Bridge)
stepping    : 1
microcode    : 0x1
cpu MHz        : 2294.210
cache size    : 4096 KB
physical id    : 0
siblings    : 1
core id        : 0
cpu cores    : 1
apicid        : 0
initial apicid    : 0
fpu        : yes
fpu_exception    : yes
cpuid level    : 13
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl eagerfpu pni pclmulqdq vmx ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm xsaveopt tpr_shadow vnmi flexpriority ept fsgsbase smep erms
bogomips    : 4588.42
clflush size    : 64
cache_alignment    : 64
address sizes    : 40 bits physical, 48 bits virtual
power management:

processor    : 1
vendor_id    : GenuineIntel
cpu family    : 6
model        : 42
model name    : Intel Xeon E312xx (Sandy Bridge)
stepping    : 1
microcode    : 0x1
cpu MHz        : 2294.210
cache size    : 4096 KB
physical id    : 1
siblings    : 1
core id        : 0
cpu cores    : 1
apicid        : 1
initial apicid    : 1
fpu        : yes
fpu_exception    : yes
cpuid level    : 13
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl eagerfpu pni pclmulqdq vmx ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm xsaveopt tpr_shadow vnmi flexpriority ept fsgsbase smep erms
bogomips    : 4588.42
clflush size    : 64
cache_alignment    : 64
address sizes    : 40 bits physical, 48 bits virtual
power management:

[krha]

Hi @solimand,

Please let me clarify one thing first.

Anyone knows how to bypass this incompatibility between kvm nested virtualization and monitor flag?

Are you trying to install OpenStack++ (or cloudlet code) inside or VM? If you are, it won't work. It might work within a VM in the future, but there would be lots of things to test.

is core2due a modified core2duo? If it is, what are additional flagprovided to this type of CPU? where I can retrieve his definition ?

Thanks for the bug report. I will fix that. But I don't think this typo is a cause of the problem. For the VM portability (to make sure that VM can be resumed every machine), I force CPU model to core2duo for every VM used in cloudlet code. See the following code.

cmusatyalab/elijah-provisioning/blob/master/elijah/provisioning/synthesis.py#L598

I had a couple of choice for selecting CPU model for the VMs running at OpenStack++, and decide to go with cure2duo for the following reason.

• libvirtd library guarantees to support core2duo cpu model to run if libvirtd can be installed on the host
• QEMU64 CPU model has compatibility issue libvirt 1.0.2 and libvirt 0.9.8
• KVM64 CPU model is only available from libvirt 1.0.2

Since Core2Duo CPU model includes ssse3 CPU flag, it explains why you had a problem with ssse3. Also, Core2Duo does not have svm flag, which is a CPU flag for AMD virtualization (http://en.wikipedia.org/wiki/X86_virtualization#AMD_virtualization_.28AMD-V.29), so it will prevent a VM from resuming on AMD machine.

The possible solution is changing CPU model from Core2Duo to KVM64, if you don't care about old version of Ubuntu and OpenStack (From Grizzly version, openstack uses libvrit 1.0.2 version and Ubuntu 14.04 uses libvirt >= 1.0.2), but I haven't tested it yet.

Thank you.

[solimand]

Hi @krha,
thank you for the precious help.

If you are, it won't work.

I would try again, following your tip about KVM64 option,

The possible solution is changing CPU model from Core2Duo to KVM64

I will change it in synthesis.py and fabfile.py files (is it right?) and then I will update you with my results.

Best regards and thanks again.

[krha]

Hi @solimand,

I will change it in synthesis.py and fabfile.py files (is it right?)

Yes, those are all changes I can think at this point. One thing to note is that you need to create your own Base VM for this because base VM is resumed using the Core2Duo CPU model. Thank you.

[solimand]

Hi everyone,
I have successfully installed Openstack++ all-in-one single VM. I made these steps to change CPU model configuration of the base VM and to create a new base VM.

1. Previously I created a VM in a classic way, with qemu/kvm. I used VM Manager graphical GUI (virt-manager package), I set the CPU configuration mode on “Copy Host CPU Configuration”. After the installation and the booting, I closed the VM and this action updates the resulting file .img, saved in the /var/lib/libvirt/images/ folder (default).
2. I modified the synthesis.py (elijah-provisioning/elijah/provisioning/) and the fabfile.py (elijah-openstack/) how @krha suggested me

model from Core2Duo to KVM64

3. I used the cloudlet base command with the file .img created before. And I obtained 4 files: VM-image-name.base-hash; VM-image-name.base-img-meta; VM-image-name.base-mem; VM-image-name.base-mem-meta; VM-image-name.img (this is the original one).
4. I had to create an xml file and zip all these 6 files together. The xml is like the below snippet:

<?xml version='1.0' encoding='UTF-8'?>
<image xmlns="http://opencloudlet.org/xmlns/vmsynthesis/package" hash_value="…">
  <disk path=" VM-image-name.img "/>
  <memory path=" VM-image-name.base-mem"/>
  <disk_hash path=" VM-image-name.base-img-meta"/>
  <memory_hash path=" VM-image-name.base-mem-meta"/>
</image>

In the hash value field insert the hash of the image (cat VM-image-name.base-hash or cloudlet list-base commands show it).

1. The .zip file represents the new baseVM and can be used in a classic way as described in https://github.com/cmusatyalab/elijah-openstack#how-to-use.

I hope I was helpful, best regards!!!

[krha]

Hi @solimand,

It's glad to hear that it works.

1. I used the cloudlet base command with the file .img created before. And I obtained 4 files: VM-image-name.base-hash; VM-image-name.base-img-meta; VM-image-name.base-mem; VM-image-name.base-mem-meta; VM-image-name.img (this is the original one). 4. I had to create an xml file and zip all these 6 files together. The xml is like the below snippet:

If you use "cloudlet export-base" command, it will give you a single zip file containing all these files with XML. You can import this single zip file to OpenStack or other machine using "cloudlet import-base" command.

Thank you.