So what is the proposed fix? Just to find some way to warn when the user isn't using the correct systemvm template (the new one required for 4.2 has been based on Wheezy for awhile), other than nothing working and them having to look in the logs? This is probably a good idea, we can perhaps have a shell script that goes through everything on the template and makes sure everything is installed (e.g. dnsmasq-utils, haproxy, virtio-console, and every other dependency). It might be useful for those rolling their own system vms. It may be tough to keep it up to date, but it's an interesting concept.
On Sun, Jun 23, 2013 at 9:35 PM, Hiroaki KAWAI <ka...@stratosphere.co.jp> wrote: > No I don't think we need to make such effort (sending emails) for devs, > I think we should fix the code itself (and comments in the codes) > because we're devs. > > > (2013/06/24 12:20), Marcus Sorensen wrote: >> >> I personally thought it had been publicized pretty well on various threads >> that there is a new system vm for master/4.2, but if you were unaware of >> it, do you think more needs to be done to call it out and make it known to >> the devs working on it? >> On Jun 23, 2013 8:33 PM, "Hiroaki KAWAI" <ka...@stratosphere.co.jp> wrote: >> >>> Current patch/systemvm/debian is based on debian squeeze, >>> which kernel is 2.6.32-5-686-bigmem. In that system vm, >>> cloud-early-config silently fails : >>> /etc/init.d/cloud-early-**config: line 109: /dev/vport0p1: No such file >>> >>> or directory >>> So I've upgraded to wheezy (which includes virtio-console.ko) >>> # I pushed some patch for this. >>> >>> I think we need to ANNOUNCE the incompatibility of this, >>> and hopfuly give some upgrade paths for cloudstack users. >>> >>> >>> (2013/03/05 7:24), Marcus Sorensen wrote: >>> >>>> I think this just requires an updated system vm (the virtio-serial >>>> portion). I've played a bit with the old debian 2.6.32-5-686-bigmem >>>> one and can't get the device nodes to show up, even though the >>>> /boot/config shows that it has CONFIG_VIRTIO_CONSOLE=y. However, if I >>>> try this with a CentOS 6.3 VM, on a CentOS 6.3 or Ubuntu 12.04 KVM >>>> host it works. So I'm not sure what's being used for the ipv6 update, >>>> but we can probably make one that works. We'll need to install qemu-ga >>>> and start it within the systemvm as well. >>>> >>>> On Mon, Mar 4, 2013 at 12:41 PM, Edison Su <edison...@citrix.com> wrote: >>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>>> >>>>>> From: Marcus Sorensen [mailto:shadow...@gmail.com] >>>>>> Sent: Sunday, March 03, 2013 12:13 PM >>>>>> To: >>>>>> cloudstack-dev@incubator.**apache.org<cloudstack-...@incubator.apache.org> >>>>>> >>>>>> Subject: [DISCUSS] getting rid of KVM patchdisk >>>>>> >>>>>> For those who don't know (this probably doesn't matter, but...), when >>>>>> KVM >>>>>> brings up a system VM, it creates a 'patchdisk' on primary storage. >>>>>> This >>>>>> patchdisk is used to pass along 1) the authorized_keys file and 2) a >>>>>> 'cmdline' >>>>>> file that describes to the systemvm startup services all of the >>>>>> various >>>>>> properties of the system vm. >>>>>> >>>>>> Example cmdline file: >>>>>> >>>>>> template=domP type=secstorage host=172.17.10.10 port=8250 name=s-1- >>>>>> VM >>>>>> zone=1 pod=1 guid=s-1-VM >>>>>> resource=com.cloud.storage.**resource.**NfsSecondaryStorageResource >>>>>> >>>>>> instance=SecStorage sslcopy=true role=templateProcessor mtu=1500 >>>>>> eth2ip=192.168.100.170 eth2mask=255.255.255.0 gateway=192.168.100.1 >>>>>> public.network.device=eth2 eth0ip=169.254.1.46 eth0mask=255.255.0.0 >>>>>> eth1ip=172.17.10.150 eth1mask=255.255.255.0 mgmtcidr=172.17.10.0/24 >>>>>> localgw=172.17.10.1 private.network.device=eth1 eth3ip=172.17.10.192 >>>>>> eth3mask=255.255.255.0 storageip=172.17.10.192 >>>>>> storagenetmask=255.255.255.0 storagegateway=172.17.10.1 >>>>>> internaldns1=8.8.4.4 dns1=8.8.8.8 >>>>>> >>>>>> This patch disk has been bugging me for awhile, as it creates a volume >>>>>> that >>>>>> isn't really tracked anywhere or known about in cloudstack's database. >>>>>> Up >>>>>> until recently these would just litter the KVM primary storages, but >>>>>> there's >>>>>> been some triage done to attempt to clean them up when the system vms >>>>>> go away. It's not perfect. It also can be inefficient for certain >>>>>> primary storage >>>>>> types, for example if you end up creating a bunch of 10MB luns on a >>>>>> SAN >>>>>> for >>>>>> these. >>>>>> >>>>>> So my question goes to those who have been working on the system vm. >>>>>> My first preference (aside from a full system vm redesign, perhaps >>>>>> something that is controlled via an API) would be to copy these up to >>>>>> the >>>>>> system vm via SCP or something. But the cloud services start so early >>>>>> on that >>>>>> this isn't possible. Next would be to inject them into the system vm's >>>>>> root >>>>>> disk before starting the server, but if we're allowing people to make >>>>>> their >>>>>> own system vms, can we count on the partitions being what we expect? >>>>>> Also >>>>>> I don't think this will work for RBD, which qemu directly connects to, >>>>>> with the >>>>>> host OS unaware of any disk. >>>>>> >>>>>> Options? >>>>>> >>>>> >>>>> Could you take a look at the status of this projects in KVM? >>>>> >>>>> http://wiki.qemu.org/Features/**QAPI/GuestAgent<http://wiki.qemu.org/Features/QAPI/GuestAgent> >>>>> >>>>> https://fedoraproject.org/**wiki/Features/VirtioSerial<https://fedoraproject.org/wiki/Features/VirtioSerial> >>>>> >>>>> >>>>> Basically, we need a way to talk to guest VM(sending parameters to KVM >>>>> guest) after VM is booted up. Both VMware/Xenserver has its own way to >>>>> send >>>>> parameters to guest VM through PV driver, but there is no such thing >>>>> for >>>>> KVM few years ago. >>>>> >>>> >>> >> >
