Originally Posted by Randicus Draco Albus

Replace a trusted and reliable initialisation system with a Comical creation? Even Buntu will not be using it. They will be going with systemd after failing to convince Debian to adopt their upstart.

Originally Posted by ReaperX7

Not to put down any efforts by the Debian developers, but they should focus on a long term stable init and service management system rather than one that has not been completed and fully finalized.

Originally Posted by vl23

LOL no, Bare metal:
appp-->kernel-->drivers--hardware
VM appinguest-->kernelinguest-->driversinguest-->virtualization infrastructure and host kernel virtualization components-->on-metal hardware
It would only be useful if you are using a jail, and that is not what I am doing, the I/O wait and memory access time would be higher since VM mapping would have to go through 2 kernels instead of one, and since the disk is a file on the host system.

Originally Posted by Randicus Draco Albus

My guess is they see the writing on the wall. It is only a matter of time before Red Hat gets systemd and whatever else will be "attached to it" forced on everyone. Perhaps Debian's developers are unwilling to fight the inevitable alone.

Originally Posted by Randicus Draco Albus

My guess is they see the writing on the wall. It is only a matter of time before Red Hat gets systemd and whatever else will be "attached to it" forced on everyone. Perhaps Debian's developers are unwilling to fight the inevitable alone.

Originally Posted by jens

Sorry for the late reply, but that's just ridiculous.

KVM can be can be instructed to do whatever you want when booting.
Real hardware needs to be accessed and validated (taking about 75% of your boot time).

GNU/Hurd boots under 1 second in KVM for me (using neither sysv or sysd), that's not even possible on bare metal ...

Originally Posted by vl23

Oh, so the I/O penalty(by far the biggest bottleneck in computing since forever) is magically less on virtualized hardware than it is on bare metal eh, and a kernel somehow does not interact in the same way with virtualized hardware as it does with regular stuff, do you have any tangible proof of your claims other than, oh it is faster for me.
maybe a few unbiased and peer-reviewed articles not churned out by VMWare or the other Cloud pushers

Originally Posted by TobiSGD

It should be as easy as to prove your claims that VMs have to boot slower than bare metal, just do a few benchmarks.

Originally Posted by "Kernel Virtual Machine (KVM): Best practices for KVM - IBM";

Most Linux file systems ensure that the metadata and files, that are stored within the file system, are
aligned on 4 KB (page) boundaries. The second extended file system (ext2) and the third extended file
system (ext3) are most commonly used. Both file systems use 4 KB alignment for all data.
Because a disk image file is a file in the file system, the disk image file is 4 KB aligned. However, when
the disk image file is partitioned using the default or established partitioning rules, partitions can begin
on boundaries or offsets within the image file that are not 4 KB aligned.
The probability of a partition, within a disk image file, starting on a 4 KB alignment is low for the
following reasons:
v Partitions within a disk image file typically start and end on cylinder boundaries.
v Cylinder sizes typically are not multiples of 4 KB.
Within the guest operating system, disk I/O operations occur with blocks that are offset in 4 KB
multiples from the beginning of the partitions. However, the offset of the partition in the disk image file
is typically not 4 KB aligned with respect to the following items:
v The beginning of the disk image file.
v The file system in which the disk image file is located.
As a result, when a guest operating system initiates I/O operations of 4 KB to the partition in the disk
image file, the I/O operations span two 4 KB pages of the disk image file. The disk image file is located
in the page cache of the hypervisor. If an I/O operation is a write request, the hypervisor must perform a
Read-Modify-Write (RMW) operation to complete the I/O request.
For example, the guest operating system initiates 4 KB write operation. The hypervisor reads a page to
update the last 1 KB of data. Then, the hypervisor reads the next page to update the remaining 3 KB of
data. After the updates are finished, the hypervisor writes both modified pages back to the disk. For
every write I/O operation from the guest operating system, the hypervisor must perform up to two read
operations and up to two write operations. These extra read and write operations produce an I/O
Best practices for KVM
9multiplication factor of four. The additional I/O operations create a greater demand on the storage
devices. This increased demand can affect the throughput and response times of all the software using
the storage devices.
To avoid the I/O affects from partitions that are not 4 KB aligned, ensure that you optimally partition the
disk image file. Ensure that partitions start on boundaries that adhere to the 4 KB alignment
recommendation. Most standard partitioning tools default to using cylinder values to specify the start
and end boundaries of each partition. However, based on default established values used for disk
geometry, like track size and heads per cylinder, cylinder sizes rarely fall on 4 KB alignment values. To
specify an optimal start value, you can switch the partition tool to the Advanced or Expert modes.

