[one-users] path error when PXE-booting VMs
Tino Vazquez
tinova at fdi.ucm.es
Wed Nov 18 08:08:02 PST 2009
Michael,
My apologies, my patch had a gross typo (baseame --> basename). You can
either change that, or try the following which is a bit more elegant:
images_path = File.dirname remote_dfile
cmd = "mkdir -p #{images_path} && cat > #{remote_dfile} &&
#{LIBVIRT[:create]} #{remote_dfile}"
Best,
-Tino
--
Constantino Vázquez, Grid Technology Engineer/Researcher:
http://www.dsa-research.org/tinova
DSA Research Group: http://dsa-research.org
Globus GridWay Metascheduler: http://www.GridWay.org
OpenNebula Virtual Infrastructure Engine: http://www.OpenNebula.org
On Tue, Nov 17, 2009 at 9:50 PM, Michael W. Lucas <
mwlucas at blackhelicopters.org> wrote:
>
> Hi,
>
> Thanks for the patch.
>
> Short answer: still not working, but the failure is different.
>
> My patched one_vmm_kvm.rb looks like the below (I don't know Ruby, so
> I could have quite easy made an error and not known it):
>
> --- one_vmm_kvm.rb-dist 2009-11-17 15:15:24.966874194 -0500
> +++ one_vmm_kvm.rb 2009-11-17 15:15:56.445072283 -0500
> @@ -85,7 +85,12 @@
> domain = tmp.read
> tmp.close()
>
> - cmd = "cat > #{remote_dfile} && #{LIBVIRT[:create]}
> #{remote_dfile}"
> +# cmd = "cat > #{remote_dfile} && #{LIBVIRT[:create]}
> #{remote_dfile}"
> + deployment_filename = File.baseame remote_dfile
> + images_path =
> +remote_dfile.gsub(deployment_filename,'')
> + cmd = "mkdir -p #{images_path} && cat > #{remote_dfile} &&
> +#{LIBVIRT[:create]} #{remote_dfile}"
>
> deploy_exe = SSHCommand.run("'#{cmd}'", host, log_method(id),
> domain)
>
> oned.log says:
>
> Tue Nov 17 15:32:42 2009 [ReM][D]: VirtualMachineAllocate invoked
> Tue Nov 17 15:32:42 2009 [DiM][D]: Allocating a new VM
> Tue Nov 17 15:33:04 2009 [ReM][D]: VirtualMachineDeploy invoked
> Tue Nov 17 15:33:04 2009 [DiM][D]: Deploying VM 2
> Tue Nov 17 15:33:04 2009 [TM][D]: Message received: TRANSFER SUCCESS 2 -
>
> 2/vm.log shows:
>
> Tue Nov 17 15:33:04 2009 [DiM][I]: New VM state is ACTIVE.
> Tue Nov 17 15:33:04 2009 [LCM][I]: New VM state is PROLOG.
> Tue Nov 17 15:33:04 2009 [VM][I]: Virtual Machine has no context
> Tue Nov 17 15:33:05 2009 [LCM][I]: New VM state is BOOT
> Tue Nov 17 15:33:05 2009 [VMM][I]: Generating deployment file:
> /usr/local/one/var/2/deployment.0
>
> It appears that we never try to run the command to start the VM,
> however.
>
> Tcpdump on the compute node shows that the head node is not even
> attempting to SSH to the compute node when deploying the VM. (I do
> see SSH traffic when oned monitors the compute node, so I believe my
> packet sniffer is configured correctly.)
>
> Any other suggestions?
>
> Thanks,
> ==ml
>
> On Mon, Nov 16, 2009 at 04:38:23PM +0100, Tino Vazquez wrote:
> > Hi Michael,
> >
> > The problem is that a diskless VM will cause that the transfer driver
> > doesn't get called. This transfer driver is responsible for creating the
> > 'images' directory. If you want t a network-booted machine you can try
> out
> > the following: in src/vmm_mad/kvm/one_vmm_kvm.rb change line 88 from:
> >
> > cmd = "cat > #{remote_dfile} && #{LIBVIRT[:create]}
> #{remote_dfile}"
> >
> > to
> >
> > deployment_filename = File.baseame remote_dfile
> > images_path =
> > remote_dfile.gsub(deployment_filename,'')
> > cmd = "mkdir -p #{images_path} && cat > #{remote_dfile} &&
> > #{LIBVIRT[:create]} #{remote_dfile}"
> >
> >
> > Please try this out, and if you find it useful please come back to us
> with
> > some feedback to we can include it in future releases.
> >
> > About your second questions, there are two deployment.0 images due to
> > OpenNebula design and its ability to use ssh or nfs. Because the VMM
> driver
> > doesn't know wihch storage it is being used, OpenNebula always uses a
> > scratch 'images' directory in the remote node were the deployment.0 file
> and
> > disks are copied from the front-end to there. If the storage is NFS based
> > you end up with two deployment.0 files locally. The 'images' directory is
> > used because doing a cat of a file over the same file will result on a
> null
> > file. Hope this makes sense :o
> >
> > Regards,
> >
> > -Tino
> >
> > --
> > Constantino V?zquez, Grid Technology Engineer/Researcher:
> > http://www.dsa-research.org/tinova
> > DSA Research Group: http://dsa-research.org
> > Globus GridWay Metascheduler: http://www.GridWay.org
> > OpenNebula Virtual Infrastructure Engine: http://www.OpenNebula.org
> >
> >
> > On Wed, Nov 11, 2009 at 9:21 PM, Michael W. Lucas <
> > mwlucas at blackhelicopters.org> wrote:
> >
> > > Hi,
> > >
> > > My ON 1.4beta2/KVM environment is working fine with disk images. ON
> > > cannot start a network-booted machine, however. The problem appears
> > > to be with the path used for the deployment file. If I use this
> template:
> > >
> > > NAME = onvm1
> > > CPU = 0.5
> > > MEMORY = 512
> > > OS = [ BOOT = network ]
> > > NIC = [ BRIDGE = "br0",
> > > MAC = "00:16:8B:AB:C7:14" ]
> > > GRAPHICS = [type="vnc",listen="127.0.0.1",port="-1"]
> > >
> > > the error log shows:
> > >
> > > Wed Nov 11 15:14:34 2009 [VMM][D]: Message received: LOG - 2 Command
> > > execution fail: 'cat > /one_dir/2/images/deployment.0 && virsh
> --connect
> > > qemu:///system create /one_dir/2/images/deployment.0'
> > >
> > > /one_dir/2/images/deployment.0 doesn't exist. But
> > > /one_dir/2/deployment.0 does exist, along with vm.log and the transfer
> > > files. There's no "images" subdirectory.
> > >
> > > On a simple VM with a hard drive, such as this, we do have an images
> > > subdirectory. Oddly, I have separate but identical deployment.0 files
> > > in multiple locations.
> > >
> > > clusterhead1/one_dir/1;ls -lai
> > > total 10K
> > > 156066 drwxrwxrwx 3 oneadmin oneadmin 6 2009-11-11 15:06 .
> > > 155649 drwxr-xr-x 6 oneadmin oneadmin 13 2009-11-11 15:17 ..
> > > 156092 -rw-r--r-- 1 oneadmin oneadmin 368 2009-11-11 15:06
> deployment.0
> > > 156088 drwxrwxrwx 2 oneadmin oneadmin 4 2009-11-11 15:06 images
> > > 156087 -rw-r--r-- 1 oneadmin oneadmin 83 2009-11-11 15:06
> > > transfer.0.prolog
> > > 156067 -rw-r--r-- 1 oneadmin oneadmin 2173 2009-11-11 15:17 vm.log
> > >
> > > clusterhead1/one_dir/1;ls -lai images/
> > > total 5K
> > > 156088 drwxrwxrwx 2 oneadmin oneadmin 4 2009-11-11 15:06 .
> > > 156066 drwxrwxrwx 3 oneadmin oneadmin 6 2009-11-11 15:06 ..
> > > 156093 -rw-r--r-- 1 oneadmin oneadmin 368 2009-11-11 15:06 deployment.0
> > > 156089 lrwxrwxrwx 1 oneadmin oneadmin 28 2009-11-11 15:06 disk.0 ->
> > > /one_dir/one_images/dns1.raw
> > > clusterhead1/one_dir/1;
> > >
> > > Any suggestions, folks?
> > >
> > > Thanks,
> > > ==ml
> > >
> > > --
> > > Michael W. Lucas mwlucas at BlackHelicopters.org
> > > http://www.MichaelWLucas.com/
> > > Latest book: Cisco Routers for the Desperate, 2nd Edition
> > > http://www.CiscoRoutersForTheDesperate.com/
> > > _______________________________________________
> > > Users mailing list
> > > Users at lists.opennebula.org
> > > http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
> > >
>
> --
> Michael W. Lucas mwlucas at BlackHelicopters.org
> http://www.MichaelWLucas.com/
> Latest book: Cisco Routers for the Desperate, 2nd Edition
> http://www.CiscoRoutersForTheDesperate.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20091118/c3344c55/attachment-0003.htm>
More information about the Users
mailing list