This is a long shot, but do you have a scheduled shutdown action in your VMs?
Can you paste the output of 'onevm show 1687 --all' ? Regards -- Carlos Martín, MSc Project Engineer OpenNebula - Flexible Enterprise Cloud Made Simple www.OpenNebula.org | cmar...@opennebula.org | @OpenNebula<http://twitter.com/opennebula><cmar...@opennebula.org> On Mon, Apr 7, 2014 at 2:47 PM, <kenny.ke...@bol.com.br> wrote: > If i try to use tap2:aio, yes. > > I changed xen and increased the loop the devices to 64, and now i´m using > file as driver. > > ------------------------------ > > *De:* cmar...@opennebula.org > *Enviada:* Segunda-feira, 7 de Abril de 2014 10:52 > > *Para:* kenny.ke...@bol.com.br > *Assunto:* [one-users] blktap xen 4.2 and opennebula 4.2 > > Hi, > > Take a look at these lines: > > Sun Mar 30 23:59:04 2014 [ReM][D]: Req:7520 UID:0 VirtualMachineDeploy > invoked, 1687, 3, false > Sun Mar 30 23:59:13 2014 [ReM][D]: Req:5120 UID:0 VirtualMachineAction > invoked, "delete", 1687 > > onevm delete was called. Is this happening for all your VMs? > > Regards > -- > Carlos Martín, MSc > Project Engineer > OpenNebula - Flexible Enterprise Cloud Made Simple > www.OpenNebula.org | cmar...@opennebula.org | @OpenNebula > > > On Sat, Apr 5, 2014 at 8:00 AM, <kenny.ke...@bol.com.br> wrote: > >> i didt find anything wrong , just something about driver.. >> >> >> thanks. >> >> Sun Mar 30 23:58:55 2014 [ReM][D]: Req:1280 UID:0 VirtualMachineAllocate >> invoked, "CPU="0.1"...", false >> Sun Mar 30 23:58:56 2014 [ReM][D]: Req:1280 UID:0 VirtualMachineAllocate >> result SUCCESS, 1687 >> Sun Mar 30 23:59:01 2014 [ReM][D]: Req:5632 UID:2 HostPoolInfo invoked >> Sun Mar 30 23:59:01 2014 [ReM][D]: Req:5632 UID:2 HostPoolInfo result >> SUCCESS, "<HOST_POOL><ID..." >> >> Sun Mar 30 23:59:02 2014 [ReM][D]: Req:8016 UID:0 VirtualMachinePoolInfo >> invoked, -2, -1, -1, -1 >> Sun Mar 30 23:59:02 2014 [ReM][D]: Req:8016 UID:0 VirtualMachinePoolInfo >> result SUCCESS, "<VM_POOL>162..." >> >> Sun Mar 30 23:59:02 2014 [ReM][D]: Req:9776 UID:0 VirtualMachineInfo >> invoked, 1624 >> Sun Mar 30 23:59:02 2014 [ReM][D]: Req:9776 UID:0 VirtualMachineInfo >> result SUCCESS, "1624<UI..." >> >> Sun Mar 30 23:59:03 2014 [ReM][D]: Req:496 UID:0 VirtualMachinePoolInfo >> invoked, -2, -1, -1, -1 >> Sun Mar 30 23:59:03 2014 [ReM][D]: Req:496 UID:0 VirtualMachinePoolInfo >> result SUCCESS, "<VM_POOL>162..." >> >> Sun Mar 30 23:59:03 2014 [ReM][D]: Req:496 UID:0 VirtualMachinePoolInfo >> invoked, -2, -1, -1, -1 >> Sun Mar 30 23:59:03 2014 [ReM][D]: Req:496 UID:0 VirtualMachinePoolInfo >> result SUCCESS, "<VM_POOL>162..." >> >> Sun Mar 30 23:59:03 2014 [ReM][D]: Req:5056 UID:0 VirtualMachineInfo >> invoked, 1624 >> Sun Mar 30 23:59:03 2014 [ReM][D]: Req:5056 UID:0 VirtualMachineInfo >> result SUCCESS, "1624<UI..." >> >> Sun Mar 30 23:59:03 2014 [ReM][D]: Req:496 UID:0 VirtualMachinePoolInfo >> invoked, -2, -1, -1, -1 >> Sun Mar 30 23:59:04 2014 [ReM][D]: Req:496 UID:0 VirtualMachinePoolInfo >> result SUCCESS, "<VM_POOL>162..." >> >> Sun Mar 30 23:59:04 2014 [ReM][D]: Req:2640 UID:0 VirtualMachinePoolInfo >> invoked, -2, -1, -1, -1 >> Sun Mar 30 23:59:04 2014 [ReM][D]: Req:2640 UID:0 VirtualMachinePoolInfo >> result SUCCESS, "<VM_POOL>162..." >> >> Sun Mar 30 23:59:04 2014 [ReM][D]: Req:9120 UID:0 HostPoolInfo invoked >> Sun Mar 30 23:59:04 2014 [ReM][D]: Req:9120 UID:0 HostPoolInfo result >> SUCCESS, "<HOST_POOL><ID..." >> >> Sun Mar 30 23:59:04 2014 [ReM][D]: Req:6560 UID:0 ClusterPoolInfo invoked >> Sun Mar 30 23:59:04 2014 [ReM][D]: Req:7520 UID:0 VirtualMachineDeploy >> invoked, 1687, 3, false >> Sun Mar 30 23:59:04 2014 [DiM][D]: Deploying VM 1687 >> Sun Mar 30 23:59:04 2014 [ReM][D]: Req:7520 UID:0 VirtualMachineDeploy >> result SUCCESS, 1687 >> Sun Mar 30 23:59:05 2014 [ReM][D]: Req:5696 UID:2 UserPoolInfo invoked >> Sun Mar 30 23:59:05 2014 [ReM][D]: Req:5696 UID:2 UserPoolInfo result >> SUCCESS, "<USER_POOL><ID..." >> >> Sun Mar 30 23:59:06 2014 [VMM][I]: --Mark-- >> Sun Mar 30 23:59:08 2014 [ReM][D]: Req:272 UID:2 AclInfo invoked >> Sun Mar 30 23:59:08 2014 [ReM][D]: Req:272 UID:2 AclInfo result SUCCESS, >> "<ACL_POOL>0..." >> >> Sun Mar 30 23:59:13 2014 [ReM][D]: Req:5120 UID:0 VirtualMachineAction >> invoked, "delete", 1687 >> Sun Mar 30 23:59:13 2014 [DiM][D]: Finalizing VM 1687 >> Sun Mar 30 23:59:13 2014 [ReM][D]: Req:5120 UID:0 VirtualMachineAction >> result SUCCESS, 1687 >> Sun Mar 30 23:59:14 2014 [TM][D]: Message received: LOG I 1687 Driver >> command for 1687 cancelled >> Sun Mar 30 23:59:15 2014 [ReM][D]: Req:2192 UID:2 VirtualMachinePoolInfo >> invoked, -2, -1, -1, -1 >> Sun Mar 30 23:59:15 2014 [ReM][D]: Req:2192 UID:2 VirtualMachinePoolInfo >> result SUCCESS, "<VM_POOL>162..." >> >> Sun Mar 30 23:59:19 2014 [ReM][D]: Req:3520 UID:2 ImagePoolInfo invoked, >> -2, -1, -1 >> Sun Mar 30 23:59:19 2014 [ReM][D]: Req:3520 UID:2 ImagePoolInfo result >> SUCCESS, "<IMAGE_POOL><..." >> ------------------------------ >> >> *De:* cmar...@opennebula.org >> *Enviada:*Quinta-feira, 3 de Abril de 2014 10:48 >> >> *Para:* kenny.ke...@bol.com.br >> *Assunto:* [one-users] blktap xen 4.2 and opennebula 4.2 >> >> Hi, >> >> On Tue, Apr 1, 2014 at 5:07 PM, <kenny.ke...@bol.com.br> wrote: >> >>> no i didn't do that. >>> >>> after a few seconds, the vm name disapear from onevm list. it doesnt >>> stay with prolog, boot etc. >>> >> >> Can you check in oned.log if there is any call to onevm delete? Maybe >> there is a script somewhere causing this... >> -- >> Carlos Martín, MSc >> Project Engineer >> OpenNebula - Flexible Enterprise Cloud Made Simple >> www.OpenNebula.org | cmar...@opennebula.org | @OpenNebula >> >> >> >>> ------------------------------ >>> >>> *De:* jfon...@opennebula.org >>> *Enviada:* Terça-feira, 1 de Abril de 2014 09:40 >>> *Para:* kenny.ke...@bol.com.br,users@lists.opennebula.org >>> >>> *Assunto:* [one-users] blktap xen 4.2 and opennebula 4.2 >>> >>> That message is only seen when you cancel actions like when you >>> execute onevm delete. Have you done that? Maybe you didn't wait until >>> the image transfer was done. >>> >>> On Mon, Mar 31, 2014 at 5:08 AM, <kenny.ke...@bol.com.br> wrote: >>> > Hello, i try to force the driver in the image but i got this error in >>> > var/log/one/XXXX.log >>> > >>> > >>> > >>> > Sun Mar 30 23:59:04 2014 [DiM][I]: New VM state is ACTIVE. >>> > Sun Mar 30 23:59:04 2014 [LCM][I]: New VM state is PROLOG. >>> > Sun Mar 30 23:59:04 2014 [VM][I]: Virtual Machine has no context >>> > Sun Mar 30 23:59:13 2014 [LCM][I]: New VM state is CLEANUP. >>> > Sun Mar 30 23:59:14 2014 [DiM][I]: New VM state is DONE >>> > Sun Mar 30 23:59:14 2014 [TM][W]: Ignored: LOG I 1687 Driver command >>> for >>> > 1687 cancelled >>> > >>> > Sun Mar 30 23:59:42 2014 [TM][W]: Ignored: TRANSFER SUCCESS 1687 - >>> > >>> > And vm didnt start . >>> > do you know what is this ? >>> > thanks. >>> > ________________________________ >>> > >>> > De: jfon...@opennebula.org >>> > Enviada: Sexta-feira, 28 de Março de 2014 16:11 >>> > >>> > Para: kenny.ke...@bol.com.br >>> > Assunto: [one-users] blktap xen 4.2 and opennebula 4.2 >>> > >>> > On Fri, Mar 28, 2014 at 3:37 PM, <kenny.ke...@bol.com.br> wrote: >>> >> Thanks for the reply, i forgot to say im using NFS. >>> >> Its a problem ? >>> > >>> > It should not be a problem. >>> > >>> >> I will check the files in the remote host. >>> >> It´s in the same folder ? >>> > >>> > No, in the nodes they reside in /var/tmp/one. >>> > >>> >> I will see if the image has a driver. >>> >> I can chage the image driver or i need to create a new one ? >>> > >>> > You can use "oneimage update" command or the Sunstone web interface >>> > >>> > >>> >> >>> >> >>> >> ________________________________ >>> >> >>> >> De: jfon...@opennebula.org >>> >> Enviada: Sexta-feira, 28 de Março de 2014 12:36 >>> >> >>> >> Para: kenny.ke...@bol.com.br >>> >> Assunto: [one-users] blktap xen 4.2 and opennebula 4.2 >>> >> >>> >> Is it possible that you have a driver defined in the image you are >>> >> attaching? An explicit driver takes precedence over the default one >>> >> configured. >>> >> >>> >> Still, I've made the test with a vanilla OpenNebula 4.2 installation >>> >> and the tips I've sent you work nicely. To test this I've changed the >>> >> prefix to a wrong one so we can see the command: >>> >> >>> >> * Changed /var/lib/one/remotes/vmm/xen4/xenrc and set this line: >>> >> >>> >> export DEFAULT_FILE_PREFIX="this:should:not:work" >>> >> >>> >> * Executed "onehost sync" as oneadmin user. This part is very >>> >> important as the nodes have a copy of driver files (remotes) and we >>> >> need to update those files in the nodes when we modify something in >>> >> the frontend. >>> >> >>> >> * Waited for the next monitoring cycle of all nodes. In OpenNebula 4.2 >>> >> the copy of remotes is done in the monitorization phase >>> >> >>> >> * Attach disk: >>> >> >>> >> $ onevm disk-attach 0 --image data >>> >> >>> >> * Got the error: >>> >> >>> >> ERROR="Fri Mar 28 12:41:33 2014 : Error attaching new VM Disk: Could >>> >> not attach >>> >> >>> this:should:not:work:/home/one/one/install-4.2/var//datastores/0/0/disk.1 >>> >> (sda) to one-0" >>> >> >>> >> On Thu, Mar 27, 2014 at 8:18 PM, <kenny.ke...@bol.com.br> wrote: >>> >>> see atached files. >>> >>> >>> >>> >>> >>> thanks. >>> >>> ________________________________ >>> >>> >>> >>> De: jfon...@gmail.com >>> >>> Enviada: Quinta-feira, 27 de Março de 2014 19:18 >>> >>> >>> >>> Para: kenny.ke...@bol.com.br >>> >>> Assunto: [one-users] blktap xen 4.2 and opennebula 4.2 >>> >>> >>> >>> Disregard the --force. I've misread the problem. The parameter >>> --force >>> >>> does not work in one 4.2. Just execute: >>> >>> >>> >>> onehost sync >>> >>> >>> >>> On Thu, Mar 27, 2014 at 7:07 PM, Javier Fontan <jfon...@gmail.com> >>> wrote: >>> >>>> Are you sure that the drivers uncomented are xen4 and not xen3? >>> >>>> >>> >>>> Also, can you send me the file xenrc you've changed? That "invalid >>> >>>> option: --force" is so strange. >>> >>>> >>> >>>> On Thu, Mar 27, 2014 at 7:03 PM, <kenny.ke...@bol.com.br> wrote: >>> >>>>> it didnt work. >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> i received this message >>> >>>>> invalid option: --force >>> >>>>> >>> >>>>> and it always use file insstead of tap2:aio >>> >>>>> i dont know what to do. >>> >>>>> ________________________________ >>> >>>>> >>> >>>>> De: jfon...@gmail.com >>> >>>>> Enviada: Quinta-feira, 27 de Março de 2014 18:08 >>> >>>>> Para: kenny.ke...@bol.com.br >>> >>>>> Assunto: [one-users] blktap xen 4.2 and opennebula 4.2 >>> >>>>> >>> >>>>> >>> >>>>> You can change it in in "/var/lib/one/remotes/vmm/xen4/xenrc", the >>> >>>>> parameter is DEFAULT_FILE_PREFIX. >>> >>>>> >>> >>>>> Remember to do a onehost sync --force so these files are copied to >>> the >>> >>>>> remote hosts. >>> >>>>> >>> >>>>> On Thu, Mar 27, 2014 at 3:54 AM, <kenny.ke...@bol.com.br> wrote: >>> >>>>>> Hello, i need to use blktap instead of default disk drive. >>> >>>>>> >>> >>>>>> i changed /var/lib/one/remotes/vmm/xen4/attach_disk and >>> >>>>>> /etc/one/vmm_exec/vmm_exec_xen4.conf , but when take a look at >>> >>>>>> deployment.0 >>> >>>>>> , it always with "file:". >>> >>>>>> What i need to do to change that ? >>> >>>>>> >>> >>>>>> I will change it beacuase with file i can run just 8 vm per node. >>> >>>>>> >>> >>>>>> >>> >>>>>> thank >>> >>>>>> >>> >>>>>> _______________________________________________ >>> >>>>>> Users mailing list >>> >>>>>> Users@lists.opennebula.org >>> >>>>>> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org >>> >>>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> -- >>> >>>>> Javier Fontán Muiños >>> >>>>> OpenNebula Developer >>> >>>>> OpenNebula - The Open Source Toolkit for Data Center Virtualization >>> >>>>> www.OpenNebula.org | @OpenNebula | github.com/jfontan >>> >>>> >>> >>>> >>> >>>> >>> >>>> -- >>> >>>> Javier Fontán Muiños >>> >>>> OpenNebula Developer >>> >>>> OpenNebula - The Open Source Toolkit for Data Center Virtualization >>> >>>> www.OpenNebula.org | @OpenNebula | github.com/jfontan >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> Javier Fontán Muiños >>> >>> OpenNebula Developer >>> >>> OpenNebula - The Open Source Toolkit for Data Center Virtualization >>> >>> www.OpenNebula.org | @OpenNebula | github.com/jfontan >>> >> >>> >> >>> >> >>> >> -- >>> >> Javier Fontán Muiños >>> >> Developer >>> >> OpenNebula - The Open Source Toolkit for Data Center Virtualization >>> >> www.OpenNebula.org | @OpenNebula | github.com/jfontan >>> > >>> > >>> > >>> > -- >>> > Javier Fontán Muiños >>> > Developer >>> > OpenNebula - The Open Source Toolkit for Data Center Virtualization >>> > www.OpenNebula.org | @OpenNebula | github.com/jfontan >>> >>> >>> >>> -- >>> Javier Fontán Muiños >>> Developer >>> OpenNebula - The Open Source Toolkit for Data Center Virtualization >>> www.OpenNebula.org | @OpenNebula | github.com/jfontan >>> >>> _______________________________________________ >>> Users mailing list >>> Users@lists.opennebula.org >>> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org >> >> >> > >
_______________________________________________ Users mailing list Users@lists.opennebula.org http://lists.opennebula.org/listinfo.cgi/users-opennebula.org