Originally Posted by vl23

it is simple logic damn it, a VM can't utilize the underlying hardware at 100%, even POWER and Z have at the least a 5% penalty for their virtualization solutions, which are light-years price and performance-wise when compared to x86 virtualization capabilities, and there is now way to have your I/O work faster when your OS is on a disk image that is basically just a file stuck in the host's FS, unless of course you are using some caching tricks, which I am not, and I really doubt that the host page cache will help all that much, besides even with bare metal you still have DMA, the on-device buffer and the disk's own readahead.

EDIT:

But please don't take my word on it, here is what Big Blue has to say on the subject:



Here is the source document http://pic.dhe.ibm.com/infocenter/ln...ctices_pdf.pdf

Originally Posted by vl23

it is simple logic damn it, a VM can't utilize the underlying hardware at 100%, even POWER and Z have at the least a 5% penalty for their virtualization solutions, which are light-years price and performance-wise when compared to x86 virtualization capabilities, and there is now way to have your I/O work faster when your OS is on a disk image that is basically just a file stuck in the host's FS, unless of course you are using some caching tricks, which I am not, and I really doubt that the host page cache will help all that much, besides even with bare metal you still have DMA, the on-device buffer and the disk's own readahead.

EDIT:

But please don't take my word on it, here is what Big Blue has to say on the subject:



Here is the source document http://pic.dhe.ibm.com/infocenter/ln...ctices_pdf.pdf

Originally Posted by TobiSGD

With the advent of SSDs and Advanced Format harddisks all modern OSes switched to automatically aligning partitions on 4KB boundaries, the only partitioning tool that still does not do that by default, whichever reason the developers may have for that, is cfdisk, which still starts the first partition on logical sector 63. Any other tool aligns correctly by default. Also, this is a partitioning issue that happen on bare metal, too, for example on SSDs or Advanced Format disks (disks with 4KB physical block size) and is not really related to VMs.

I still recommend to back up your thought processes about boot speed under different conditions with verifiable data from benchmarks. The easiest and fastest way to prove your hypothesis that booting on VMs has to be slower than on bare metal.

Originally Posted by vl23

I'd rather take IBM's word over yours, sorry but the technology behemoth with the record numbers of patents and years at the top of Gartner's various rankings just beats you for some reason

Originally Posted by TobiSGD

Actually, I would recommend to neither take my words nor IBM's words, but to come up with actual data. That is how it usually works: Make a claim, back it up with data. I don't care how many patents IBM has, nor should you.

Nope, I have not made actual benchmarks, I can only report from what I have seen when experimenting with VMs, where for example an Ubuntu installation in a VM started much faster than the same system on bare metal. I have not investigated the reasons for that nor made actual benchmarks.
This is not clear to me, are you speaking about memory pages or filesystem blocks? If you mean file-system blocks, that is neither a new feature nor a feature of the OS, but a feature of the filesystem in use, ReiserFS can do this for a long time already. In any way this is not related to performance of VMs vs. bare metal.

To make that clear: The quotes from the IBM article you presented are not related to VMs in general being slower, but are tips to prevent performance loss due to wrong configurations. It may be possible that VMs boot slower than bare metal, but from my experience this is not the case. If you are that certain that you are right it shouldn't be a problem to backup that claims with actual data. If you want do that is of course up to you, but without that data your claims are as inappropriate as evidence as my experiences.