UEC: Troubleshooting - Revision history

Onnowpurbo at 01:48, 22 March 2011

2011-03-22T01:48:07Z

← Older revision		Revision as of 01:48, 22 March 2011
Line 80:		Line 80:
	Dimana A.B.C.D adalah [[IP address]] dari interface di NC yang dapat dihubungi dari mesin client yang menjalankan VNC client. Kita mengasumsikan NC mempunyai dua (2) interface dan kita dapat menggunakan interface ke dua untuk mencapai NC tanpa melalui CC. Perhatikan bahwa ini hanya digunakan untuk troubleshooting. Pada setup produksi, kita harus menyambungkan NC ke dunia luar hanya melalui CC.		Dimana A.B.C.D adalah [[IP address]] dari interface di NC yang dapat dihubungi dari mesin client yang menjalankan VNC client. Kita mengasumsikan NC mempunyai dua (2) interface dan kita dapat menggunakan interface ke dua untuk mencapai NC tanpa melalui CC. Perhatikan bahwa ini hanya digunakan untuk troubleshooting. Pada setup produksi, kita harus menyambungkan NC ke dunia luar hanya melalui CC.

	~~With these changes~~, KVM ~~adds the~~ “-vnc” ~~option to the command with the specified NC’s ip~~ address on display ~~number~~ 4.		Dengan perubahan tersebut, KVM akan menambahkan opsi “-vnc” untuk NC dengan [[IP address]] tertentu tersebut dengan display nomor 4.

	~~To connect to the~~ instance ~~through~~ VNC client ~~from a different machine~~, ~~use the NC’s ip~~ address ~~and~~ display ~~number~~ 4.		Untuk menyambung ke instance melalui VNC client dari mesin yang berbeda, gunakan [[IP address]] NC dan display nomor 4. Misalnya: A.B.C.D :4
	Ex: A.B.C.D :4

	~~In the case of~~ Xen, ~~you would modify the relevant sections of~~ /usr/share/eucalyptus/gen_libvirt_xml. ~~We have not tested with~~ Xen~~, though~~.		Untuk Xen, kita perlu memodifikasi bagian terkait yang ada di /usr/share/eucalyptus/gen_libvirt_xml. Kami belum pernah mentest untuk Xen.

	==Instance Linux==		==Instance Linux==

Onnowpurbo at 01:44, 22 March 2011

2011-03-22T01:44:13Z

← Older revision		Revision as of 01:44, 22 March 2011
Line 37:		Line 37:
	Menjalankan sebuah instance dengan VNC attached(HACK):		Menjalankan sebuah instance dengan VNC attached(HACK):

	Jika output euca-describe-instances menunjukan status sebuah instance sebagai ‘running’, tapi jika kita tidak bisa SSH ke instance tersebut atau RDP ke instance tersebut, akan sangat susah untuk mencari tahu dimana terjadi kegagalan. Dalam kasus tersebut, sebuah VNC interface ke instance sangat menolong dalam membantu proses troubleshooting. Akan tetapi Eucalyptus tidak memberikan cara untuk menyambungkan instance melalui VNC. ~~The following hack can help in setting up a~~ VNC ~~interface to the~~ instance.		Jika output euca-describe-instances menunjukan status sebuah instance sebagai ‘running’, tapi jika kita tidak bisa SSH ke instance tersebut atau RDP ke instance tersebut, akan sangat susah untuk mencari tahu dimana terjadi kegagalan. Dalam kasus tersebut, sebuah VNC interface ke instance sangat menolong dalam membantu proses troubleshooting. Akan tetapi Eucalyptus tidak memberikan cara untuk menyambungkan instance melalui VNC. Hack berikut akan membantu dalam mensetup interface VNC ke sebuah instance.

	==Instance Windows==		===Instance Windows===

	~~On the~~ NC, edit /usr/share/eucalyptus/gen_kvm_libvirt_xml (if KVM ~~is the~~ hypervisor) ~~to change~~		Di NC, edit /usr/share/eucalyptus/gen_kvm_libvirt_xml (jika kita menggunakan KVM sebagai hypervisor) untuk mengubah

	<devices>		<devices>
Line 59:		Line 59:
	</devices>		</devices>

	to		menjadi

	<devices>		<devices>
