When I create a new disk image (using packer), and then import it into Cloudmin as a new system image, and then create a new VM from the image, I have to specify that it is a VirtIO disk. If I choose "Based on image" it fails to detect that the disk is /dev/vdaX, and tries to mount /dev/sdaX (which doesn't exist).
I can't figure out how this detection is supposed to work, so I don't have any good theories about why it's wrong. Though, the image does use UUID in the /etc/fstab, rather than the device path. Is that, perhaps, the problem with detection here?
Status:
Closed (fixed)
Comments
Oh, and this is a KVM image on CentOS (the image, however, is for Debian 9, but this problem occurs on pretty much every distro I've tried).
Submitted by JamieCameron on Sat, 07/08/2017 - 12:10 Comment #2
The way this is supposed to work normally is that when you create an image from a VM, Cloudmin detects if that VM was using virtIO and records this in the image. However, when importing an image this isn't (currently possible) as no VM is created.
I suppose one option would be to ask the user on the image import form if it's using virtIO?
OK, so it's not a bug so much as a feature request. I'll see if there's some reliable way to detect it from the image. I dunno if I want users to have to understand what their image uses, and it seems like it ought to be detectable somehow.
But, in the meantime, how do downloadable images from, say, Stacklet work? I mean, Cloudmin seems to get those right and they don't have existing Cloudmin meta data. I really want to figure out how we can deliver a "Just Works" experience, that doesn't require to user to know so much.
Submitted by JamieCameron on Sat, 07/08/2017 - 23:01 Comment #4
The current code assumes that all downloaded images don't use virtIO mounts or grub config by default, and so adjusts the extracted filesystem to match at VM creation time .. which is the right thing to do for Stacklet images. But it sounds like in your case, you started with an image that did use virtIO ?
Seems like it is. I did some spelunking in the Packer docs, and it does default to virtio disk driver.
Turning on VirtIO at VM creation time made it boot, whereas without having it turned on it wouldn't boot after creation (no errors during creation, it just failed to start and couldn't find the root filesystem after boot, which I could see in the VNC console).
If we were to try to detect it, the /boot/grub.cfg is the only obvious place I can find references to the virtual disk, but it's pretty clear there:
The kernel boot line is:
linux /boot/vmlinuz-4.9.0-3-amd64 root=/dev/vda1 ro quietJust grepping for vda in grub.cfg seems like a reasonable way to check.
Is there a reason we wouldn't want VirtIO as the default?
Submitted by JamieCameron on Sun, 07/09/2017 - 13:16 Comment #6
Ok, what I'll do in the next release is for imported images where the virtIO mode isn't know, always adjust grub.cfg and /etc/fstab to be correct - even if it was possibly already correct.
Submitted by JamieCameron on Sun, 07/09/2017 - 13:16 Comment #7
Submitted by IssueBot on Sun, 07/23/2017 - 13:30 Comment #8
Automatically closed - issue fixed for 2 weeks with no activity.