Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Few fixes to the libvirt.xml: #53

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Few fixes to the libvirt.xml: #53

wants to merge 2 commits into from

Conversation

mykaul
Copy link

@mykaul mykaul commented Aug 9, 2017

Move to virtio (hard disk, NICs), SCSI (cd-rom)
Removed USB controller (not needed), Balloon driver.
Added virtio-rng controller.

I did not remove the graphics and replaced with a console, though
it can be done as well.

Changed default iothreads from threads to native.

Tested on Fedora 26, but should work on EL7 hosts as well.

Move to virtio (hard disk, NICs), SCSI (cd-rom)
Removed USB controller (not needed), Balloon driver.
Added virtio-rng controller.

I did not remove the graphics and replaced with a console, though
it can be done as well.
@zakame
Copy link

zakame commented Aug 10, 2017

This looks better than my PR #52 🎉 hope it gets in! 😻

kvm.go Outdated
@@ -134,7 +142,7 @@ func (d *Driver) GetCreateFlags() []mcnflag.Flag {
mcnflag.StringFlag{
Name: "kvm-io-mode",
Usage: "Disk IO mode: threads, native",
Value: "threads",
Value: "native",
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems to break on my system:

θ61° [zakame:~] % docker-machine create --driver=kvm --engine-registry-mirror=http://192.168.122.1:50000 --swarm-master swarm-manager-1
Running pre-create checks...
Creating machine...
(swarm-manager-1) Copying /home/zakame/.docker/machine/cache/boot2docker.iso to /home/zakame/.docker/machine/machines/swarm-manager-1/boot2docker.iso...
(swarm-manager-1) Creating SSH key...
(swarm-manager-1) Failed to start: virError(Code=1, Domain=10, Message='internal error: process exited while connecting to monitor: 2017-08-10T03:23:14.589561Z qemu-kvm: -drive file=/home/zakame/.docker/machine/machines/swarm-manager-1/swarm-manager-1.img,format=raw,if=none,id=drive-virtio-disk0,aio=native: aio=native was specified, but it requires cache.direct=on, which was not specified.')
Error creating machine: Error in driver during machine creation: virError(Code=1, Domain=10, Message='internal error: process exited while connecting to monitor: 2017-08-10T03:23:14.589561Z qemu-kvm: -drive file=/home/zakame/.docker/machine/machines/swarm-manager-1/swarm-manager-1.img,format=raw,if=none,id=drive-virtio-disk0,aio=native: aio=native was specified, but it requires cache.direct=on, which was not specified.')

Setting kvm-cache-mode set to none or directsync, or any other mode with explicit cache.direct=on got it to work again.

See also https://bugzilla.redhat.com/show_bug.cgi?id=1086704

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, reverted the change to switch the default IO mode from threads to native and kept it on threads.

@gbraad
Copy link

gbraad commented Aug 28, 2017

This however would also need to be tested with other guest OS, besides Fedora and CentOS/RHEL. HOW about minikube, or boot2docker ISOs?

@zakame
Copy link

zakame commented Aug 28, 2017

@gbraad it should work on minikube/boot2docker based machines as I'm using this PR myself, on a Slackware host

@mykaul
Copy link
Author

mykaul commented Aug 28, 2017

@gbraad - this PR came from me trying to use minikube with bookt2docker ISO and being a bit concerned about the old (vintage?) devices that were used. It works OK with minikube 0.21.0, and on top of it I've ran K8S 1.7.0, 1.7.2, 1.7.3.

@mykaul
Copy link
Author

mykaul commented Sep 18, 2017

ping?

@mykaul
Copy link
Author

mykaul commented Nov 30, 2017

Anything I can help with to push this?

@afbjorklund
Copy link

I thought virtio devices were normally called /dev/vda and not /dev/sda ?
At least that is what I got, when I did the same thing (virtio) with qemu-kvm...

There was also an interesting side effect, in that their order got reversed.
That is: without virtio I get /dev/sda1 (A) and with I get dev/vdb1 (B) :

-cdrom boot2docker.iso disk.qcow2

Disk /dev/sda: 20 GB, 20971524608 bytes, 40960009 sectors
2549 cylinders, 255 heads, 63 sectors/track
Units: cylinders of 16065 * 512 = 8225280 bytes

Device  Boot StartCHS    EndCHS        StartLBA     EndLBA    Sectors  Size Id Type
/dev/sda1    123,0,1     1023,254,63    1975995   40949684   38973690 18.5G 83 Linux
/dev/sda2    0,1,1       122,254,63          63    1975994    1975932  964M 82 Linux swap

Partition table entries are not in disk order
Note: sector size is 2048 (not 512)
Disk /dev/sr0: 45 MB, 47185920 bytes, 92160 sectors
11 cylinders, 64 heads, 32 sectors/track
Units: cylinders of 2048 * 2048 = 4194304 bytes

Device   Boot StartCHS    EndCHS        StartLBA     EndLBA    Sectors  Size Id Type
/dev/sr0p1 *  0,0,1       44,63,32             0      92159      92160  180M 17 Hidden HPFS/NTFS

-drive file=boot2docker.iso,index=2,media=cdrom,if=virtio -drive file=disk.qcow2,index=0,media=disk,if=virtio

Disk /dev/vda: 45 MB, 47185920 bytes, 92160 sectors
45 cylinders, 64 heads, 32 sectors/track
Units: cylinders of 2048 * 512 = 1048576 bytes

Device  Boot StartCHS    EndCHS        StartLBA     EndLBA    Sectors  Size Id Type
/dev/vda1 *  0,0,1       44,63,32             0      92159      92160 45.0M 17 Hidden HPFS/NTFS
Disk /dev/vdb: 20 GB, 20971524608 bytes, 40960009 sectors
40634 cylinders, 16 heads, 63 sectors/track
Units: cylinders of 1008 * 512 = 516096 bytes

Device  Boot StartCHS    EndCHS        StartLBA     EndLBA    Sectors  Size Id Type
/dev/vdb1    1023,15,63  1023,15,63     1954512   40959071   39004560 18.5G 83 Linux
/dev/vdb2    0,1,1       1023,15,63          63    1954511    1954449  954M 82 Linux swap

Partition table entries are not in disk order

@mykaul
Copy link
Author

mykaul commented Jan 14, 2018

I've changed (in my patch) the CDROM device to use SCSI, which is therefore using /dev/sdX. If that's an issue, we can revert it back to IDE (or SATA). I wanted it to be quick as we read from it (and IDE is somewhat slow). But I really have not touched this patch for months as it did not get any attention whatsoever.

@afbjorklund
Copy link

afbjorklund commented Jan 14, 2018

I haven't benchmarked sda vs. vdb, both seemed to be "fast enough"...
Made my own driver instead, since this doesn't work without libvirt access.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants