Bug #4624
the public image 'alpine-vrouter (KVM)' has got errors? shouldn't it say its initial p/w somewhere? and it said "Image is not in qcow2 format"
| Status: | Closed | Start date: | 07/07/2016 | |
|---|---|---|---|---|
| Priority: | Low | Due date: | ||
| Assignee: |  Jaime Melis | % Done: | 0% | |
| Category: | MarketPlace | |||
| Target version: | Release 5.0.2 | |||
| Resolution: | worksforme | Pull request: | ||
| Affected Versions: | OpenNebula 5.0 |
Description
Hi, I'm Nicho1as.
Version: 5.0.1
Source of the problem: alpine-vrouter (KVM) on the public marketplace
2016-07-07 13:19:33 Nicho1as I am following the deployment guide on opennebula.org and I've stumbled upon this problem making a vrouter and I guess it'd be a bug, anyone check if it is a bug?
2016-07-07 13:19:33 Nicho1as /var/log/one/oned.log: Thu Jul 7 13:10:50 2016 [Z0][VMM][D]: Message received: LOG I 8 error: Failed to create domain from /var/lib/one//datastores/101/8/deployment.0 Thu Jul 7 13:10:50 2016 [Z0][VMM][D]: Message received: LOG I 8 error: internal error: process exited while connecting to monitor: 2016-07-07T04:10:49.989286Z qemu-system-x86_64: -drive
2016-07-07 13:19:33 Nicho1as file=/var/lib/one//datastores/101/8/disk.0,if=none,id=drive-virtio-disk0,format=qcow2,cache=none: could not open disk image /var/lib/one//datastores/101/8/disk.0: Image is not in qcow2 format
2016-07-07 13:42:24 pfak darkfader: oh apparently the knowledge base doesn't exist, i don't think the guy is a native speaker.
2016-07-07 13:43:32 Nicho1as yes, yes
2016-07-07 13:43:41 Nicho1as (no) yes
2016-07-07 13:44:22 Nicho1as positive, positive.... oh English is so hard..
2016-07-07 13:54:19 Nicho1as is it just me or the image on the public marketplace has an error?
2016-07-07 13:55:22 Nicho1as the document just basically says, download and deploy.
2016-07-07 13:55:38 Nicho1as What is wrong with my deployment?
2016-07-07 14:03:22 Nicho1as well, I just edited the FORMAT and DRIVER from 'qcow2' to 'raw' issuing the command 'oneimage update <image_id>'
2016-07-07 14:03:26 Nicho1as it works
2016-07-07 14:03:44 Nicho1as Should I report this bug?
2016-07-07 14:03:49 Nicho1as or it's not a bug and my fault?
2016-07-07 14:04:23 Nicho1as is there an error in the document?
2016-07-07 14:18:09 Nicho1as I wonder what's wrong with this vrouter image, shouldn't it say its initial password somewhere?
2016-07-07 14:42:53 Nicho1as wow, it doesn't even forward packets....
History
#1
Updated by Ruben S. Montero about 5 years ago
- Assignee set to Javi Fontan
- Target version set to Release 5.0.2
Thanks, we'll take a look to the format. About the password for security reasons, we expect to access with SSH keys. Just add the public key to the opennebula user.
#2
Updated by Gunwoo Gim almost 5 years ago
Ruben S. Montero wrote:
Thanks, we'll take a look to the format. About the password for security reasons, we expect to access with SSH keys. Just add the public key to the opennebula user.
so in order to access the vrouter you have to copy your public key to /home/opennebula or /root/; and opennebula's uid is 0 in the vrouter?
#3
Updated by Gunwoo Gim almost 5 years ago
Gunwoo Gim wrote:
Ruben S. Montero wrote:
Thanks, we'll take a look to the format. About the password for security reasons, we expect to access with SSH keys. Just add the public key to the opennebula user.
so in order to access the vrouter's root shell, you have to copy your public key to /home/opennebula or /root/; and opennebula's uid is 0 in the vrouter?
#4
Updated by EOLE Team almost 5 years ago
Gunwoo Gim wrote:
Ruben S. Montero wrote:
About the password for security reasons, we expect to access with SSH keys. Just add the public key to the opennebula user.
so in order to access the vrouter you have to copy your public key to /home/opennebula or /root/; and opennebula's uid is 0 in the vrouter?
It's handled by context ,the user starting the VM will have her SSH keys added to the authorized keys of the user root (c.f. sources of the script).
For the password, I made two pull request to permit to set it in GNU/Linux machines too even if the documentation does not reflect it:
So you could add a user input to set the CRYPTPASSWORD or the less secure clear text PASSWORD and the user will need to fill this input to start the VM, then the context script will define the root password to the user input.
NB: the context script does not check if user input is correct, the ${CRYPTED_PASSWORD} need to be valid and the clear text PASSWORD must comply with whatever password policy is set in the VM.
Regards.
#5
Updated by Jaime Melis almost 5 years ago
- Assignee changed from Javi Fontan to Jaime Melis
#6
Updated by Jaime Melis almost 5 years ago
- Status changed from Pending to Closed
- Resolution set to worksforme
I'm going to close this ticket as the format looks correct to me:
$ oneimage show 20|grep SOURCE
SOURCE : /var/lib/one//datastores/1/5ff068409567960b1328366634615424
$ qemu-img info /var/lib/one//datastores/1/5ff068409567960b1328366634615424
image: /var/lib/one//datastores/1/5ff068409567960b1328366634615424
file format: qcow2
virtual size: 256M (268435456 bytes)
disk size: 53M
cluster_size: 65536
Format specific information:
compat: 1.1
lazy refcounts: false
refcount bits: 16
corrupt: false
Can yoy try again? If it fails, please reopen the ticket and attach the output of qemu-img info for the image.