Line 78:		Line 78:
	</devices>		</devices>

	~~where~~ A.B.C.D ~~is the~~ IP address ~~of the~~ interface on NC ~~that is reachable from the~~ client ~~machine where you want to run the vnc~~ client. ~~We assume that your~~ NC ~~has~~ 2 ~~interfaces and you are able to use the second~~ interface ~~to reach it without going through~~ CC. ~~Again, this is only for~~ troubleshooting. ~~In a production~~ setup, ~~you may have the~~ NC ~~connected to the outside world only through~~ CC.		Dimana A.B.C.D adalah [[IP address]] dari interface di NC yang dapat dihubungi dari mesin client yang menjalankan VNC client. Kita mengasumsikan NC mempunyai dua (2) interface dan kita dapat menggunakan interface ke dua untuk mencapai NC tanpa melalui CC. Perhatikan bahwa ini hanya digunakan untuk troubleshooting. Pada setup produksi, kita harus menyambungkan NC ke dunia luar hanya melalui CC.

	With these changes, KVM adds the “-vnc” option to the command with the specified NC’s ip address on display number 4.		With these changes, KVM adds the “-vnc” option to the command with the specified NC’s ip address on display number 4.

Onnowpurbo at 01:38, 22 March 2011

2011-03-22T01:38:29Z

← Older revision		Revision as of 01:38, 22 March 2011
Line 35:		Line 35:
	NC akan menjalankan sebuah instance dengan cara melakukan call ke libvirt untuk menjalankan VM. Kita dapat menggunakan tool libvirt seperti virsh untuk troubleshooting berbagai isu sekitar hypervisor.		NC akan menjalankan sebuah instance dengan cara melakukan call ke libvirt untuk menjalankan VM. Kita dapat menggunakan tool libvirt seperti virsh untuk troubleshooting berbagai isu sekitar hypervisor.

	~~Launching an~~ instance ~~with~~ VNC attached(HACK):		Menjalankan sebuah instance dengan VNC attached(HACK):

	~~If the~~ output of euca-describe-instances ~~shows the~~ status ~~of an~~ instance as ‘running’, ~~but if you are not able to~~ SSH ~~into it or~~ RDP ~~into it~~, ~~it is is tough to find out where the failure is~~. ~~In such cases~~, a VNC interface ~~to the~~ instance ~~is generally of great help to troubleshoot further~~. ~~But~~ Eucalyptus ~~does not provide a way of connecting to the~~ instance ~~through~~ VNC. The following hack can help in setting up a VNC interface to the instance.		Jika output euca-describe-instances menunjukan status sebuah instance sebagai ‘running’, tapi jika kita tidak bisa SSH ke instance tersebut atau RDP ke instance tersebut, akan sangat susah untuk mencari tahu dimana terjadi kegagalan. Dalam kasus tersebut, sebuah VNC interface ke instance sangat menolong dalam membantu proses troubleshooting. Akan tetapi Eucalyptus tidak memberikan cara untuk menyambungkan instance melalui VNC. The following hack can help in setting up a VNC interface to the instance.
	Windows ~~Instances~~
			==Instance Windows==

	On the NC, edit /usr/share/eucalyptus/gen_kvm_libvirt_xml (if KVM is the hypervisor) to change		On the NC, edit /usr/share/eucalyptus/gen_kvm_libvirt_xml (if KVM is the hypervisor) to change

Onnowpurbo: /* Libvirt tools */

2011-03-22T01:02:44Z

Libvirt tools

← Older revision		Revision as of 01:02, 22 March 2011
Line 31:		Line 31:
	Perintah Linux seperti ps, top dll. jalan di CC dan NC sangat membantu dalam mengetahui tahapan proses pada Eucalyptus.		Perintah Linux seperti ps, top dll. jalan di CC dan NC sangat membantu dalam mengetahui tahapan proses pada Eucalyptus.

	==Libvirt ~~tools~~==		==Tool Libvirt==

	NC ~~launches the instances by making~~ libvirt ~~calls to launch a~~ VM. ~~You can use~~ libvirt ~~tools like~~ virsh ~~for~~ troubleshooting ~~any~~ hypervisor ~~related issues~~.		NC akan menjalankan sebuah instance dengan cara melakukan call ke libvirt untuk menjalankan VM. Kita dapat menggunakan tool libvirt seperti virsh untuk troubleshooting berbagai isu sekitar hypervisor.

	Launching an instance with VNC attached(HACK):		Launching an instance with VNC attached(HACK):

Onnowpurbo: /* Linux Instances */

2011-03-22T01:00:32Z

Linux Instances

