[one-users] path error when PXE-booting VMs

Tino Vazquez tinova at fdi.ucm.es
Wed Dec 16 07:58:44 PST 2009


Hi Michael,

This change will be included in OpenNebula 1.4.

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 18, 2009 at 5:58 PM, Michael W. Lucas
<mwlucas at blackhelicopters.org> wrote:
>
> Your more elegant patch works on 1.4.0-RC1.  Thank you, sir!
>
> Any chance we could get this in before 1.4?  If it's too risky, I'll
> just carry the patch locally.
>
> Thanks,
> ==ml
>
>
>
>
> On Wed, Nov 18, 2009 at 05:08:02PM +0100, Tino Vazquez wrote:
>> 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/
>> >
>
> --
> Michael W. Lucas        mwlucas at BlackHelicopters.org
> http://www.MichaelWLucas.com/
> Latest book:  Cisco Routers for the Desperate, 2nd Edition
> http://www.CiscoRoutersForTheDesperate.com/
>



More information about the Users mailing list