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. >>> >> >