← Older revision		Revision as of 01:00, 22 March 2011
Line 86:		Line 86:
	In the case of Xen, you would modify the relevant sections of /usr/share/eucalyptus/gen_libvirt_xml. We have not tested with Xen, though.		In the case of Xen, you would modify the relevant sections of /usr/share/eucalyptus/gen_libvirt_xml. We have not tested with Xen, though.

	==Linux ~~Instances~~==		==Instance Linux==

	~~You can use the same approach for~~ Linux ~~instances as well~~, ~~with the caveat that you will not see any output with~~ euca-get-console-output as console ~~output does not get written to~~ /var/lib/eucalyptus/instances/<user>/i-xxxxxxxx/console.log. ~~The output will, of course, be displayed though~~ VNC.		Kita dapat menggunakan cara yang sama untuk Instance Linux, dengan catatan kita tidak dapat melihat keluaran apapun euca-get-console-output jika output console tidak di tulis ke /var/lib/eucalyptus/instances/<user>/i-xxxxxxxx/console.log. Output tentu saja dapat di display menggunakan VNC.

	~~NOTE~~: ~~This works only if we are~~ debugging ~~one~~ instance ~~at a time~~. ~~If you attempt to start another~~ instance ~~while one~~ instance ~~is already running~~, KVM ~~will try to attach the same~~ VNC display 4 ~~to the second~~ instance ~~and will fail with the following~~ error in /var/log/libvirtd/qemu/i-XXXXXXXX.log		CATATAN: Cara ini hanya jalan jika kita melakukan debugging satu instance dalam satu waktu. Jika kita berusaha untuk menjalankan instance yang lain pada saat sebuah instance sedang berjalan, KVM akan berusaha untuk menempelkan VNC display 4 yang sama ke instance yang ke dua dan akan gagal dengan error yang tertulis di /var/log/libvirtd/qemu/i-XXXXXXXX.log

	inet_listen_opts: bind(ipv4,A.B.C.D,5904): Address already in use		inet_listen_opts: bind(ipv4,A.B.C.D,5904): Address already in use
	inet_listen_opts:FAILED		inet_listen_opts:FAILED


	==Referensi==		==Referensi==

Onnowpurbo at 00:55, 22 March 2011

2011-03-22T00:55:28Z

← Older revision		Revision as of 00:55, 22 March 2011
Line 23:		Line 23:
	\|}		\|}

	~~The~~ logging ~~level is controlled by the~~ LOGLEVEL ~~macro in~~ eucalyptus.conf ~~of the respective component~~. ~~The~~ log ~~levels are~~ DEBUG, INFO, WARN, ERROR, ~~and~~ FATAL ~~(in descending order of verbosity)~~. ~~The default~~ level is DEBUG (~~everything~~).		Level logging di atur oleh macro LOGLEVEL di eucalyptus.conf untuk masing-masing komponen. Level log yang ada adalah DEBUG, INFO, WARN, ERROR, dan FATAL. Default level adalah DEBUG (untuk semua komponen).

	‘tail -f ‘ ~~on the~~ log ~~files is a good way to understand what is happening with the components of~~ Eucalyptus.		‘tail -f ‘ pada file log adalah cara yang baik untuk mengetahui apa yang terjadi pada komponen Eucalyptus.

	==Linux ~~commands~~==		==Perintah Linux==

	Linux ~~comamnds like~~ ps, top ~~etc~~. ~~run on~~ CC ~~and~~ NC ~~are helpful to understand the state of the processes related to~~ Eucalyptus.		Perintah Linux seperti ps, top dll. jalan di CC dan NC sangat membantu dalam mengetahui tahapan proses pada Eucalyptus.

	==Libvirt tools==		==Libvirt tools==

Onnowpurbo at 00:52, 22 March 2011

2011-03-22T00:52:22Z

