This is related to the KVM instance referenced in https://www.virtualmin.com/node/14808
This KVM instance was auto-detected when the server was added as a KVM Host. The problem is that if I shut down the KVM instance and then try to start it through Cloudmin, it is started with a much more abbreviated set of options which does not include the extra drives that should be attached to the VM.
If I start the VM through virt-manager, this is the process that is started:
root 25870 1 42 16:16 ? 00:14:51 /usr/libexec/qemu-kvm -S -M rhel5.4.0 -m 4096 -smp 4 -name klingon -uuid 5f0290ca-a729-5a79-18bf-b40285d30c20 -no-kvm-pit-reinjection -monitor pty -pidfile /var/run/libvirt/qemu//klingon.pid -boot c -drive file=/boot_drives/klingon.img,if=virtio,index=0,boot=on,cache=none -drive file=,if=ide,media=cdrom,index=2 -drive file=/dev/disk/by-path/ip-10.7.7.5:3260-iscsi-iqn.1986-03.com.sun:02:5c09ee61-ad3d-6b27-d1bd-d5b2b9008e10-lun-0,if=virtio,index=1 -net nic,macaddr=54:52:00:0e:41:9c,vlan=0,model=virtio -net tap,fd=16,script=,vlan=0,ifname=vnet0 -serial pty -parallel none -usb -vnc 127.0.0.1:0 -k en-us
if I start it through Cloudmin, this is the process that gets started:
root 27646 1 49 16:55 ? 00:00:07 /usr/libexec/qemu-kvm -name klingon -m 4096 -drive file=/boot_drives/klingon.img,if=virtio,index=0,boot=on,cache=none -boot c -serial stdio -vnc :1
Seemingly important options that get dropped include:
-M rhel5.4.0
-smp 4
-uuid 5f0290ca-a729-5a79-18bf-b40285d30c20
-no-kvm-pit-reinjection
-drive file=/dev/disk/by-path/ip-10.7.7.5:3260-iscsi-iqn.1986-03.com.sun:02:5c09ee61-ad3d-6b27-d1bd-d5b2b9008e10-lun-0,if=virtio,index=1
-net nic,macaddr=54:52:00:0e:41:9c,vlan=0,model=virtio
I guess if the VM was created through Cloudmin, then we would not run into these issues?
I'm also guessing you are trying to avoid integrating with libvirt using Sys::Virt? It would certainly simplify things if the config interoperated with libvirt...
Comments
Submitted by rheilbroun on Wed, 06/30/2010 - 16:44 Comment #1
Submitted by JamieCameron on Thu, 07/01/2010 - 01:46 Comment #2
Those missing drives look like the biggest issue - Cloudmin should be importing them automatically.
Was this system added after you applied the fix from your previous bug?
Submitted by rheilbroun on Thu, 07/01/2010 - 09:56 Comment #3
Yes, the system was added after applying the fix. Without the fix it wouldn't even add the KVM instance.
Submitted by JamieCameron on Thu, 07/01/2010 - 18:11 Comment #4
Could you run the following command and paste the output here :
grep kvm_drives /etc/webmin/servers/*.serv
Submitted by rheilbroun on Thu, 07/01/2010 - 22:23 Comment #5
# grep kvm_drives /etc/webmin/servers/*.serv
/etc/webmin/servers/1277930160267180.serv:kvm_drives=file=/boot_drives/klingon.img,if=virtio,index=0,boot=on,cache=none
Submitted by JamieCameron on Fri, 07/02/2010 - 01:13 Comment #6
Ok, I found another bug that causes import of KVM systems with multiple disks to fail :-(
I can send a patch to fix this if you like, or you can wait for Cloudmin 4.7.
Submitted by rheilbroun on Fri, 07/02/2010 - 10:42 Comment #7
It can wait, we are using the libvirt based tools for now and I had to put this VM into production without cloudmin management since it was holding back some other work.
Submitted by JamieCameron on Fri, 07/02/2010 - 19:26 Comment #8
Ok .. you shouldn't see this kind of issue with VMs created from within cloudmin
Submitted by JamieCameron on Sun, 07/11/2010 - 22:13 Comment #9
Cloudmin 4.8 will include a fix that will preserve all custom command-line flags when importing a VM.
Submitted by Issues on Mon, 07/26/2010 - 03:22 Comment #10
Automatically closed -- issue fixed for 2 weeks with no activity.