[one-users] Cannot shutdown VM
Harsha Buggi
Harsha_Buggi at mindtree.com
Wed Aug 12 05:32:23 PDT 2009
Hi,
The shutdown does not work because we are adding the following line in xml for creating a vm:
<features>
<acpi/>
<features>
We dont add this line in v1.2 by default. Can I know what changes do I need to make to source so that these lines are not added in the xml.
Regarding the node statistics not showing up - I have checked the logs and there is no information there. It just says hot x.x.x.x successfully monitored.
Regards,
Harsha
________________________________________
From: rsmontero at gmail.com [rsmontero at gmail.com] On Behalf Of Ruben S. Montero [rubensm at dacya.ucm.es]
Sent: Tuesday, August 11, 2009 8:21 PM
To: Harsha Buggi
Cc: users at lists.opennebula.org
Subject: Re: [one-users] Cannot shutdown VM
Hi
On Tue, Aug 11, 2009 at 8:52 AM, Harsha Buggi<Harsha_Buggi at mindtree.com> wrote:
> Hi,
> Thanks for your response. To answer some of your questions :
>
> For the 1st issue - Yes I am able to boot the VM's but not shut them down. If I just replace v1.3.80 with v1.2 in the same environment everything works perfect. There are no errors in the logs. When I do a shutdown the VM goes to shut state and stays there. But the VM is still running on the node.
>
> Modifications made as described in the second issue does not solve the first issue.
>
Ok, so the problem is not related to accessing libvirt. The difference
between 1.2 and 1.3.80 regarding shutdown is the following:
1.2 behavior. We issue the shutdown command, if the command is
accepted by the hypervisor, the VM proceeds to the next state
(epilog). However the VM is shutting down and moving/deleting the disk
images before the VM is completely stopped may lead to
inconsistencies.
1.3.80 we wait for the VM to completely stop. So if the VM is stuck in
the shutdown state it may:
a- did not complete the shutdown process.
b.- There is a bug in the "waiting" code or problem with your libvirt
version. The code is very simple:
while [ $(virsh dominfo one-<ID> > /dev/null 2 >&1 ; echo $?) -eq "0"
]; do sleep 2; done
Can you check:
1.- the VM is really shutdown (in the cluster node) virsh list or something
2.- The above code works with your libvirt installation. (Note that if
you are using the -c qemu:///session this should be placed in 48:56 in
one_vmm_kvm.rb
> Comming to the third issue - what is the mechanism for oneadmin to define a user and related access controls? I could not find any 'oneuser' command which might let the oneadmin define permissions. Also what is the mechanism for a specific user to access his/her VM's.
The permissions are implicit, you can only deal with your VMs and
Networks, for example
$onevm list
ID USER NAME STAT CPU MEM HOSTNAME TIME
12 ruben arch runn 0 131072 localhost 00 03:21:15
In this case USER means the owner of VM 12, and so only user "ruben"
(and oneadmin) can manage VM 12
> How does Nebula core know which user is currently logged into the system and executing 'one' commands.
The user is authenticated by her credentials (ONE_AUTH), and
authorized as described previously.
> I have created a user on the system called 'harsha' and after I log into the system I am able to run all the 'one' commands.I was able to delete Vnets and VM's created by 'oneadmin'.
Then it is :
a.- You are using the oneadmin's user and password in harsha ONE_AUTH
b.- This is a bug, but I can not reproduce it. I would need more info...
> This got me a little confused and I am finding it difficult to understand what is the purpose of creating users in nebula?
> I am not using 'sudo' to execute any commands.
The user system is suppose to work as you expect (bugs apart). You may
want to check
the following message for the aim of the multi-user support in OpenNebula:
http://lists.opennebula.org/pipermail/users-opennebula.org/2009-July/000620.html
Also, note that now ONE_AUTH contains the user and pass, which is a
serious security hole. In the next beta ONE_AUTH will point to a file
with the credentials. This file must be protected with the standard FS
access control mechanisms in UNIX.
> Few more issues....
>
> 1) The node statistics do not get updated to the Front end after adding a host with 'onehost' command. 'TCPU','FCPU' and 'TMEM' are all 0. Therefore VM do not automatically get deployed when they are created.
Do we have something interesting in oned.log? Is the monitoring action
started in the host?
> 2) What state should a VM be in order to perform a 'restart'. Will this by any chance reboot a VM? I have tried restart when the VM is in runn,fail,shut states but I always get the response this is not in the right state to perform this operation.
For example, you start a VM and go inside the VM and shutdown it
(within the virtual system). Next time OpenNebula will monitor the VM
it will not find it (because you shutdown it, or for example libvirt
crashed...). In v1.2 OpenNebula silently deletes the VM and removes
it. Now you will see that the VM go to a "unknown" state, from there
you can restart (because you have everything in the node) or delete
the VM, or try to recover it manually...
> Questions...
>
> What is the version of VM ware that Nebula supports. If I want to run Nebula with VMware which packages and their corresponding version should I install?
>
That is OpenNebula v1.3.80, the drivers are already shipped with that
release. More info in:
http://www.opennebula.org/doku.php?id=documentation:rel1.4:vmwareg
> Is VM reboot functionality included in the product roadmap? This is somthing which I require urgently and I am ready to test any partial builds if they are available with this functionality.
>
Ok this is something that is being requested by more people and it is
not too difficult to implement. I think this should be included in
next beta (1.3.85). I've created the following issue so you can track
the developments:
http://dev.opennebula.org/issues/132
We will try to start with the KVM driver so you can test it
Cheers
Ruben
>
> Regards,
> Harsha
>
>
>
> ________________________________________
> From: rsmontero at gmail.com [rsmontero at gmail.com] On Behalf Of Ruben S. Montero [rubensm at dacya.ucm.es]
> Sent: Tuesday, August 11, 2009 3:39 AM
> To: Harsha Buggi
> Cc: users at lists.opennebula.org
> Subject: Re: [one-users] Cannot shutdown VM
>
> On Mon, Aug 10, 2009 at 2:24 PM, Harsha Buggi<Harsha_Buggi at mindtree.com> wrote:
>> Hi,
>>
>> I have installed Nebula on an fc8 machine with NIS and NFS support. Using Oneadmin login to create VM's
>>
>> I have couple of issues:
>>
>> 1) I am not able to shutdown VM's. By default fc8 installs 'qemu-kvm' and I have created the symbolic link 'kvm' for this file. But after I create the VM's I am not able to perform a shutdown. I tried changing the 'emulator' to 'qemu-kvm' in libvirtdriver.cc file and reinstalling but I am still not able to shutdown the VM. I am able to do this if I install v1.2. I am using the following versions of hypervisor and libvirt
>> kvm-60
>> qemu-0.9.0-7
>> libvirt-0.4.4
>> libvirt-python-0.4.4
>
> So, after the changes you are able to boot the VM but not to shutdown
> it, right?. I am not sure why you can create but not shutdown. What
> does the log files say?
> I've updated the following issue to address also the "emulator" path:
>
> http://dev.opennebula.org/issues/131
>
>>
>> 2) I found that libvirt v 0.4.4 does not support user logins apart from root. This seems to have been fixed in the released recently v0.7.0. This could be the solution to the issue described in
>> http://lists.opennebula.org/pipermail/users-opennebula.org/2009-August/000626.html
>> In my case I have modified the one_vmm_kvm.rb file to reflect
>> create => "sudo virsh create" instead of 'create => "virsh -c qemu:///session create"'
>>
>
> Yes, we plan to make the hypervisor URI a configurable parameter in
> the vmm_kvm.conf file. BTW, Does this solve the previous issue?
>
>> 3) After creating a new user using 'oneuser create' command and setting the ONE_AUTH variable how do I set VM permissions for this user?
>
> The permissions are as follows:
>
> * Each VM and Network are owned by the user that creates them. (you
> can now see ownership in the "list" commands)
> * Each user can only managed her own VMs or Networks (i.e. shutdown
> migrate delete...)
> * Oneadmin can do anything
>
> This is enforced by the OpenNebula core.
>
>>Should this user be created on the system too?
>
> It is not really needed, it depends on the type of deployment you want
> to make. If the users are *external* (e.g. will access to your
> infrastructure through a cloud interface) you do not have to make a
> system account for each user, just an OpenNebula one. However if those
> users are the team of sysadmins managing the virtual infrastructure
> for a site each one will probably have their own system and OpenNebula
> accounts.
>
> Thanks for the feedback!
>
> Cheers!
>
> Ruben
>>
>> Regards,
>> Harsha
>>
>>
>>
>> ________________________________
>> http://www.mindtree.com/email/disclaimer.html
>> _______________________________________________
>> Users mailing list
>> Users at lists.opennebula.org
>> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>>
>
>
>
> --
> +---------------------------------------------------------------+
> Dr. Ruben Santiago Montero
> Associate Professor
> Distributed System Architecture Group (http://dsa-research.org)
>
> URL: http://dsa-research.org/doku.php?id=people:ruben
> Weblog: http://blog.dsa-research.org/?author=7
>
> GridWay, http://www.gridway.org
> OpenNebula, http://www.opennebula.org
> +---------------------------------------------------------------+
>
> http://www.mindtree.com/email/disclaimer.html
>
--
+---------------------------------------------------------------+
Dr. Ruben Santiago Montero
Associate Professor
Distributed System Architecture Group (http://dsa-research.org)
URL: http://dsa-research.org/doku.php?id=people:ruben
Weblog: http://blog.dsa-research.org/?author=7
GridWay, http://www.gridway.org
OpenNebula, http://www.opennebula.org
+---------------------------------------------------------------+
http://www.mindtree.com/email/disclaimer.html
More information about the Users
mailing list