← Older revision		Revision as of 00:52, 22 March 2011
Line 3:		Line 3:
	File log berikut akan sangat menolong pada saat melakukan debugging berbagai masalah pada pada Eucalyptus yang berjalan:		File log berikut akan sangat menolong pada saat melakukan debugging berbagai masalah pada pada Eucalyptus yang berjalan:

			{\| border="1" cellpadding=2 style="border-collapse: collapse"
	Eucalyptus Component Log file(s)		! Eucalyptus Component
	CC cc.log, httpd-cc_error_log, cc-registration.log		! Log file(s)
	NC nc.log, httpd-nc_error_log, euca_test_nc.log		\|-
	CLC cloud-debug.log, cloud-error.log, cloud-output.log, axis2c.log		\| CC
	SC sc-stats.log, sc-registration.log		\| cc.log, httpd-cc_error_log, cc-registration.log
	WS3 walrus-stats.log, walrus-registration.log		\|-
			\| NC
			\| nc.log, httpd-nc_error_log, euca_test_nc.log
			\|-
			\| CLC
			\| cloud-debug.log, cloud-error.log, cloud-output.log, axis2c.log
			\|-
			\| SC
			\| sc-stats.log, sc-registration.log
			\|-
			\| WS3
			\| walrus-stats.log, walrus-registration.log
			\|}

	The logging level is controlled by the LOGLEVEL macro in eucalyptus.conf of the respective component. The log levels are DEBUG, INFO, WARN, ERROR, and FATAL (in descending order of verbosity). The default level is DEBUG (everything).		The logging level is controlled by the LOGLEVEL macro in eucalyptus.conf of the respective component. The log levels are DEBUG, INFO, WARN, ERROR, and FATAL (in descending order of verbosity). The default level is DEBUG (everything).

Onnowpurbo at 00:51, 22 March 2011

2011-03-22T00:51:19Z

← Older revision		Revision as of 00:51, 22 March 2011
Line 1:		Line 1:
	Eucalyptus ~~Log files~~		==File Log Eucalyptus==

			File log berikut akan sangat menolong pada saat melakukan debugging berbagai masalah pada pada Eucalyptus yang berjalan:

	~~The following log files help in debugging issues encountered while working with Eucalyptus:~~

	Eucalyptus Component Log file(s)		Eucalyptus Component Log file(s)

Onnowpurbo: /* Pranala Menarik */

2011-01-06T12:33:00Z

Pranala Menarik

← Older revision		Revision as of 12:33, 6 January 2011
Line 89:		Line 89:
	==Pranala Menarik==		==Pranala Menarik==

	* [[Ubuntu Enterprise Cloud: ~~Eucalyptus Beginner’s Guide~~]] '''RECOMMENDED'''		* [[Ubuntu Enterprise Cloud: Panduan Untuk Pemula]] '''RECOMMENDED'''
	* [[Ubuntu Enterprise Cloud: Instalasi UEC]]		* [[Ubuntu Enterprise Cloud: Instalasi UEC]]
	* [[Cloud Computing]]		* [[Cloud Computing]]

Onnowpurbo at 01:17, 28 December 2010

2010-12-28T01:17:15Z

← Older revision		Revision as of 01:17, 28 December 2010
Line 2:		Line 2:

	The following log files help in debugging issues encountered while working with Eucalyptus:		The following log files help in debugging issues encountered while working with Eucalyptus:
	Eucalyptus Component Log file(s)
	CC cc.log, httpd-cc_error_log, cc-registration.log		Eucalyptus Component Log file(s)
	NC nc.log, httpd-nc_error_log, euca_test_nc.log		CC cc.log, httpd-cc_error_log, cc-registration.log
	CLC cloud-debug.log, cloud-error.log, cloud-output.log, axis2c.log		NC nc.log, httpd-nc_error_log, euca_test_nc.log
	SC sc-stats.log, sc-registration.log		CLC cloud-debug.log, cloud-error.log, cloud-output.log, axis2c.log
	WS3 walrus-stats.log, walrus-registration.log		SC sc-stats.log, sc-registration.log
			WS3 walrus-stats.log, walrus-registration.log

	The logging level is controlled by the LOGLEVEL macro in eucalyptus.conf of the respective component. The log levels are DEBUG, INFO, WARN, ERROR, and FATAL (in descending order of verbosity). The default level is DEBUG (everything).		The logging level is controlled by the LOGLEVEL macro in eucalyptus.conf of the respective component. The log levels are DEBUG, INFO, WARN, ERROR, and FATAL (in descending order of verbosity). The default level is DEBUG (everything).

	‘tail -f ‘ on the log files is a good way to understand what is happening with the components of Eucalyptus.		‘tail -f ‘ on the log files is a good way to understand what is happening with the components of Eucalyptus.
	Linux commands
			==Linux commands==

	Linux comamnds like ps, top etc. run on CC and NC are helpful to understand the state of the processes related to Eucalyptus.		Linux comamnds like ps, top etc. run on CC and NC are helpful to understand the state of the processes related to Eucalyptus.
	Libvirt tools
			==Libvirt tools==

	NC launches the instances by making libvirt calls to launch a VM. You can use libvirt tools like virsh for troubleshooting any hypervisor related issues.		NC launches the instances by making libvirt calls to launch a VM. You can use libvirt tools like virsh for troubleshooting any hypervisor related issues.

	Launching an instance with VNC attached(HACK):		Launching an instance with VNC attached(HACK):

