Re: kvm - why just qcow2
I suppose it would be best, and probably easiest, to accept templates in vmdk, vdi, etc, but qemu-img convert to qcow2 during the copy to primary storage, to keep the agent code from dealing with many formats. There's a lot of code that would need rework to deal with non-qcow2 file based disks. On Dec 13, 2013 10:39 PM, "Marcus Sorensen" wrote: > Is there any reason why we only support qcow2 format on KVM? It seems > like it would be fairly simple to support other formats, qemu-img can > handle going from VMDK to RAW for example, and qemu-kvm can even use > VMDK, QED, and other formats. It even seems like QemuImg.java was > written with other formats in mind. It seems like it wouldn't be a lot > of work to simply let other formats come through, we might have to > change LibvirtVMDef a bit so it can make the proper XML. >
RE: Documentation - Install Guide
Many thanks - who would have thought - Read the Wiki! I'll see where I get to. Cheers! Regards, Alex Hitchins VP Software Engineering S: +44 20 3603 0540 | M: +44 07788 423 969 www.shapeblue.com | Twitter:@ShapeBlue ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS Apache CloudStack Bootcamp training courses: **NEW!** CloudStack 4.2 training 08/09 January 2014, London 13-17 January 2014, GLOBAL. Instructor led, On-line 20-24 January 2014, GLOBAL. Instructor led, On-line -Original Message- From: Radhika Puthiyetath [mailto:radhika.puthiyet...@citrix.com] Sent: 14 December 2013 02:57 To: dev@cloudstack.apache.org Subject: RE: Documentation - Install Guide Awesome! Here are the instructions to start with documentation contribution. https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Documentation+Contributors+Overview Please let us know if you face any road blocks. Thank you -Radhika -Original Message- From: Alex Hitchins [mailto:alex.hitch...@shapeblue.com] Sent: Saturday, December 14, 2013 3:16 AM To: dev@cloudstack.apache.org Subject: Documentation - Install Guide I have found some problems with the current install guide. The last step details the wrong path for the template vm. It seems a regression as the instructions for 4.1 are correct. More than happy to change this however I'm not sure of the process involved - Can someone let me know what I need to do to edit it? Regards, Alex Hitchins This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue is a registered trademark. This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
Re: Documentation - Install Guide
Alex, also check the new proposed docs: http://cloudstack.readthedocs.org/en/latest/ There are easily editable via github... On Dec 14, 2013, at 9:44 AM, Alex Hitchins wrote: > Many thanks - who would have thought - Read the Wiki! > > I'll see where I get to. Cheers! > > Regards, > > Alex Hitchins > VP Software Engineering > > > > S: +44 20 3603 0540 | M: +44 07788 423 969 > www.shapeblue.com | Twitter:@ShapeBlue > > ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS > > Apache CloudStack Bootcamp training courses: > > **NEW!** CloudStack 4.2 training > 08/09 January 2014, London > 13-17 January 2014, GLOBAL. Instructor led, On-line > 20-24 January 2014, GLOBAL. Instructor led, On-line > > -Original Message- > From: Radhika Puthiyetath [mailto:radhika.puthiyet...@citrix.com] > Sent: 14 December 2013 02:57 > To: dev@cloudstack.apache.org > Subject: RE: Documentation - Install Guide > > Awesome! > > Here are the instructions to start with documentation contribution. > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Documentation+Contributors+Overview > > Please let us know if you face any road blocks. > > Thank you > > -Radhika > > -Original Message- > From: Alex Hitchins [mailto:alex.hitch...@shapeblue.com] > Sent: Saturday, December 14, 2013 3:16 AM > To: dev@cloudstack.apache.org > Subject: Documentation - Install Guide > > I have found some problems with the current install guide. The last step > details the wrong path for the template vm. It seems a regression as the > instructions for 4.1 are correct. > > More than happy to change this however I'm not sure of the process involved - > Can someone let me know what I need to do to edit it? > > > Regards, > > Alex Hitchins > > This email and any attachments to it may be confidential and are intended > solely for the use of the individual to whom it is addressed. Any views or > opinions expressed are solely those of the author and do not necessarily > represent those of Shape Blue Ltd or related companies. If you are not the > intended recipient of this email, you must neither take any action based upon > its contents, nor copy or show it to anyone. Please contact the sender if you > believe you have received this email in error. Shape Blue Ltd is a company > incorporated in England & Wales. ShapeBlue Services India LLP is a company > incorporated in India and is operated under license from Shape Blue Ltd. > Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is > operated under license from Shape Blue Ltd. ShapeBlue is a registered > trademark. > This email and any attachments to it may be confidential and are intended > solely for the use of the individual to whom it is addressed. Any views or > opinions expressed are solely those of the author and do not necessarily > represent those of Shape Blue Ltd or related companies. If you are not the > intended recipient of this email, you must neither take any action based upon > its contents, nor copy or show it to anyone. Please contact the sender if you > believe you have received this email in error. Shape Blue Ltd is a company > incorporated in England & Wales. ShapeBlue Services India LLP is a company > incorporated in India and is operated under license from Shape Blue Ltd. > Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is > operated under license from Shape Blue Ltd. ShapeBlue is a registered > trademark.
Re: kvm - why just qcow2
On 12/14/2013 09:05 AM, Marcus Sorensen wrote: I suppose it would be best, and probably easiest, to accept templates in vmdk, vdi, etc, but qemu-img convert to qcow2 during the copy to primary storage, to keep the agent code from dealing with many formats. There's a lot of code that would need rework to deal with non-qcow2 file based disks. I ran into this when implementing RBD. Since the code made all kinds of assumptions when it came to the format. RBD uses RAW (how KVM sees it). That's why I wrote QemuImg.java to abstract most of that work. But I agree with you, we shouldn't force ourselfs into QCOW2, but we should be aware that the hypervisors could be doing a lot of converting work. Wido On Dec 13, 2013 10:39 PM, "Marcus Sorensen" wrote: Is there any reason why we only support qcow2 format on KVM? It seems like it would be fairly simple to support other formats, qemu-img can handle going from VMDK to RAW for example, and qemu-kvm can even use VMDK, QED, and other formats. It even seems like QemuImg.java was written with other formats in mind. It seems like it wouldn't be a lot of work to simply let other formats come through, we might have to change LibvirtVMDef a bit so it can make the proper XML.
RE: kvm - why just qcow2
Marcus, When I refactored the template upload process ages ago, I left in an interface called Processor.java. The whole purpose of which was to allow others to add post processing of the template once its been uploaded. Such conversions can be done there. Take a look and see if it suits your purposes. --Alex > -Original Message- > From: Marcus Sorensen [mailto:shadow...@gmail.com] > Sent: Saturday, December 14, 2013 12:06 AM > To: dev@cloudstack.apache.org > Subject: Re: kvm - why just qcow2 > > I suppose it would be best, and probably easiest, to accept templates in > vmdk, vdi, etc, but qemu-img convert to qcow2 during the copy to primary > storage, to keep the agent code from dealing with many formats. There's a > lot of code that would need rework to deal with non-qcow2 file based disks. > On Dec 13, 2013 10:39 PM, "Marcus Sorensen" > wrote: > > > Is there any reason why we only support qcow2 format on KVM? It seems > > like it would be fairly simple to support other formats, qemu-img can > > handle going from VMDK to RAW for example, and qemu-kvm can even > use > > VMDK, QED, and other formats. It even seems like QemuImg.java was > > written with other formats in mind. It seems like it wouldn't be a lot > > of work to simply let other formats come through, we might have to > > change LibvirtVMDef a bit so it can make the proper XML. > >
Re: SG broken in Adv zone with multiple shared networks (4.2)
On 14.12.2013 01:07, Alena Prokharchyk wrote: We do make this check when deployVm is called with multiple networks specified, in SG enabled Advance zone. And don¹t let VM to have a mix of SG enabled and disabled Nics. However I suspect that this check is missing when Nic is plugged to existing VM via PlugNic API command. Why can't we use multiple SG network? What is the limitation and what can we do to overcome it? Lucian -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro
Re: kvm - why just qcow2
Yeah. I don't think it would be so bad, since we already do qemu-img convert on any non-file based storage, or at least a copy. I think the impact would be negligible or none going from a vmdk template to raw compared to the existing qcow2 to raw, but definitely be felt on file based primary storage that normally just copies the template file. On Dec 14, 2013 4:35 AM, "Wido den Hollander" wrote: > > > On 12/14/2013 09:05 AM, Marcus Sorensen wrote: > >> I suppose it would be best, and probably easiest, to accept templates in >> vmdk, vdi, etc, but qemu-img convert to qcow2 during the copy to primary >> storage, to keep the agent code from dealing with many formats. There's a >> lot of code that would need rework to deal with non-qcow2 file based >> disks. >> > > I ran into this when implementing RBD. Since the code made all kinds of > assumptions when it came to the format. RBD uses RAW (how KVM sees it). > > That's why I wrote QemuImg.java to abstract most of that work. > > But I agree with you, we shouldn't force ourselfs into QCOW2, but we > should be aware that the hypervisors could be doing a lot of converting > work. > > Wido > > On Dec 13, 2013 10:39 PM, "Marcus Sorensen" wrote: >> >> Is there any reason why we only support qcow2 format on KVM? It seems >>> like it would be fairly simple to support other formats, qemu-img can >>> handle going from VMDK to RAW for example, and qemu-kvm can even use >>> VMDK, QED, and other formats. It even seems like QemuImg.java was >>> written with other formats in mind. It seems like it wouldn't be a lot >>> of work to simply let other formats come through, we might have to >>> change LibvirtVMDef a bit so it can make the proper XML. >>> >>> >>
RE: kvm - why just qcow2
Sure, I'll take a look, it might just do the trick. I imagine this would be run in the SSVM? On the other hand, if we pass off format conversation to the hypervisors template copy as discussed, we could move toward multi hypervisor templates, where you can upload and store a single vmdk or vdi and the hypervisors just convert as necessary when copying to primary storage. On Dec 14, 2013 8:04 AM, "Alex Huang" wrote: > Marcus, > > When I refactored the template upload process ages ago, I left in an > interface called Processor.java. The whole purpose of which was to allow > others to add post processing of the template once its been uploaded. Such > conversions can be done there. Take a look and see if it suits your > purposes. > > --Alex > > > -Original Message- > > From: Marcus Sorensen [mailto:shadow...@gmail.com] > > Sent: Saturday, December 14, 2013 12:06 AM > > To: dev@cloudstack.apache.org > > Subject: Re: kvm - why just qcow2 > > > > I suppose it would be best, and probably easiest, to accept templates in > > vmdk, vdi, etc, but qemu-img convert to qcow2 during the copy to primary > > storage, to keep the agent code from dealing with many formats. There's a > > lot of code that would need rework to deal with non-qcow2 file based > disks. > > On Dec 13, 2013 10:39 PM, "Marcus Sorensen" > > wrote: > > > > > Is there any reason why we only support qcow2 format on KVM? It seems > > > like it would be fairly simple to support other formats, qemu-img can > > > handle going from VMDK to RAW for example, and qemu-kvm can even > > use > > > VMDK, QED, and other formats. It even seems like QemuImg.java was > > > written with other formats in mind. It seems like it wouldn't be a lot > > > of work to simply let other formats come through, we might have to > > > change LibvirtVMDef a bit so it can make the proper XML. > > > >
Re: git commit: updated refs/heads/4.2 to 2b34dc5
On Friday, December 13, 2013, Abhinandan Prateek wrote: > > > On 13/12/13 9:20 pm, "Chip Childers" > > wrote: > >> > >> > xapi > >> > 5.6.100-1-SNAPSHOT > >> > >> The specific project version ^^ > >> > >> For all previous releases, we have been releasing this specific pom.xml > >> file with the appropriate *non SNAPSHOT* versions for both the parent > >> version number and the XenServerJava project's version number > >> (specifically setting the latter to 5.6.100-1). > >> > >> Since we are releasing the XenServerJava code as part of ACS, why would > >> we leave the SNAPSHOT in there? > >> > >> Did something change that requires it to be added back? > >> > >> -chip > > > >I'll also point out that the reason that this is doing a mv then the > >perl string changes is that there used to be a bug in the mvn versions > >plugin that changed the XenServerJava version to the ACS version. This > >appears to have been fixed (just tested). So actually, the mv can be > >removed or not, it doesn't really matter because it's basically a noop. > > > >However -1 still stands unless someone convinces me that we should > >release the XenServerJava project with -SNAPSHOT. IIRC, that actually > >caused problems for us somehow (but I can't find a reference to that to > >back up my sometimes fuzzy memory). > > > > I was pointed to this ticket CLOUDSTACK-4827. The info is not very clear > and it appears that this fixes probably a bad version for the repo, and > not for the build. > > -abhi Please revert your commit. > > > > >
RE: Documentation - Install Guide
Thanks for the pointer to the new documentation. I will do an install from it and see how it pans out. There has probably been discussion on this that I've missed - is the current documentation being retired? If so, when is the changeover scheduled? Regards, S: +44 20 3603 0540 | M: +44 07788 423 969 www.shapeblue.com | Twitter:@ShapeBlue ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS Apache CloudStack Bootcamp training courses: **NEW!** CloudStack 4.2 training 08/09 January 2014, London 13-17 January 2014, GLOBAL. Instructor led, On-line 20-24 January 2014, GLOBAL. Instructor led, On-line -Original Message- From: sebgoa [mailto:run...@gmail.com] Sent: 14 December 2013 09:41 To: dev@cloudstack.apache.org Subject: Re: Documentation - Install Guide Alex, also check the new proposed docs: http://cloudstack.readthedocs.org/en/latest/ There are easily editable via github... On Dec 14, 2013, at 9:44 AM, Alex Hitchins wrote: > Many thanks - who would have thought - Read the Wiki! > > I'll see where I get to. Cheers! > > Regards, > > Alex Hitchins > VP Software Engineering > > > > S: +44 20 3603 0540 | M: +44 07788 423 969 www.shapeblue.com | > Twitter:@ShapeBlue > > ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS > > Apache CloudStack Bootcamp training courses: > > **NEW!** CloudStack 4.2 training > 08/09 January 2014, London > 13-17 January 2014, GLOBAL. Instructor led, On-line > 20-24 January 2014, GLOBAL. Instructor led, On-line > > -Original Message- > From: Radhika Puthiyetath [mailto:radhika.puthiyet...@citrix.com] > Sent: 14 December 2013 02:57 > To: dev@cloudstack.apache.org > Subject: RE: Documentation - Install Guide > > Awesome! > > Here are the instructions to start with documentation contribution. > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Docu > mentation+Contributors+Overview > > Please let us know if you face any road blocks. > > Thank you > > -Radhika > > -Original Message- > From: Alex Hitchins [mailto:alex.hitch...@shapeblue.com] > Sent: Saturday, December 14, 2013 3:16 AM > To: dev@cloudstack.apache.org > Subject: Documentation - Install Guide > > I have found some problems with the current install guide. The last step > details the wrong path for the template vm. It seems a regression as the > instructions for 4.1 are correct. > > More than happy to change this however I'm not sure of the process involved - > Can someone let me know what I need to do to edit it? > > > Regards, > > Alex Hitchins > > This email and any attachments to it may be confidential and are intended > solely for the use of the individual to whom it is addressed. Any views or > opinions expressed are solely those of the author and do not necessarily > represent those of Shape Blue Ltd or related companies. If you are not the > intended recipient of this email, you must neither take any action based upon > its contents, nor copy or show it to anyone. Please contact the sender if you > believe you have received this email in error. Shape Blue Ltd is a company > incorporated in England & Wales. ShapeBlue Services India LLP is a company > incorporated in India and is operated under license from Shape Blue Ltd. > Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is > operated under license from Shape Blue Ltd. ShapeBlue is a registered > trademark. > This email and any attachments to it may be confidential and are intended > solely for the use of the individual to whom it is addressed. Any views or > opinions expressed are solely those of the author and do not necessarily > represent those of Shape Blue Ltd or related companies. If you are not the > intended recipient of this email, you must neither take any action based upon > its contents, nor copy or show it to anyone. Please contact the sender if you > believe you have received this email in error. Shape Blue Ltd is a company > incorporated in England & Wales. ShapeBlue Services India LLP is a company > incorporated in India and is operated under license from Shape Blue Ltd. > Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is > operated under license from Shape Blue Ltd. ShapeBlue is a registered > trademark. This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue B