google compute engine vps

[irtusb]

Google offers a paid service called Compute Engine. It allow creation and management of virtual machines running inside Google's infrastructure.

I went a bit crazy and managed to boot haiku r1b2 and hrev54429 (x86_64) on the smallest machine they offer (f1-micro: 1vCpu + 600mb RAM)

• Beta2 went kdl
• hrev54429 showed full colored icons, but then nothing, it stopped there

attached serial output and last status screenshot

[X512]

X86EMU_exec

bios_interrupt

vesa_init

Can you try to boot in EFI mode? Also you can try to disable BIOS calls in boot options.

[irtusb]

Replying to X512:

X86EMU_exec

bios_interrupt

vesa_init

Can you try to boot in EFI mode? Also you can try to disable BIOS calls in boot options.

that is actually very difficult. there is no way to configure boot nor to attach keyboard or mouse to it. The only way to send command to the machine is via ssh. It is possible to see screen but not at realtime.

I gave it another try. This time i dd'ed hrev54429 into a disk instead of following a rather convoluted way to setup disk images and got a different result. The following KDL

PANIC: I/O operation would need to be cut.
Welcome to Kernel Debugging Land...
Thread 253 "scsi scheduler 1" running on CPU 0
stack trace for thread 253 "scsi scheduler 1"
    kernel stack: 0xffffffff812dc000 to 0xffffffff812e1000
frame                       caller             <image>:function + offset
 0 ffffffff812e0b28 (+  24) ffffffff8014fa1c   <kernel_x86_64> arch_debug_call_with_fault_handler + 0x16
 1 ffffffff812e0b40 (+  80) ffffffff800ae1b8   <kernel_x86_64> debug_call_with_fault_handler + 0x88
 2 ffffffff812e0b90 (+  96) ffffffff800afb41   <kernel_x86_64> kernel_debugger_loop(char const*, char const*, __va_list_tag*, int) + 0xf1
 3 ffffffff812e0bf0 (+  80) ffffffff800afe3e   <kernel_x86_64> kernel_debugger_internal(char const*, char const*, __va_list_tag*, int) + 0x6e
 4 ffffffff812e0c40 (+ 240) ffffffff800b01a7   <kernel_x86_64> panic + 0xb7
 5 ffffffff812e0d30 (+ 144) ffffffff817e66e6   <scsi_periph> read_write(scsi_periph_device_info*, scsi_ccb*, IOOperation*, unsigned long, unsigned long, physical_entry*, unsigned long, bool, unsigned long*) + 0xd6
 6 ffffffff812e0dc0 (+ 128) ffffffff817e7408   <scsi_periph> periph_io(scsi_periph_device_info*, IOOperation*, unsigned long*) + 0xa8
 7 ffffffff812e0e40 (+  64) ffffffff817e0fd5   <scsi_disk> do_io(void*, IOOperation*) + 0x25
 8 ffffffff812e0e80 (+ 304) ffffffff800dfd26   <kernel_x86_64> IOSchedulerSimple::_Scheduler() + 0x726
 9 ffffffff812e0fb0 (+  32) ffffffff8008af17   <kernel_x86_64> common_thread_entry(void*) + 0x37
10 ffffffff812e0fd0 (+2127687728) ffffffff812e0fe0   
kdebug> 

Attached full serial output

[irtusb]

using dd

[waddlesplash]

That seems strange, I would think Google Compute Engine would be using virtio here?

CC'ing kallisti5 as I know he has successfully run Haiku on GCE.

[diver]

What happens if you blacklist scsi_periph by creating /system/settings/packages with this content:

Package haiku  {
	EntryBlacklist {
		add-ons/kernel/generic/scsi_periph
	}
}

For that you will probably need bfs_fuse working though.

[irtusb]

blacklisting scsi_periph

[mmlr]

It is using virtio SCSI and not virtio block devices, so that would be expected. The virtio SCSI interface is more advanced and allows for things like discard to work, which is why it is often used in virtual environments to free unused block storage.

The HaikuPorts builders at Hetzner also run on virtio SCSI and that hasn't been a problem so far.

There appear to be two disks of the same size, the first being empty and the second containing an anyboot image, is that correct?

[irtusb]

@mmlr, short answer: no, a single disk was present

All of them x86_64

Before I forget. Procedures so far

• beta2-screen and beta2-serial: beta anyboot from homepage unziped, renamed, targzed, uploaded to cloud storage, made a compute engine "image", created VM based on this image (google automagically created a hard disk for the instance) and run
• 54429-screen and 54429-serial: same as above but using nightly hrev 54429
• 54429-serial2: in a working debian VM downloaded, unziped, dd into empty disk. Shutdown, attached disk as boot image to a new VM and run
• blacklist.jpg: in a working debian VM: git clone haiku and buildtools, jam '<build>bfs_fuse', losetup anyboot iso, bfs_fuse /dev/loop0p1, nano system/config/packages, umount and remove loop device, dd into new hard disk, use as boot into new VM and run.

[irtusb]

As cloud based services are not a target of Haiku and this one specifically cannot be interacted with keyboard and mouse in realtime it is not really worth to keep this ticket open. Please close this

[kallisti5]

I think there could be a valid story behind this one. We have discussed haikuporter auto starting and stopping Haiku compute instances for port builds... however historically not at GCP given their high costs.

There are alternatives like Vultr (which also successfully use virtio) I use for my Haiku machines, and our virtio drivers work well there.

I ran a Haiku machine under the Haiku, Inc. google account a while ago via building a custom disk image.

I personally am ok keeping this one open to do a bit of additional investigation into limitations of Haiku under GCP

[kallisti5]

by the way, the biggest suspect issue here is the machine selection...

"f1-micro: 1vCpu + 600mb RAM"

Not sure our x86_64 machine will run in that. I think 512 MiB has been a bit too tight for me in the past. 256 MiB is *definitely* too small given my previous experiences.

The cloud is just someone elses computer... that 1 vCpu isn't any faster than an Intel Celeron server :-)