Line 25:		Line 29:
	On the NC, edit /usr/share/eucalyptus/gen_kvm_libvirt_xml (if KVM is the hypervisor) to change		On the NC, edit /usr/share/eucalyptus/gen_kvm_libvirt_xml (if KVM is the hypervisor) to change

	<devices>		<devices>
	<disk type='file'>		<disk type='file'>
	<source file='BASEPATH/disk'/>		<source file='BASEPATH/disk'/>
	<target dev='sda'/>		<target dev='sda'/>
	</disk>		</disk>
	<interface type='bridge'>		<interface type='bridge'>
	<source bridge='BRIDGEDEV'/>		<source bridge='BRIDGEDEV'/>
	<mac address='PRIVMACADDR'/>		<mac address='PRIVMACADDR'/>
	<model type='e1000'/>		<model type='e1000'/>
	</interface>		</interface>
	<serial type="file">		<serial type="file">
	<source path='BASEPATH/console.log'/>		<source path='BASEPATH/console.log'/>
	<target port='1'/>		<target port='1'/>
	</serial>		</serial>
	</devices>		</devices>

	to		to

	<devices>		<devices>
	<disk type='file'>		<disk type='file'>
	<source file='BASEPATH/disk'/>		<source file='BASEPATH/disk'/>
	<target dev='sda'/>		<target dev='sda'/>
	</disk>		</disk>
	<interface type='bridge'>		<interface type='bridge'>
	<source bridge='BRIDGEDEV'/>		<source bridge='BRIDGEDEV'/>
	<mac address='PRIVMACADDR'/>		<mac address='PRIVMACADDR'/>
	<model type='e1000'/>		<model type='e1000'/>
	</interface>		</interface>
	<serial type="file">		<serial type="file">
	<source path='BASEPATH/console.log'/>		<source path='BASEPATH/console.log'/>
	<target port='1'/>		<target port='1'/>
	</serial>		</serial>
	<graphics type='vnc' listen='A.B.C.D' port='5904'/>		<graphics type='vnc' listen='A.B.C.D' port='5904'/>
	</devices>		</devices>

	where A.B.C.D is the IP address of the interface on NC that is reachable from the client machine where you want to run the vnc client. We assume that your NC has 2 interfaces and you are able to use the second interface to reach it without going through CC. Again, this is only for troubleshooting. In a production setup, you may have the NC connected to the outside world only through CC.		where A.B.C.D is the IP address of the interface on NC that is reachable from the client machine where you want to run the vnc client. We assume that your NC has 2 interfaces and you are able to use the second interface to reach it without going through CC. Again, this is only for troubleshooting. In a production setup, you may have the NC connected to the outside world only through CC.
Line 68:		Line 72:

	In the case of Xen, you would modify the relevant sections of /usr/share/eucalyptus/gen_libvirt_xml. We have not tested with Xen, though.		In the case of Xen, you would modify the relevant sections of /usr/share/eucalyptus/gen_libvirt_xml. We have not tested with Xen, though.
	Linux Instances
			==Linux Instances==

	You can use the same approach for Linux instances as well, with the caveat that you will not see any output with euca-get-console-output as console output does not get written to /var/lib/eucalyptus/instances/<user>/i-xxxxxxxx/console.log. The output will, of course, be displayed though VNC.		You can use the same approach for Linux instances as well, with the caveat that you will not see any output with euca-get-console-output as console output does not get written to /var/lib/eucalyptus/instances/<user>/i-xxxxxxxx/console.log. The output will, of course, be displayed though VNC.
Line 74:		Line 79:
	NOTE: This works only if we are debugging one instance at a time. If you attempt to start another instance while one instance is already running, KVM will try to attach the same VNC display 4 to the second instance and will fail with the following error in /var/log/libvirtd/qemu/i-XXXXXXXX.log		NOTE: This works only if we are debugging one instance at a time. If you attempt to start another instance while one instance is already running, KVM will try to attach the same VNC display 4 to the second instance and will fail with the following error in /var/log/libvirtd/qemu/i-XXXXXXXX.log

	inet_listen_opts: bind(ipv4,A.B.C.D,5904): Address already in use		inet_listen_opts: bind(ipv4,A.B.C.D,5904): Address already in use
	inet_listen_opts:FAILED		inet_listen_opts:FAILED